geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: Java EE 5.0
Date Wed, 08 Nov 2006 15:39:34 GMT

On Nov 7, 2006, at 7:16 PM, David Jencks wrote:

> My objection to putting the jee5 work into a branch is that it's  
> not a branch!   It is currently and IMO will always remain  
> additional code that can happily run side by side with all our  
> current code.  Creating the jee5 workspace is not going to involve  
> copying any existing geronimo server branch: its going to involve  
> adding new modules for new functionality.  After reading ken's  
> comments I agree that keeping it in the sandbox carries an unwanted  
> implication that it's not ready for prime time.

I agree with David that we should not be putting a "sparse" branch in  

I don't necessarily agree with "will always remain additional code  
that can happily run side by side with all our current code", but I  
think that can be a future discussion...

IMO, "sandbox" development does not imply "toy". It does imply  
"temporary location" or "experimental work" and sometimes "toy". If  
modules, configs, and assemblies can be built reliably from a  
sandbox, then I don't think that the fact that the code is in  
"sandbox" is a significant barrier. The code will be important, if  
those working on it make it so...

If there's too much stigma associated with sandbox, then let's  
establish a convention for hosting "sparse" branches (e.g. server/ 
sparse/jee5 or server/sparse/jpa, etc). This all assumes that a  
sparse development branch is a viable solution...

Seems useful to review the options:

1) Create a full branch (e.g. server/branches/jee5) which is a copy  
of current trunk. And develop there. Once server/branches/1.2 has  
been created. server/branches/jee5 could be merged onto trunk. The  
problem with this approach is that the overhead of merging vs.  
problem resolution. Either you work diligently to keep the codebases  
in sync, or you potentially debug problems on two codebases, and pay  
merge costs later...
2) Develop in a sparse source tree. The source tree only contains the  
new code that is being developed. The hope is that this reduces the  
overhead of merging changes. However, it will also complicate the  
build process -- it seems that Joe has been having problems building  
using this technique.
3) Create server/branches/1.2, now. This seems pretty much equivalent  
to 1). Similar merging concerns... Most changes made to branches/1.2  
will require merging onto trunk.

If people can make reasonable progress on jee5 using 2), then that  
seems as close as we'll get to a win-win...


View raw message