|Craig McClanahan||Jul 17, 2004 2:56 pm|
|Martin Cooper||Jul 17, 2004 5:06 pm|
|Vic Cekvenich||Jul 17, 2004 6:30 pm|
|Ted Husted||Jul 18, 2004 5:51 am|
|Ted Husted||Jul 18, 2004 5:59 am|
|Ted Husted||Jul 18, 2004 6:01 am|
|Craig McClanahan||Jul 18, 2004 1:15 pm|
|Ted Husted||Jul 19, 2004 4:24 pm|
|Craig McClanahan||Jul 19, 2004 4:48 pm|
|Ted Husted||Jul 19, 2004 5:04 pm|
|Martin Cooper||Jul 19, 2004 9:06 pm|
|Martin Cooper||Jul 19, 2004 9:12 pm|
|Martin Cooper||Jul 19, 2004 9:21 pm|
|Ted Husted||Jul 20, 2004 3:52 am|
|Ted Husted||Jul 20, 2004 5:15 am|
|Niall Pemberton||Jul 20, 2004 6:52 am|
|Craig McClanahan||Jul 20, 2004 7:48 am|
|Subject:||Repository Reorg (Once More With Feeling)|
|From:||Craig McClanahan (crai...@apache.org)|
|Date:||Jul 17, 2004 2:56:23 pm|
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
Packages and Classes: org.apache.struts.actions.* org.apache.struts.plugins.* org.apache.struts.upload.*
(3) "taglib" -- Legacy non-EL based tag libraries
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
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
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.