On Tue, 23 Mar 2004, Ted Husted wrote: > On Tue, 23 Mar 2004 18:16:53 +0000, Peter A. Pilgrim wrote: > > 1) I think you should keep the same elementary structure > > Moving forward, we have already decided to use Maven as our build environment, which > addresses a number of consistency and structural issues. We had also decided to > distribute non-core components, like the taglibs, independantly. Independant > releases lead to the idea of independant modules. Modules also seem like a good way > to handle bringing on some of the more popular extensions.
As Joe mentioned, we would still need somewhere to put the shared files, such as Maven's project.xml, the LICENSE and NOTICE files, the KEYS file, etc. In a single-module world, those would live at the top level, just as they do now. In a multi-module world, those should be in another module solely for that purpose. (I certainly wouldn't want a build file that knows about all the individual modules living in core, or any other independently buildable module.) > So, the "site" subproject would be an overview of the Struts project, and then link > to the subprojects (including core) for more detail. > > A contributor mentioned wanting a single JAR. I don't think that's an itch any of > Committers are desparate to scratch. And, if anyone did, it's been pointed out that > Ant can be used to burst and combine JARs. Anyone could do that. > > I don't think anyone wants to build a single Struts WAR, especially since we already > have multiple example applications in their own WARs. I don't want a single jar or a single war, but I do want to be able to run *one* build process to get all of the pieces to build. I also don't relish the thought of having to maintain multiple Gump descriptors, either. > At this point, we're down to whether to organize the subprojects (units of release) > into multiple modules or around top-level-directories in a single module. Yep, that's exactly where we are. ;-) Here's what I think are the pros and cons of each approach: One module, multiple directories: + One checkout grabs it all (but an alias can reference multiple modules). + Natural place (top level) for all cross-"module" files. (See above.) + Labelling and branching across "modules" is one CVS command. + Don't need CVS admin karma (i.e. Craig) to create new "modules". - Harder (?) to check out only portions of the overall code base. Multiple modules: + Easier (?) to check out only portions of the overall code base. + May scale better as we accumulate extensions. - Need an extra module for cross-module files. - Clutters up the Apache CVS repository. The reason for the question marks is that this issue seems to have been implied, but it's not really true. The difference is literally a single character - 'cvs co struts-core' versus 'cvs co struts/core'. The labelling issue is an interesting one. Someone (hi Ted! ;) is going to argue that we'll want to label each "module" independently because we'll want to release them independently, and I agree with that. But I also think that there will be points in time that we'll want to label or branch the entire code base, which will be easier to do across a single module. So, there are pros and cons both ways, of course. Now we just need to make a decision and move on it. ;-) -- Martin Cooper > My only feeling is that should we start inviting some of the popular extensions to > join us, the module approach seems like it would scale better. > > -Ted. > > > > > > --------------------------------------------------------------------- > 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]
