1 |
Hi Robert, |
2 |
|
3 |
Robert Burrell Donkin wrote: |
4 |
|
5 |
> On Wed, May 25, 2011 at 5:09 PM, Jörg Schaible |
6 |
> <joerg.schaible@×××.de> wrote: |
7 |
>> Hi Robert, |
8 |
> |
9 |
> Hi Jörg :-) |
10 |
> |
11 |
[snip] |
12 |
>>> |
13 |
>>> AIUI the situation is more complex than that |
14 |
>>> |
15 |
>>> maven seems to be moving towards requiring specific core versions for |
16 |
>>> builds. some projects i develop require maven 2, some maven 3. i |
17 |
>>> manage this situation with a set of custom scripts and installations |
18 |
>>> independent of gentoo. i expect other developers now work in a similar |
19 |
>>> way. (same goes for jdks.) the gentoo java stuff just gets in my way |
20 |
>>> now for development. |
21 |
>> |
22 |
>> Why? I have emerged maven:1.0, maven:1.1, maven:2.0, maven:2.2 and |
23 |
>> maven:3.0. I've selected my default version with eselect. However, I can |
24 |
>> use any of those versions at the same time: |
25 |
>> |
26 |
>> /usr/bin $ ls -lGgo m*v*n* |
27 |
>> lrwxrwxrwx 1 34 Jan 22 14:07 maven-1.0 -> /usr/share/maven- |
28 |
>> bin-1.0/bin/maven |
29 |
>> lrwxrwxrwx 1 34 Jan 22 14:07 maven-1.1 -> /usr/share/maven- |
30 |
>> bin-1.1/bin/maven |
31 |
>> lrwxrwxrwx 1 7 Jul 19 2010 mvn -> mvn-3.0 |
32 |
>> lrwxrwxrwx 1 32 Apr 30 2010 mvn-2.0 -> |
33 |
>> /usr/share/maven-bin-2.0/bin/mvn lrwxrwxrwx 1 32 Apr 30 2010 mvn-2.2 |
34 |
>> -> /usr/share/maven-bin-2.2/bin/mvn lrwxrwxrwx 1 32 Mar 10 18:17 |
35 |
>> mvn-3.0 -> /usr/share/maven-bin-3.0/bin/mvn |
36 |
>> |
37 |
>> All that eselect effectively does is to switch the unversioned link. You |
38 |
>> may call any of those scripts (well, you should not have set MAVEN_HOME |
39 |
>> at all, the Maven start script will do this for you anyway). |
40 |
> |
41 |
> Cool. Thanks :-) |
42 |
> |
43 |
> Apache James builds now insists on particular minor versions (mostly |
44 |
> 3.0.3 ATM). This matches the current version for maven-bin-3.0 but I |
45 |
> suppose it should be easy enough to create an overlay or something to |
46 |
> handle minor versions when needed...) |
47 |
|
48 |
I have typically always the latest installed for a specific slot. Never had |
49 |
real problems with this. Apart from that I create my own ebuilds for Maven |
50 |
RCs and the like. Actually I don't expect projects that require Maven 2.0 to |
51 |
be really buildable with Maven 2.0.0 ;-) |
52 |
|
53 |
>>> FWIW one unresolved challenge for linux distributions with the rise of |
54 |
>>> bytecode languages (such as Java) is that compressed bytecodes are not |
55 |
>>> binaries in the usual sense (platform dependent machine executable |
56 |
>>> machine code). i know that it's a hard thing for the linux community |
57 |
>>> to hear but it's about time that the community acknowledged that these |
58 |
>>> languages are now mainstream and stop trying to force them into a |
59 |
>>> inappropriate provisioning model. |
60 |
>> |
61 |
>> To build Maven from source in Gentoo I wonder about the hen-and-egg |
62 |
>> problem. |
63 |
> |
64 |
> +1 |
65 |
> |
66 |
> The scale scares me as well. Loosely coupled systems assembled from |
67 |
> lots of components are becoming the dominant paradigm for bytecode |
68 |
> languages (such as java and ruby). The amount of effort required to |
69 |
> create independent builds for all those libraries is huge for no gain |
70 |
> I know. |
71 |
> |
72 |
> I still believe that there are significant advantages to building |
73 |
> every application from source, and most applications built from |
74 |
> bytecode can be optimised for a platform. But IMHO the bytecode |
75 |
> repository approach is the best way to manage libraries for these |
76 |
> languages. |
77 |
|
78 |
Maven simply does not fit to Gentoo's package philosophy. When you try to |
79 |
build a complex project from source (like Maven itself), I am quite sure |
80 |
that the build will require e.g. five different versions of commons-lang. So |
81 |
what to do with it in Gentoo? Create slots for all of these versions? Create |
82 |
a symlink in a system local Maven repo for all those versions to the one |
83 |
that is actually installed? Who updates these symlinks if the real package |
84 |
is updated? Not to speak that all of this already require a hook into |
85 |
Gentoo's download processing ... and might possibly require calling emerge |
86 |
for missing deps that are available as Gentoo package? |
87 |
|
88 |
Luckily this is not *my* can of worms :D |
89 |
|
90 |
Cheers, |
91 |
Jörg |