gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject A Few Plans
Date Fri, 18 Jun 2010 08:15:13 GMT
Hi,

I just wanted to share a few plans I have short/midterm.  Feel free to
comment, pick tasks or add wishes.

Honestly I have no idea how we could deal with the ever increasing build
times as Gump grows, apart from some sort of distributed Gump which I
wouldn't want to build on top of the current code base (I'd rather think
in a tuple spaces architecture like Mnesia and Erlang or JavaSpaces and
anything on the VM).

mvnrepoproxy:

  - move the mapping of URL prefix to real repository into a properties
    file passed in on the command line.  This way we can maintain the
    list of repositories we proxy in a single place which would create
    the properties and mvn settings files.

Python:

 - go further with generalizing outputs, add POM as a type of output

 - allow outputs of different types to share the same id (jar and POM
   for example)

 - only publish POMs and JARs to the proxy

 - maybe add a mvn-install builder to simplify things like the camel-pom
   where the ids could be taken from the project/workspace and the
   version might even be read from the POM directly.

 - maybe add a RAT builder

 - generalize junitreport so it can be used to publish other types of
   reports (like RAT's)

Metadata:

 - ask the Forrest and Lenya communities which parts of Cocoon 2.x they
   need, remove the Cocoon reactor and only build the parts needed,
   finally start building Forrest and Lenya again.

 - regularly publish POMs with the JARs so depending projects will pick
   up the new POMs as well as the new code.

 - split the Axis2 reactor.  Reactor builds are simpler to maintain but
   fail for too many reasons IMHO.

 - the next logical projects to add (judging from dependencies
   downloaded by Maven) would be XBean (somewhere in Geronimo) and
   Felix.  I'm afraid Felix and OSGi would mean a whole new can of
   worms, though.

 - try to get some communities engaged again, in particular it would be
   nice if we could get the Velocity and Portals communities to sort out
   the Velocity bridge problem.
   I'm not sure I have the energy required to do that right now.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message