Re: Re: Maven from source - version 2.x or 3.x ?

Hi Robert,

Robert Burrell Donkin wrote:

> On Wed, May 25, 2011 at 5:09 PM, J=C3=B6rg Schaible
> <[email protected]> wrote:
>> Hi Robert,
>=20
> Hi J=C3=B6rg :-)
>=20
[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 simila=
r
>>> 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 c=
an
>> 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. Y=
ou
>> may call any of those scripts (well, you should not have set MAVEN_HOM=
E
>> at all, the Maven start script will do this for you anyway).
>=20
> Cool. Thanks :-)
>=20
> 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 h=
ad=20
real problems with this. Apart from that I create my own ebuilds for Mave=
n=20
RCs and the like. Actually I don't expect projects that require Maven 2.0=
 to=20
be really buildable with Maven 2.0.0 ;-)

>>> FWIW one unresolved challenge for linux distributions with the rise o=
f
>>> bytecode languages (such as Java) is that compressed bytecodes are no=
t
>>> 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 thes=
e
>>> 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.
>=20
> +1
>=20
> 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.
>=20
> 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=
=20
build a complex project from source (like Maven itself), I am quite sure=20
that the build will require e.g. five different versions of commons-lang.=
 So=20
what to do with it in Gentoo? Create slots for all of these versions? Cre=
ate=20
a symlink in a system local Maven repo for all those versions to the one=20
that is actually installed? Who updates these symlinks if the real packag=
e=20
is updated? Not to speak that all of this already require a hook into=20
Gentoo's download processing ... and might possibly require calling emerg=
e=20
for missing deps that are available as Gentoo package?

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

Cheers,
J=C3=B6rg