[gentoo-java] Java ideas for Summer of Code

["robert burrell donkin" <robertburrelldonkin@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]

one day i'll remember about gmail :-<

---------- Forwarded message ----------
From: robert burrell donkin <robertburrelldonkin@gmail.com>
Date: May 8, 2006 11:35 PM
Subject: Re: [gentoo-java] Java ideas for Summer of Code
To: Joshua Nichols <nichoj@gentoo.org>

On 5/7/06, Joshua Nichols <nichoj@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> robert burrell donkin wrote:
> > On 5/5/06, Joshua Nichols <nichoj@gentoo.org> wrote:
> >>
> >> robert burrell donkin wrote:
> >> > On 5/4/06, *Joshua Nichols* <nichoj@gentoo.org


<snip>

>> why not open source java?
> >> >
> >> Uh, open source java is EXACTLY what I'm talking about :)
> >
> >
> > good :-)
> >
> > gump (http://gump.apache.org/ ) builds and tests 700 projects from
> source
> > each day. IIRC the classpath team run gump. might be able to dig out an
> url
> > if you're interested in seeing the current level of progress.
> >
> > in general, finding a way to generate EBUILDs from gump descriptors
> would
> > make available a lot of libraries and applications without extensive
> > effort.
> > a maven EBUILD plugin would be even better.
>
> ebuild isn't an acronym, so you don't need to capitalize it all ;)


looks better as EBUILD (especially as i don't know where the shift key is ;)


maybe need to fake an acronym for marketing purposes :)

But having a way to generate ebuilds from gump descriptor or maven
> project files would be intersting and all well and good... but someone
> would actually have to do the work to put it together. That person isn't
> likely me in the foreseeable future, unless someone has a deal on cloning.
>


just speculating out load ATM  (on the generation, not the cloning)

> apache has a lot of API implementations but they are scattered amongst
> > different projects. it would probably be generally a good thing if they
> > were
> > more easily accessible. fixing that would also be a big gain for a small
>
> > amount of effort.
>
> 'small amount of effort' for whom?


sorry - ASF hat on there :-/

actually providing an index of all available implementations in one place is
something that the ASF should really do. make things a little easier for
those folks downstream consumers looking for clean room implementations and
a lot easier for users. there's a lot of activity around DOAP ATM and this
fits in well.

Adding a lot of packages doesn't
> particularly sound like a small effort to me.

Another hurdle is that
> many projects are switching to maven for building, and as I describe in
> the project ideas, we aren't quiet ready to handle using it to build.


i'm not sure i understand why mavenization is such a hurdle. nearly anything
built with maven can be built with ant. (maven can generate an ant build
from the POM.) projects using techniques such as generation using custom
maven plugins aren't so easy but that's a definite minority.

(but that's not to say that building maven2 isn't a worthy exercise)

- robert

[-- Attachment #2: Type: text/html, Size: 5366 bytes --]