/usr/share/java as maven repository?
paul-debian at home.paulcager.org
Fri Dec 21 16:17:16 UTC 2007
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?
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
debian/.m2/repository/.../junit-3.8.1.jar -> /usr/share/java/junit.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.
> * 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
> * someone would need to implement it and see if the pros actually hold. :)
> dalibor topic
> pkg-java-maintainers mailing list
> pkg-java-maintainers at lists.alioth.debian.org
More information about the pkg-java-maintainers