/usr/share/java as maven repository?

[manfred at mosabuam.com]

Hi!

I have been following this thread with much interest since I am using  
Maven commercially on a daily basis and have been doing so for a while.

Here are some ideas regarding Pauls questions..

Quoting Paul Cager <paul-debian at home.paulcager.org>:


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

That sounds about right. I would suggest to make the repository more  
of a permanent thing in some sort of maven-build-essentials package or  
whatever you want to call it. With transitive dependencies the  
temporary haul up and tear down process will be a significant overhead.

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

I think we will have to provide links for all versions that supported  
packages contain. These links will have to include not only the jar  
files, but more importantly the pom files. Ideally it will also  
include the packaged src files.
These can be very helpful when actually coding with a maven project in  
an IDE allowing debugging and source code reading in the whole chain  
including your dependencies.

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

To sort that out it would probably better to have a more permanent  
maven repository as a meta package that is a build dependency for  
every package that uses maven for its build. It would contain multiple  
versions of jars and so on.

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

You could do that. Maven allows you to create a list of all  
dependencies including transitive ones, but you need to use the  
dependencies and have their poms available.

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

That sounds like a very bad idea. Maven has all the power to work  
through the transitive dependencies and conflicts of version allowing  
the developer to
override and exclude stuff in the pom. Removing that power and writing  
a new system that does the same again sounds like a waste of time to me.

The same point as above also applies to  Dalibors suggestion bwlow.

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

I think using Maven with a Debian internal and cleaned up repository  
that only contains debian compliant packages and the fixes to make the  
build of any debian package work is the better approach. It is also  
more useful for the bigger community since this debian repo could be  
used as a clean minimum repo. Many other public repos are quite a mess  
with lots of historic rubbish in there (like broken spring packages,  
wrong and moved groupids and so on).

I hope some of these ideas are a bit of help.

manfred
Vancouver Island Java User Group
http://www.mosabuam.com