On Sat, 17 Jul 2004 14:56:45 -0700, Craig McClanahan wrote: > * Separate modules for independently releaseable artifacts. > > * Modules can depend on each other (i.e. pretty much all will > depend on core), but we should exercise caution if the dependency > tree gets deep ... complexity lurks here.
Just to be clear, the modules (or subprojects) can depend on each other's artifacts, but should not depend on each other's source code. > * The "core" module should have no view tier dependencies. So long as this point does not generate API changes to the classes within the core. > NOTE: Generation process for TLDs and associated docs should live > here, but the resulting docs will probably need to be imported into > "site" somehow. > (7) "site" -- Struts web site source > > Dependencies: None. > > All the usual xdocs stuff to create our website and the associated > documentation. Originally, Site was intended to cover what's on the outer-layer of the website now. Which is to say, NOT the User Guide. Each distribution can have it's own user guide. So the taglibs documentation would be in the taglibs distribution. > WDYT? I'd like to take advantage of the fact that I've got a > modicum of time available now, so I'd like to get going on this > stuff. After agreement, we could pretty easily split up the > modules and do lots of the prep work in parallel ... the only > synchronization issue will be getting core to compile, but even > though there are lots of classes this should be pretty > straightforward. We might want to start by getting the struts-core and struts-site building first. Site would have a number of "under-construction links at first, which would go away as each subproject came online. What's in the other subprojects then defined by what is not in the core. (And for now, when in doubt, let's leave something out. We can always put it back later.) Here's a metaphor to consider: Let's pretend we're jumping in the Way-Back machine and doing this for the first time. We want to have a clean core subproject upon which several other future subprojects can depend. So, as proposed, we start with the core, and then bring up the other subprojects independently, either in serial or parallel, as people lights lead them. Once core is up, people could even start work on some of the new subprojects, like Scripting. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
