| 1 |
On Wed, May 25, 2011 at 5:09 PM, Jörg Schaible <joerg.schaible@×××.de> wrote: |
| 2 |
> Hi Robert, |
| 3 |
|
| 4 |
Hi Jörg :-) |
| 5 |
|
| 6 |
> Robert Burrell Donkin wrote: |
| 7 |
> |
| 8 |
>> On Tue, May 24, 2011 at 12:52 PM, Kasun Gajasinghe |
| 9 |
>> <kasunbg@×××××.com> wrote: |
| 10 |
>>> On 24 May 2011, at 14:37, Petteri Räty |
| 11 |
>>> <betelgeuse@g.o> wrote: |
| 12 |
>>>> On 05/23/2011 07:52 PM, Kasun Gajasinghe wrote: |
| 13 |
>>>> |
| 14 |
>>>>>> |
| 15 |
>>>>>> maven-bin 2.x support continues to work through the binary package? |
| 16 |
>>>>> |
| 17 |
>>>>> Yes, we can keep supporting maven-bin 2.x for maven users. Though the |
| 18 |
>>>>> packagers of projects based on maven won't be able to use the support |
| 19 |
>>>>> for maven 2.x if we start with 3.x.This project's focus is more |
| 20 |
>>>>> towards packagers, right? I think Serkan or people who are more |
| 21 |
>>>>> familiar with this can give an exact answer. |
| 22 |
>>>>> |
| 23 |
>>>> |
| 24 |
>>>> So are you discussing which version of Maven to build from source or |
| 25 |
>>>> which version to target ebuild infrastructure for? Those two don't |
| 26 |
>>>> necessarily need to be the same and your topic implied the former but |
| 27 |
>>>> the above talks about the latter. |
| 28 |
>>> |
| 29 |
>>> Well, mainly this project is inclined towards packagers. |
| 30 |
>>> But of course the users are targeted too. Currently, users have the |
| 31 |
>>> maven-bin too |
| 32 |
>>> which means they have a choice in hand. The problem with Maven 3 is |
| 33 |
>>> that some important plugins for users are not |
| 34 |
>>> supported yet. |
| 35 |
>> |
| 36 |
>> AIUI the situation is more complex than that |
| 37 |
>> |
| 38 |
>> maven seems to be moving towards requiring specific core versions for |
| 39 |
>> builds. some projects i develop require maven 2, some maven 3. i |
| 40 |
>> manage this situation with a set of custom scripts and installations |
| 41 |
>> independent of gentoo. i expect other developers now work in a similar |
| 42 |
>> way. (same goes for jdks.) the gentoo java stuff just gets in my way |
| 43 |
>> now for development. |
| 44 |
> |
| 45 |
> Why? I have emerged maven:1.0, maven:1.1, maven:2.0, maven:2.2 and |
| 46 |
> maven:3.0. I've selected my default version with eselect. However, I can use |
| 47 |
> any of those versions at the same time: |
| 48 |
> |
| 49 |
> /usr/bin $ ls -lGgo m*v*n* |
| 50 |
> lrwxrwxrwx 1 34 Jan 22 14:07 maven-1.0 -> /usr/share/maven- |
| 51 |
> bin-1.0/bin/maven |
| 52 |
> lrwxrwxrwx 1 34 Jan 22 14:07 maven-1.1 -> /usr/share/maven- |
| 53 |
> bin-1.1/bin/maven |
| 54 |
> lrwxrwxrwx 1 7 Jul 19 2010 mvn -> mvn-3.0 |
| 55 |
> lrwxrwxrwx 1 32 Apr 30 2010 mvn-2.0 -> /usr/share/maven-bin-2.0/bin/mvn |
| 56 |
> lrwxrwxrwx 1 32 Apr 30 2010 mvn-2.2 -> /usr/share/maven-bin-2.2/bin/mvn |
| 57 |
> lrwxrwxrwx 1 32 Mar 10 18:17 mvn-3.0 -> /usr/share/maven-bin-3.0/bin/mvn |
| 58 |
> |
| 59 |
> All that eselect effectively does is to switch the unversioned link. You may |
| 60 |
> call any of those scripts (well, you should not have set MAVEN_HOME at all, |
| 61 |
> the Maven start script will do this for you anyway). |
| 62 |
|
| 63 |
Cool. Thanks :-) |
| 64 |
|
| 65 |
Apache James builds now insists on particular minor versions (mostly |
| 66 |
3.0.3 ATM). This matches the current version for maven-bin-3.0 but I |
| 67 |
suppose it should be easy enough to create an overlay or something to |
| 68 |
handle minor versions when needed...) |
| 69 |
|
| 70 |
>> FWIW one unresolved challenge for linux distributions with the rise of |
| 71 |
>> bytecode languages (such as Java) is that compressed bytecodes are not |
| 72 |
>> binaries in the usual sense (platform dependent machine executable |
| 73 |
>> machine code). i know that it's a hard thing for the linux community |
| 74 |
>> to hear but it's about time that the community acknowledged that these |
| 75 |
>> languages are now mainstream and stop trying to force them into a |
| 76 |
>> inappropriate provisioning model. |
| 77 |
> |
| 78 |
> To build Maven from source in Gentoo I wonder about the hen-and-egg problem. |
| 79 |
|
| 80 |
+1 |
| 81 |
|
| 82 |
The scale scares me as well. Loosely coupled systems assembled from |
| 83 |
lots of components are becoming the dominant paradigm for bytecode |
| 84 |
languages (such as java and ruby). The amount of effort required to |
| 85 |
create independent builds for all those libraries is huge for no gain |
| 86 |
I know. |
| 87 |
|
| 88 |
I still believe that there are significant advantages to building |
| 89 |
every application from source, and most applications built from |
| 90 |
bytecode can be optimised for a platform. But IMHO the bytecode |
| 91 |
repository approach is the best way to manage libraries for these |
| 92 |
languages. |
| 93 |
|
| 94 |
Robert |
Archives