[gentoo-java] Re: Re: Maven from source - version 2.x or 3.x ?

[Jörg Schaible]

Hi Robert,

Robert Burrell Donkin wrote:

> On Wed, May 25, 2011 at 5:09 PM, Jörg Schaible
> <joerg.schaible@×××.de> wrote:
>> Hi Robert,
>
> Hi Jörg :-)
>
[snip]
>>>
>>> AIUI the situation is more complex than that
>>>
>>> maven seems to be moving towards requiring specific core versions for
>>> builds. some  projects i develop require maven 2, some maven 3. i
>>> manage this situation with a set of custom scripts and installations
>>> independent of gentoo. i expect other developers now work in a similar
>>> way. (same goes for jdks.) the gentoo java stuff just gets in my way
>>> now for development.
>>
>> Why? I have emerged maven:1.0, maven:1.1, maven:2.0, maven:2.2 and
>> maven:3.0. I've selected my default version with eselect. However, I can
>> use any of those versions at the same time:
>>
>> /usr/bin $ ls -lGgo m*v*n*
>> lrwxrwxrwx 1    34 Jan 22 14:07 maven-1.0 -> /usr/share/maven-
>> bin-1.0/bin/maven
>> lrwxrwxrwx 1    34 Jan 22 14:07 maven-1.1 -> /usr/share/maven-
>> bin-1.1/bin/maven
>> lrwxrwxrwx 1     7 Jul 19  2010 mvn -> mvn-3.0
>> lrwxrwxrwx 1    32 Apr 30  2010 mvn-2.0 ->
>> /usr/share/maven-bin-2.0/bin/mvn lrwxrwxrwx 1    32 Apr 30  2010 mvn-2.2
>> -> /usr/share/maven-bin-2.2/bin/mvn lrwxrwxrwx 1    32 Mar 10 18:17
>> mvn-3.0 -> /usr/share/maven-bin-3.0/bin/mvn
>>
>> All that eselect effectively does is to switch the unversioned link. You
>> may call any of those scripts (well, you should not have set MAVEN_HOME
>> at all, the Maven start script will do this for you anyway).
>
> Cool. Thanks :-)
>
> Apache James builds now insists on particular minor versions (mostly
> 3.0.3 ATM). This matches the current version for maven-bin-3.0 but I
> suppose it should be easy enough to create an overlay or something to
> handle minor versions when needed...)

I have typically always the latest installed for a specific slot. Never had 
real problems with this. Apart from that I create my own ebuilds for Maven 
RCs and the like. Actually I don't expect projects that require Maven 2.0 to 
be really buildable with Maven 2.0.0 ;-)

>>> FWIW one unresolved challenge for linux distributions with the rise of
>>> bytecode languages (such as Java) is that compressed bytecodes are not
>>> binaries in the usual sense (platform dependent machine executable
>>> machine code). i know that it's a hard thing for the linux community
>>> to hear but it's about time that the community acknowledged that these
>>> languages are now mainstream and stop trying to force them into a
>>> inappropriate provisioning model.
>>
>> To build Maven from source in Gentoo I wonder about the hen-and-egg
>> problem.
>
> +1
>
> The scale scares me as well. Loosely coupled systems assembled from
> lots of components are becoming the dominant paradigm for bytecode
> languages (such as java and ruby). The amount of effort required to
> create independent builds for all those libraries is huge for no gain
> I know.
>
> I still believe that there are significant advantages to building
> every application from source, and most applications built from
> bytecode can be optimised for a platform. But IMHO the bytecode
> repository approach is the best way to manage libraries for these
> languages.

Maven simply does not fit to Gentoo's package philosophy. When you try to 
build a complex project from source (like Maven itself), I am quite sure 
that the build will require e.g. five different versions of commons-lang. So 
what to do with it in Gentoo? Create slots for all of these versions? Create 
a symlink in a system local Maven repo for all those versions to the one 
that is actually installed? Who updates these symlinks if the real package 
is updated? Not to speak that all of this already require a hook into 
Gentoo's download processing ... and might possibly require calling emerge 
for missing deps that are available as Gentoo package?

Luckily this is not *my* can of worms :D

Cheers,
Jörg