/usr/share/java as maven repository?

[Dalibor Topic]

Paul Cager wrote:
> 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?

Another way, proposed by trygvis on IRC, would be to implement 
functionality in Wagon to read Debian metadata / packages.

> 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.

Yes.

The other alternative is to package all versions referenced as build 
dependencies as separate, un-upgradeable, parallel installable packages, 
I guess, and that's not going to work very well or to be very maintainable.

Another alternative is to patch POMs of packages using maven to use
a) a dependencymanagement section in the POM to set explicit global 
versions of dependencies to those present in Debian at build time
b) and to scrub the version information from the dependencies themselves.

I don't see how we could do this in a repeatable way, though, if we 
patch the POM in the package to be built, as then we'd fix its 
dependencies to the versions in Debian at the time of build, which may 
be upgraded by the time of the next rebuild. So I think that generating 
virtual POMs for dependencies on the fly is a better way to do it, than
to rewrite POMs of packages with patches.

> 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?

I think that's sufficient for now. We can see how well that works once 
it's implemented. We might get lucky, after all. ;)

> 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.

Right, I think that should be a feature of the setUp tool.

> 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.

What's an indirect dependency? Something defined in the POM of a dependency?

In that case, since we generate the virtual POMs for the direct 
dependencies, and have access to the Debian metadata on dependencies of 
those packages, we could also generate their transitive closure within 
Debian's Java hierarchy, I guess.

cheers,
dalibor topic