* 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]
