| 1 |
Hi Robert, |
| 2 |
|
| 3 |
Robert Burrell Donkin wrote: |
| 4 |
|
| 5 |
> On Tue, May 24, 2011 at 12:52 PM, Kasun Gajasinghe |
| 6 |
> <kasunbg@×××××.com> wrote: |
| 7 |
>> On 24 May 2011, at 14:37, Petteri Räty |
| 8 |
>> <betelgeuse@g.o> wrote: |
| 9 |
>>> On 05/23/2011 07:52 PM, Kasun Gajasinghe wrote: |
| 10 |
>>> |
| 11 |
>>>>> |
| 12 |
>>>>> maven-bin 2.x support continues to work through the binary package? |
| 13 |
>>>> |
| 14 |
>>>> Yes, we can keep supporting maven-bin 2.x for maven users. Though the |
| 15 |
>>>> packagers of projects based on maven won't be able to use the support |
| 16 |
>>>> for maven 2.x if we start with 3.x.This project's focus is more |
| 17 |
>>>> towards packagers, right? I think Serkan or people who are more |
| 18 |
>>>> familiar with this can give an exact answer. |
| 19 |
>>>> |
| 20 |
>>> |
| 21 |
>>> So are you discussing which version of Maven to build from source or |
| 22 |
>>> which version to target ebuild infrastructure for? Those two don't |
| 23 |
>>> necessarily need to be the same and your topic implied the former but |
| 24 |
>>> the above talks about the latter. |
| 25 |
>> |
| 26 |
>> Well, mainly this project is inclined towards packagers. |
| 27 |
>> But of course the users are targeted too. Currently, users have the |
| 28 |
>> maven-bin too |
| 29 |
>> which means they have a choice in hand. The problem with Maven 3 is |
| 30 |
>> that some important plugins for users are not |
| 31 |
>> supported yet. |
| 32 |
> |
| 33 |
> AIUI the situation is more complex than that |
| 34 |
> |
| 35 |
> maven seems to be moving towards requiring specific core versions for |
| 36 |
> builds. some projects i develop require maven 2, some maven 3. i |
| 37 |
> manage this situation with a set of custom scripts and installations |
| 38 |
> independent of gentoo. i expect other developers now work in a similar |
| 39 |
> way. (same goes for jdks.) the gentoo java stuff just gets in my way |
| 40 |
> now for development. |
| 41 |
|
| 42 |
Why? I have emerged maven:1.0, maven:1.1, maven:2.0, maven:2.2 and |
| 43 |
maven:3.0. I've selected my default version with eselect. However, I can use |
| 44 |
any of those versions at the same time: |
| 45 |
|
| 46 |
/usr/bin $ ls -lGgo m*v*n* |
| 47 |
lrwxrwxrwx 1 34 Jan 22 14:07 maven-1.0 -> /usr/share/maven- |
| 48 |
bin-1.0/bin/maven |
| 49 |
lrwxrwxrwx 1 34 Jan 22 14:07 maven-1.1 -> /usr/share/maven- |
| 50 |
bin-1.1/bin/maven |
| 51 |
lrwxrwxrwx 1 7 Jul 19 2010 mvn -> mvn-3.0 |
| 52 |
lrwxrwxrwx 1 32 Apr 30 2010 mvn-2.0 -> /usr/share/maven-bin-2.0/bin/mvn |
| 53 |
lrwxrwxrwx 1 32 Apr 30 2010 mvn-2.2 -> /usr/share/maven-bin-2.2/bin/mvn |
| 54 |
lrwxrwxrwx 1 32 Mar 10 18:17 mvn-3.0 -> /usr/share/maven-bin-3.0/bin/mvn |
| 55 |
|
| 56 |
All that eselect effectively does is to switch the unversioned link. You may |
| 57 |
call any of those scripts (well, you should not have set MAVEN_HOME at all, |
| 58 |
the Maven start script will do this for you anyway). |
| 59 |
|
| 60 |
> FWIW one unresolved challenge for linux distributions with the rise of |
| 61 |
> bytecode languages (such as Java) is that compressed bytecodes are not |
| 62 |
> binaries in the usual sense (platform dependent machine executable |
| 63 |
> machine code). i know that it's a hard thing for the linux community |
| 64 |
> to hear but it's about time that the community acknowledged that these |
| 65 |
> languages are now mainstream and stop trying to force them into a |
| 66 |
> inappropriate provisioning model. |
| 67 |
|
| 68 |
To build Maven from source in Gentoo I wonder about the hen-and-egg problem. |
| 69 |
|
| 70 |
Cheers, |
| 71 |
Jörg |
Archives