/usr/share/java as maven repository?

[Paul Cager]

On Wed, December 19, 2007 17:52, Dalibor Topic wrote:
> Arnaud Vandyck wrote:
>> Many thanks for the clarifications.
>>
>> So if we are talking about refactoring /usr/share/java, let's do it in
>> some sort of Debian way. We'll write a wrapper around different build
>> system to let them understand our layout. (is it what you meant?)
>>
> I hope that wrapping the build systems themselves won't be necessary.
>
> It may be easier to 'setUp' and 'tearDown' virtual repositories based on
> our own binaries in
> /usr/share/java and automatically generated metadata from debian's
> metadata about the packages
> using some kind of a debhelper_maven script or something like that.
>
> I'd imagine something like this:
> 1. for the package build, you'd call debhelper_maven
> 2. (setUp) it would look at the dependency information of the package,
> and for each dependency generate a POM file on the fly from the debian
> package metadata,
> 3. (build) then call maven with the freshly generated pom repository to
> do its build work,
> 4. (tearDown) then tear down the POM repository, i.e. remove POMs,
> unregister them from Maven, etc.

That sounds good. There's still a few things bothering me - anyone got any
ideas on the following?


Offline Mode + Repository
=========================

When building a Debian package I expect we'll be running Maven with the
offline flag, so I believe we'll have to set up the temporary repository
in the local cache, e.g. debian/.m2/repository (and provide a
<localRepository> setting). Or is there a better way?


Versions
========

The POMs will refer to an explicit version of a dependency, e.g.
junit-3.8.1, and its unlikely we'd have exactly the right version in
/usr/share/java (the Maven build of jetty, for instance, downloaded two
different versions of junit). I guess we will have to "fake" it and
pretend our jar is the correct version.

E.g. the POM could require JUnit-3.8.1 but Debian has packaged version
3.8.2. In this case we would set up a link in the temporary Maven
repository:

  debian/.m2/repository/.../junit-3.8.1.jar -> /usr/share/java/junit.jar
-> /usr/share/java/junit-3.8.2.jar

We should check that the Debian version is not *older* than the version
required by the POM, but we are still relying on releases being backwards
compatible. Any comments?


Mapping Maven Artifacts to Our Jar Names
========================================

Any ideas how we'd generate the list of jars to copy into our temporary
repository? I think most of the time a simple naming convention is good
enough (e.g. artifact junit maps onto /usr/share/java/junit.jar). But I
think we also need to allow the packager to override the default - for
example if Debian has packaged two ABI-incompatible versions of a jar, or
used non-standard jar names.

I guess that *indirect* dependencies wouldn't be set up in the temporary
maven repository - we'd just add them to the classpath as we do for ant
builds. Would this work? I can't see an alternative here, as we wouldn't
have the dependencies' POMs.


The "No-Dependencies" Alternative
=================================

Alternatively we could add *all* required jars to the classpath (same as
we do now for ant builds), and remove all dependencies from the POM(s). I
think that would work, but haven't tested it. Instead of modifying the
POM(s) we could write a Maven plugin so that Maven ignores any
dependencies - I'm not sure how easy that would be.

Then I believe we would only need to put the plugins (e.g.
maven-compiler-plugin) in the temporary repository.




> Replace maven & POM above with a different system, but the steps would
> be virtually the same.
>
> Pros:
> * builds are reproducible & consistent within the Debian system
> * Debian's metadata is used throughout the build system, i.e. no
> metadata skew
> * could be separated from user's own build system repository, so no
> 'your jars are messing with my jars' conflicts
>
> Cons:
> * someone would need to implement it and see if the pros actually hold. :)
>
> cheers,
> dalibor topic
>
> _______________________________________________
> pkg-java-maintainers mailing list
> pkg-java-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
>