geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: One version for specs
Date Mon, 02 Oct 2006 19:49:36 GMT
On Oct 2, 2006, at 10:35 AM, Aaron Mulder wrote:
> However, I still don't think this is a very good approach.  Our specs
> tree will continue to expand with new JSRs and J2EE releases,
> especially if we go with the earlier intent of making it a home for
> all Apache Java spec packages.  I don't like the idea that I'll have
> 10 versions of EJB 2.0 in my local repository, all with the same code,
> and with different projects potentially using different revs depending
> on how aggressive they are about needing new unrelated specs.

Growing spec modules is actually a case to simplify and use one  
version rather than the opposite... especially for cases when new  
specs depend on other specs.

> I think in the end, I'd rather have separate builds for separate specs
> and an auto-generated or frequently updated web page with a table
> listing all the specs with their JSR reference and the latest released
> and snapshot versions of each.  If I had to check that page for the
> right numbers for each spec when building a new POM, that would be a
> pretty close second to just having all of them use the same number
> (which I'd still have to look up each time anyway).  And it would mean
> copy and paste dependencies on old specs like EJB 2 would be more
> likely to be up to date.

IMO the one-version for users, which is the point I am getting most  
of of this reply, is a side-effect of a simple process for developers  
(us) to manage a growing codebase of specs.

Separate builds for specs does not really solve any of the problems  
related to maintenance which I have been trying to explain in more  
detail.  The only problem which separate builds solves is that it  
reduces (not eliminates) re-releases of spec modules hat have had no  
_code_ change (could be a header change, or a config change, or a  
documentation change though).

The amount of effort required to maintain a system like this far  
outweighs the advantages of _purity_ (or semi-purity when you  
consider the non-code changes described above).


View raw message