geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: A couple of modest proposals
Date Sat, 12 Feb 2005 04:09:28 GMT
	I think one of the problems is that dependencies go both ways.  
Changes to Jetty may require (or be required by) changes to the Jetty
configuration and deployment code in Geronimo.  But OpenEJB deployment
code is in OpenEJB and depends heavily on Geronimo, not to mention the
OpenEJB assembly process.  I think we'd have to sort out what type of code
should go where in order to make easy and consistent non-uberbuilds 

	And the more I think about it, the more I think we'd want to push 
as much as possible out to the projects.  Provide stable GBean features 
and interfaces in Geronimo, and put the Geronimo Jetty deployer in Jetty, 
so the Geronimo libs can be relatively stable and all the changes to get 
Jetty working would be made on the Jetty side (and only on the Jetty 

	Still, if we did that and depended on only pre-packaged Jetty
builds, it would be quite hard to get a Geronimo build of the latest and
greatest.  So I guess to my mind, easy builds are opposed to cutting-edge
Geronimo assemblies.  Personally, I wouldn't mind easier and more stable
builds, but I suspect everyone who's actively TCK testing would freak.


On Fri, 11 Feb 2005, Jeremy Boynes wrote:
> I would like to see what you check out of SVN at Apache build on its 
> own, every time, without needing to check out HEAD from several other 
> projects; we should be able to use published releases or, if necessary 
> (and temporarily), SNAPSHOTS.
> The uber-build should be considered convenience for Geronimo developers 
> for use when, and only when, they are doing stuff that requires changes 
> in multiple projects. If we have clear APIs this should be relatively 
> infrequent.
> Needing to build multiple projects concurrently from HEAD is a serious 
> PITA for most users of the project and we need to stop pissing them off.
> Having said that I don't want us to disappear into another month long 
> period of disruption as we refactor the build yet again. We should plan 
> out how we, the whole community, would like it to work and get it right.
> --
> Jeremy

View raw message