Re: Repository Reorg (Once More With Feeling)
On Mon, 19 Jul 2004 21:21:52 -0700, Martin Cooper wrote: (BTW, that's something I think we should develop a policy on, so that we're not seen as making arbitrary decisions in this area, but that's another topic entirely.) I think the decision would have to depend on who is going to maintain the glue. A case in point is the VelTools. There's some Struts glue that is currently being maintained there. I encouraged that since the people interested in the glue were members of the Velocity community. A volunteer shouldn't have to follow a DEV list to maintain code, they should maintain code because they are following a DEV list. :) Of course, that's changed a bit now, and we have VelStrutsTools people who hang out here now, so today it could go either way. In a volunteer organization, some decisions may seem arbitrary, since the volunteers can be arbitrary, and decisions without volunteers don't exist. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Reorg (Once More With Feeling)
On Mon, 19 Jul 2004 21:07:14 -0700, Martin Cooper wrote: One important question, though: Where are we doing 1.2.x development / maintenance? Are we leaving that in CVS and splitting off a new SVN repo for 2.0 development, or are we converting to SVN lock, stock and barrel? How about this: * On the roadmap, we reclassify Struts 1.3+ as Struts 2.0, and what-was 2.0 as 3.0. * We clear the 1.2.1 problem tickets, issue the 1.2.2 release, and vote whether it is GA or not. * We link the Acquiring page to the mirroring system. * We have infrastructure import the jakarta-struts CVS to an apache-struts SVN, but we put it all under a /v1 directory. * We continue the work we started in the private SVN under a /v2 directory in the apache-struts SVN. So, the top-level of struts-apache would look like /v1 /v2 /v3 And the branch Craig started for the core subproject would live under /v2/trunk/core And the 1.2.2 release would be at /v1/trunk/ If we needed to make any further releases in the 1.2.x series, we could do those from there. But let's ship a GA 1.2.2 first. Thoughts? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Reorg (Once More With Feeling)
Does this include having Struts 1.x, 2.x, and 3.x, for the Servlet 2.2, 2.3, and 2.4 respectively? Niall - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 1:15 PM Subject: Re: Repository Reorg (Once More With Feeling) On Mon, 19 Jul 2004 21:07:14 -0700, Martin Cooper wrote: One important question, though: Where are we doing 1.2.x development / maintenance? Are we leaving that in CVS and splitting off a new SVN repo for 2.0 development, or are we converting to SVN lock, stock and barrel? How about this: * On the roadmap, we reclassify Struts 1.3+ as Struts 2.0, and what-was 2.0 as 3.0. * We clear the 1.2.1 problem tickets, issue the 1.2.2 release, and vote whether it is GA or not. * We link the Acquiring page to the mirroring system. * We have infrastructure import the jakarta-struts CVS to an apache-struts SVN, but we put it all under a /v1 directory. * We continue the work we started in the private SVN under a /v2 directory in the apache-struts SVN. So, the top-level of struts-apache would look like /v1 /v2 /v3 And the branch Craig started for the core subproject would live under /v2/trunk/core And the 1.2.2 release would be at /v1/trunk/ If we needed to make any further releases in the 1.2.x series, we could do those from there. But let's ship a GA 1.2.2 first. Thoughts? -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]
Re: Repository Reorg (Once More With Feeling)
On Tue, 20 Jul 2004 06:53:04 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 19 Jul 2004 21:21:52 -0700, Martin Cooper wrote: (BTW, that's something I think we should develop a policy on, so that we're not seen as making arbitrary decisions in this area, but that's another topic entirely.) I think the decision would have to depend on who is going to maintain the glue. A case in point is the VelTools. There's some Struts glue that is currently being maintained there. I encouraged that since the people interested in the glue were members of the Velocity community. A volunteer shouldn't have to follow a DEV list to maintain code, they should maintain code because they are following a DEV list. :) Of course, that's changed a bit now, and we have VelStrutsTools people who hang out here now, so today it could go either way. We have precedents for dealing with this that seem to work fine: * File upload -- generic code in separate (Commons) package; glue in Struts * Chain integration -- same thing If the Tiles folks want to create a Struts-free distribution, two separate modules (generic and glue) are certainly possible. And, as far as I'm concerned, the generic one is welcome to stay here. In a volunteer organization, some decisions may seem arbitrary, since the volunteers can be arbitrary, and decisions without volunteers don't exist. :) -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Reorg (Once More With Feeling)
On Sun, 18 Jul 2004 13:15:45 -0700, Craig McClanahan wrote: Personally, I want to stay focused on the code part first, and would prefer someone more familiar with Maven and xml-html transformations would focus on the site module. What I'm thinking is that we should use an infrastructure similar to the Jakarta Commons. The site subproject would be all website, and serve as a portal to introduce people to the other subprojects -- the first and foremost being core. Each subproject would then carry it's own JavaDoc and user guide docs. So two things we would also need to work on would be the user guide xdocs for core and a site subprojects (all xdocs no src). What I'm been calling site corresponds to what Commons calls commons-build. But, I don't see a problem with pushing on and doing the JAR artifacts first and letting the docs follow. The core JAR compiled just fine for me (under Maven 1.0, thank you very much). Do we want to move the /branch/craigmcc-refactor/core out to /test/core to make it easier to see what has been done and what hasn't? I haven't tried this from the CLI, but it's pretty easy with Tortious. I note that we brought chain up from contrib to boot. Under first thing first, I might try to move commons-chain toward a GA this week, so that we don't have so many -SNAPSHOTS roaming around. :) I think that's mainly a Maven XDOC issue too. BTW, is it yet possible to put the Sun JSF JARs into a Maven repository for distribution, or does the license restrict that? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Reorg (Once More With Feeling)
On Mon, 19 Jul 2004 16:48:35 -0700, Craig McClanahan wrote: I was just following the usual conventions in the Subversion book, and am not attached to the location (svn move and svn copy are * sweet*). But first, a question ... if we are thinking about actually keeping the end result, wouldn't it make just as much sense to do the real work on Apache's svn server? At this point, I was thinking of drafting what we were going to do on the private server, and once we were sure it was what we wanted, then do it once more with feeling on the Apache SVN server. [Things always go *much* faster the second time around :)] Or, maybe even just get a tarball of the end-result and hand that over to [EMAIL PROTECTED] But, if everyone is ready to have at it, we could just ask infrastructure@ for a SVN repository now and be done with it. I'm always ready to cut to the chase. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Reorg (Once More With Feeling)
On Mon, 19 Jul 2004 20:05:14 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 19 Jul 2004 16:48:35 -0700, Craig McClanahan wrote: I was just following the usual conventions in the Subversion book, and am not attached to the location (svn move and svn copy are * sweet*). But first, a question ... if we are thinking about actually keeping the end result, wouldn't it make just as much sense to do the real work on Apache's svn server? At this point, I was thinking of drafting what we were going to do on the private server, and once we were sure it was what we wanted, then do it once more with feeling on the Apache SVN server. [Things always go *much* faster the second time around :)] Or, maybe even just get a tarball of the end-result and hand that over to [EMAIL PROTECTED] This (the former) is what I was thinking, too. When we're ready to roll, we can have infra@ create an SVN repo and cvs2svn our existing repo over to that, and then make the changes we know we want to make to get us in shape for 2.0. One important question, though: Where are we doing 1.2.x development / maintenance? Are we leaving that in CVS and splitting off a new SVN repo for 2.0 development, or are we converting to SVN lock, stock and barrel? I can see pros and cons to both approaches, although I think the balance tips in favour of the lock, stock and barrel approach. But, if everyone is ready to have at it, we could just ask infrastructure@ for a SVN repository now and be done with it. I'm always ready to cut to the chase. :) There's no harm in going ahead and getting the SVN repo set up now, whether or not we continue to play in our playground prior to making sweeping changes in the new repo. All we need to decide is whether or not CVS is in the state we want it in for the switchover. Once it is, we'll just want to label that point and freeze checkins until the SVN repo is ready. I'm happy to work with Fitz and the other infra@ folks to get our SVN repo up and running once we've decided what we want to do. -- Martin Cooper -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]
Re: Repository Reorg (Once More With Feeling)
On Sun, 18 Jul 2004 08:52:21 -0400, Ted Husted [EMAIL PROTECTED] wrote: 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. +1. Having a clean core is the single most important thing to get right here. Once core is up, people could even start work on some of the new subprojects, like Scripting. They could, yes. However, we'd obviously want to encourage folks to help with bringing existing subprojects back on line in our new world, so that we can restore the current functionality. -- Martin Cooper -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]
Re: Repository Reorg (Once More With Feeling)
+1 to all of this. :-) One point about dependencies on 'core', though. It's seldom likely to be as clear cut as depending on core or not. For example, it's likely that, once we split out Tiles, there will still be some glue that depends on 'core', even if Tiles per se does not. Then the question arises of where the glue should live - here or as part of the glued-on project. ;-) (BTW, that's something I think we should develop a policy on, so that we're not seen as making arbitrary decisions in this area, but that's another topic entirely.) -- Martin Cooper On Sun, 18 Jul 2004 08:59:38 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Sat, 17 Jul 2004 17:06:44 -0700, Martin Cooper wrote: 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. If we want to call this Struts 2.x, that would be OK with me. Then, everything we slated for 2.x moves up to 3.x. (Which underscores the evil of framing development roadmaps around version numbers. The tail starts to wag the dog.) 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. If we want to move the minimum to Servlet 2.3 that would be OK with me too. Then we have Struts 1.x, 2.x, and 3.x, for the Servlet 2.2, 2.3, and 2.4 respectively. 7) I think we need a better term than 'module', since that's already taken in the context of Struts apps. ;-) I'd favor going back to referring these as subprojects and make subprojects artifacts the units of release. The idea being we can make a new release of struts-core without making a new release of struts-taglibs, and vice versa. 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. As subprojects, each of these would have their own documentation and Maven site. Struts-site would need only link to each subproject (or module). While this starts to have the look-and-feel of an umbrella project like the Commons it is NOT AN UMBRELLA project, since all the subprojects are dependant on the struts-core distribution. The latter might even be a rule. If a subproject is not dependant on struts-core, then it can be hosted elsewhere. So, for example, if we can spin-off Tiles so that it has no struts-core dependencies, then it wouldn't belong here. It could live in the Jakarta or Apache Commons, or SourceForge. -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]
Re: Repository Reorg (Once More With Feeling)
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]
Re: Repository Reorg (Once More With Feeling)
[snip] 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.) I'm playing in an experimental Subversion repository (to get used to svn's approach to branches, plus play with Maven some), and so far have gotten a core module that compiles clean. I had to leave out Tiles (should make Martin happy :-) as there are too many cross-imports. Other than that, the only changes needed were: * Migrate a few constants from o.a.s.taglib.Constants to o.a.s.Globals. * Remove the deprecated methods in RequestUtils and ResponseUtils that delegated to TagUtils (which, I believe, should stay in whatever module the tag classes themselves go in). I haven't migrated any tests yet ... that'll be next. Of course, we don't have very many tests that focus just on the core part, so it should be fairly easy. Personally, I want to stay focused on the code part first, and would prefer someone more familiar with Maven and xml-html transformations would focus on the site module. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Repository Reorg (Once More With Feeling)
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
Re: Repository Reorg (Once More With Feeling)
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
Re: Repository Reorg (Once More With Feeling)
Craig McClanahan wrote: * 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). I think there should be support for RiA and SoA in the new request processor, which is what the chain enables. Not many new HTML/HTTP apps will be constructed in '05 to be operated in '06, '07. So one could get a SOAP or similar type request and not have to refactor. I think that should be the main goal, have it work with RiA/SoA 1st and then look for a way how to make it backaward compatiable and support legacy html/html apps (since that is well known how those work). At worst, make an interface or mechanisam so that people can implement a protocol. (Also perform() got removed and Struts is still to mark beans and logic for depecation. And it be nice that a nightly build ships with a sample chain. And ... what happend to 1.2.1 as far as a download link from an html page with due note as to release level (red/yellow/orange)). .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
