On Thu, 2006-03-09 at 11:38 -0600, Stan Silvert wrote: > I assume this was all discussed before, but I'm glad the discussion has > been raised again. I have also been having trouble understanding what > is going on and why. > > My current understanding is as follows: > 1) There is some common code that both core and tomahawk (and others?) > use. > 2) We want core and tomahawk to have different release schedules. > 3) We want tomahawk to be usable with the RI > 4) The decision was to let the common code's source become bound to > each project at build time by a global package name change. > > Please correct me if I have this wrong.
Yes that's correct. And yes there are "others"; tobago and ADF-faces are likely to use shared as well. It's effectively a "poor man's version" of c# (well, technically CLR) library versioning, so that there aren't version conflicts over shared code. In particular, consider the case where core (including shared code) is distributed with a J2EE servers, a webapp includes tomahawk, tobago or adf, and parent-first classloading is selected. > > This is an interesting approach, but it is also one I have never > encountered before. I'm surprised nobody has come forward and said, > "Don't do that!! We did that on X project and it caused Y problems." > So, maybe this approach has merit. Time will tell. Well, it's not so different from having a UML model or database model from which code is generated at compile-time. That's a well-known approach. > > Besides the issues that have been raised in this thread, the thing I > have worried about is how we can recreate a release. Since the modified > common source is not checked in, how would you recreate a tomahawk build > with the proper version of the common source? The shared module which contains the original (pre-modification) source code gets tagged at the same time as the library that uses it. So when rebuilding that tagged version of the library you just apply the "refactor" build step to the tagged version of the shared module. Again, this is just like an approach which generates code from a "model"; tag the model when you tag the code that uses it. Converting model->code is part of the build process. Note that subversion's flexibility allows a directory to point to code anywhere in the repository, so a single tag dir can conveniently capture both the module code and the associated shared code together. > > Another thing I was wondering. Why not make a clean break right now? > That is, let each project have its own version of the common source that > gets checked in today? Then they can be maintained independently. Exactly because they have to be maintained independently. It's not nice to have to add a bugfix to each "copy". And if each project has its own potentially divergent copy, where do the unit tests for the shared code go? Right now, each copy is guaranteed to be the same, so having the unit tests only in shared should be ok. One disadvantage of shared is that every project gets a copy of the *whole* of shared even when it only uses a subset. However given that we are talking about code running in containers here the extra few kilobytes are not likely to be significant. Cheers, Simon
