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).
--jason
