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

[Robert Burrell Donkin <robertburrelldonkin@gmail.com>]

On Wed, May 25, 2011 at 5:09 PM, Jörg Schaible <joerg.schaible@gmx.de> wrote:
> Hi Robert,

Hi Jörg :-)

> Robert Burrell Donkin wrote:
>
>> On Tue, May 24, 2011 at 12:52 PM, Kasun Gajasinghe
>> <kasunbg@gmail.com> wrote:
>>> On 24 May 2011, at 14:37, Petteri Räty
>>> <betelgeuse@gentoo.org> wrote:
>>>> On 05/23/2011 07:52 PM, Kasun Gajasinghe wrote:
>>>>
>>>>>>
>>>>>> maven-bin 2.x support continues to work through the binary package?
>>>>>
>>>>> Yes, we can keep supporting maven-bin 2.x for maven users. Though the
>>>>> packagers of projects based on maven won't be able to use the support
>>>>> for maven 2.x if we start with 3.x.This project's focus is more
>>>>> towards packagers, right?  I think Serkan or people who are more
>>>>> familiar with this can give an exact answer.
>>>>>
>>>>
>>>> So are you discussing which version of Maven to build from source or
>>>> which version to target ebuild infrastructure for? Those two don't
>>>> necessarily need to be the same and your topic implied the former but
>>>> the above talks about the latter.
>>>
>>> Well, mainly this project is inclined towards packagers.
>>> But of course the users are targeted too. Currently, users have the
>>> maven-bin too
>>> which means they have a choice in hand. The problem with Maven 3 is
>>> that some important plugins for users are not
>>> supported yet.
>>
>> 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...)

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

Robert