1 |
one day i'll remember about gmail :-< |
2 |
|
3 |
---------- Forwarded message ---------- |
4 |
From: robert burrell donkin <robertburrelldonkin@×××××.com> |
5 |
Date: May 8, 2006 11:35 PM |
6 |
Subject: Re: [gentoo-java] Java ideas for Summer of Code |
7 |
To: Joshua Nichols <nichoj@g.o> |
8 |
|
9 |
On 5/7/06, Joshua Nichols <nichoj@g.o> wrote: |
10 |
|
11 |
> -----BEGIN PGP SIGNED MESSAGE----- |
12 |
> Hash: SHA1 |
13 |
> |
14 |
> robert burrell donkin wrote: |
15 |
> > On 5/5/06, Joshua Nichols <nichoj@g.o> wrote: |
16 |
> >> |
17 |
> >> robert burrell donkin wrote: |
18 |
> >> > On 5/4/06, *Joshua Nichols* <nichoj@g.o |
19 |
|
20 |
|
21 |
<snip> |
22 |
|
23 |
>> why not open source java? |
24 |
> >> > |
25 |
> >> Uh, open source java is EXACTLY what I'm talking about :) |
26 |
> > |
27 |
> > |
28 |
> > good :-) |
29 |
> > |
30 |
> > gump (http://gump.apache.org/ ) builds and tests 700 projects from |
31 |
> source |
32 |
> > each day. IIRC the classpath team run gump. might be able to dig out an |
33 |
> url |
34 |
> > if you're interested in seeing the current level of progress. |
35 |
> > |
36 |
> > in general, finding a way to generate EBUILDs from gump descriptors |
37 |
> would |
38 |
> > make available a lot of libraries and applications without extensive |
39 |
> > effort. |
40 |
> > a maven EBUILD plugin would be even better. |
41 |
> |
42 |
> ebuild isn't an acronym, so you don't need to capitalize it all ;) |
43 |
|
44 |
|
45 |
looks better as EBUILD (especially as i don't know where the shift key is ;) |
46 |
|
47 |
|
48 |
maybe need to fake an acronym for marketing purposes :) |
49 |
|
50 |
But having a way to generate ebuilds from gump descriptor or maven |
51 |
> project files would be intersting and all well and good... but someone |
52 |
> would actually have to do the work to put it together. That person isn't |
53 |
> likely me in the foreseeable future, unless someone has a deal on cloning. |
54 |
> |
55 |
|
56 |
|
57 |
just speculating out load ATM (on the generation, not the cloning) |
58 |
|
59 |
> apache has a lot of API implementations but they are scattered amongst |
60 |
> > different projects. it would probably be generally a good thing if they |
61 |
> > were |
62 |
> > more easily accessible. fixing that would also be a big gain for a small |
63 |
> |
64 |
> > amount of effort. |
65 |
> |
66 |
> 'small amount of effort' for whom? |
67 |
|
68 |
|
69 |
sorry - ASF hat on there :-/ |
70 |
|
71 |
actually providing an index of all available implementations in one place is |
72 |
something that the ASF should really do. make things a little easier for |
73 |
those folks downstream consumers looking for clean room implementations and |
74 |
a lot easier for users. there's a lot of activity around DOAP ATM and this |
75 |
fits in well. |
76 |
|
77 |
Adding a lot of packages doesn't |
78 |
> particularly sound like a small effort to me. |
79 |
|
80 |
Another hurdle is that |
81 |
> many projects are switching to maven for building, and as I describe in |
82 |
> the project ideas, we aren't quiet ready to handle using it to build. |
83 |
|
84 |
|
85 |
i'm not sure i understand why mavenization is such a hurdle. nearly anything |
86 |
built with maven can be built with ant. (maven can generate an ant build |
87 |
from the POM.) projects using techniques such as generation using custom |
88 |
maven plugins aren't so easy but that's a definite minority. |
89 |
|
90 |
(but that's not to say that building maven2 isn't a worthy exercise) |
91 |
|
92 |
- robert |