A few comments: 1) I don't consider Tiles to be core Struts functionality at all, and would very much prefer to see it be its own module, or another part of 'addons'. Note that we've had numerous requests to make Tiles available unbundled from Struts, and in his session at JavaOne, David Geary explained how to use Tiles with JSF and without Struts. Plenty of people are building Struts apps without using Tiles, too, emphasising the fact that it really isn't core functionality.
2) Is this presuming a change of Servlet / JSP version dependencies? Otherwise I'm not sure how feasible it would be to move 'upload' to 'addons', because of all the wrapping and unwrapping we have to do for Servlet 2.2 compatibility. 3) This kind of repackaging seems fairly drastic as part of a point release, since it will affect how people download and build their Struts apps. But if everyone else is OK with that, I won't object. 4) This would probably need to wait for 2.x, but I'd like to get away from the 'strutsel' in the taglibs-el package name, and have it be perhaps 'struts.el' instead, so that all of Struts is in 'org.apache.struts'. More consistent, and easier for log config as well. 5) I'd like us to find some kind of plugin mechanism for the web site, so that the non-core modules had add their piece to the main site without a lot of dependencies. Not sure how that would work, off the top of my head, but I think it would be a good goal. 6) I'm not against moving to Maven, but I would like to note that if we put the same energy into improving the existing build system, instead of switching to a new one, the one we have wouldn't be as hard to use as people seem to feel it is... 7) I think we need a better term than 'module', since that's already taken in the context of Struts apps. ;-) -- Martin Cooper On Sat, 17 Jul 2004 14:56:45 -0700, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Here's another crack at trying to get us moving forwards on the > repository reorg. Given the feedback of our most recent discussions, > I'd like to focus on the following motivations for a particular decision > on the organization of the repository, followed by what seems to make > sense based on those motivations: > > * Use Subversion for the new repository (I've played enough to be sold). > > * Use Maven 1.0 for the build tool (we need to deal with > persistent user complaints about complexity of our build > process, plus enable independent module releases gracefully). > > * In general, follow Maven's recommendations for directory > layout on multi-module builds. > > * Continue to build 1.2.x releases off the old (jakarta-struts) > repository (taking the time pressure off on getting the new > architecture perfect the first time). > > * Focus the new repository on supporting 1.3.x development > (generally backwards compatibile, but using chain-based > request processor, adding support for portlet), in prep for > later migration to 2.x.x development (which might end up > in either separate modules or a separate repository -- too > early to tell at this point). > > * 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. > > * The "core" module should have no view tier dependencies. > > * There is no need for a separate JSP-specific module for TagUtils. > That class is tightly coupled to the legacy tag libraries, so it should > go in the same module. > > * We'll need to do some minor refactoring to optimize things after > the rearrangement, but that shouldn't delay getting started. > > * Each module (of course) includes its appropriate complement > of unit tests. > > Given the above, here's my suggestion for the top-level modules in the > initial repository, and the packages and classes that should be included > there: > > (1) "core" -- Core Framework > > Dependencies: > commons-beanutils > commons-chain > commons-digester > commons-fileupload > commons-logging > commons-resources (once graduated) > commons-validator > jakarta-oro (inherited from commons-validator) > > Packages and Classes: > org.apache.struts.Globals > org.apache.struts.action.* > org.apache.struts.chain.* > org.apache.struts.chain.legacy.* > org.apache.struts.chain.portlet.* (to be created) > org.apache.struts.chain.servlet.* > org.apache.struts.chain.util.* > org.apache.struts.config.* > org.apache.struts.config.impl.* > org.apache.struts.tiles.* > org.apache.struts.tiles.actions.* > org.apache.struts.tiles.beans.* > org.apache.struts.tiles.definition.* > org.apache.struts.tiles.xmlDefinition.* > org.apache.struts.util.* > org.apache.struts.validator.* > org.apache.struts.validator.validwhen.* > > NOTE: Plan on migrating to commons-resources in 1.3 time frame. > > NOTE: Should end up with a single integrated request processor chain > for tiles/nontiles. > > NOTE: Should end up with request processor chain that works in portlet > environment, providing adapters to call 1.x compatible Action methods. > > (2) "addons" -- Standard generic add-in functionality > > Dependencies: core > > Packages and Classes: > org.apache.struts.actions.* > org.apache.struts.plugins.* > org.apache.struts.upload.* > > (3) "taglib" -- Legacy non-EL based tag libraries > > Dependencies: core > > Packages and Classes: > org.apache.struts.taglib.* (i.e. the TagUtils class) > org.apache.struts.taglib.bean.* > org.apache.struts.taglib.html.* > org.apache.struts.taglib.logic.* > org.apache.struts.taglib.nested.* > org.apache.struts.taglib.nested.bean.* > org.apache.struts.taglib.nested.html.* > org.apache.struts.taglib.nested.logic.* > > NOTE: Generation process for TLDs and associated docs should live here, > but the resulting docs will probably need to be imported into "site" > somehow. > > (4) "taglib-el" -- Legacy EL-based tag libraries > > Dependencies: core, taglib > > Packages and Classes: > org.apache.strutsel.taglib.bean.* > org.apache.strutsel.taglib.html.* > org.apache.strutsel.taglib.logic.* > org.apache.strutsel.taglib.tiles.* > org.apache.strutsel.taglib.utils.* > > (5) "faces" -- Struts-JSF integration > > Dependencies: core > > Packages and Classes: > org.apache.struts.faces.* > org.apache.struts.faces.application.* > org.apache.struts.faces.component.* > org.apache.struts.faces.renderer.* > org.apache.struts.faces.tagib.* > org.apache.struts.faces.util.* > > NOTE: The only components that should be included are those that have > direct analogs to legacy Struts tags (to easy conversion). General > purpose JSF components (if any) should go elsewhere. > > (6) "examples" -- Example Struts-based web applicatons > > All the existing example applications from core, tiles, struts-el, > struts-chain, struts-faces, ... *except* documentation, which gets > subsumed into the "site" module. May need to make sub-modules here; > remains to be seen. > > (7) "site" -- Struts web site source > > Dependencies: None. > > All the usual xdocs stuff to create our website and the associated > documentation. > > 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. > > Craig > > --------------------------------------------------------------------- > 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]
