This is a discussion page for the pkg-java team's plan to use Maven to build Debian packages. If you just want to find out how to install and run Maven in Debian, you are probably looking at the wrong page. Instead run:


How Many Jars?!!??

As an indication of how many jars we need to package before we can think about using Maven in Debian builds, I ran a mvn install for Jetty-6. It downloaded 58 jars.

Some of these jars we have already packaged, and some are specific to Jetty, but it still looks like a big list:

Questions

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:

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.


CategoryJava