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 > [email protected] > http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers > _______________________________________________ pkg-java-maintainers mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
