Of course, this is a case where you need a separate module. IMHO it is a bad sign when you have to do this - maybe you could use a different package name instead of same class names, or refactor a bit so you don't depend on the class name. But if for any reason you have to use the same classname, then use a different module for that code. JDK does this for platform-specific things in IO, awt, etc.
I think this should be the exception, not the rule. Costin On 2/28/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > I would prefer to keep the module source tree separate. > For example, the "ha" module (cluster2) uses the same classes as the > "cluster", but they are being enhanced for performance and modularity. > merging all this into one tree would be a pain in the neck. > > Filip > > > Costin Manolache wrote: > > On 2/28/06, Mark Thomas <[EMAIL PROTECTED]> wrote: > > > >> Remy Maucherat wrote: > >> > >>> Hi, > >>> > >>> I think it is time to decide how the source repository is going to be > >>> organized, with the questions being: > >>> - how many source folders do we need (Costin wanted one, while others > >>> like Jacob seem to want "modules") ? > >>> - do we continue to use Ant ? > >>> - etc > >>> > >> I am +0 on any changes. > >> > >> Assuming some changes are made, there needs to be some thought given > >> to where in the source tree we put the trunk/branch/tag structure > >> before we start moving things around. > >> > > > > > > Well, single source tree means all source will be in one svn repo. > > > > My understanding is that you can label/tag/branch subdirs - and that a > > tag is cheap enough that you can do it for the entire tree. > > > > I think it's better to tag the entire tree - not just the component, > > so it's easier to reproduce ( since it has deps, etc ). That seems the > > current practice. > > > > > > > > > > > > > > > >> There have also been various comments made that different components > >> may be released on different release cycles. If this route is > >> followed, there needs to be a reasonably clear idea of what these > >> components might be as this will also have an impact on the best way > >> to structure the source. > >> > >> > > > > I don't think the source structure should be related to release structure. > > > > >From one source tree you can generate as many jars and packages as you > > want, in any structure or variation. > > > > Things like 'el' or 'jspc' or maybe cluster could chose to release - > > either as a jar, or as a .tar.gz or anything else. Or maybe not - that > > should be an independent decision from source tree layout or build > > mechanism. > > > > Costin > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
