You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Craig McClanahan <cr...@apache.org> on 2004/07/17 23:56:45 UTC
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
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Ted Husted <hu...@apache.org>.
> 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)).
All this has been done.
http://struts.apache.org/acquiring.html
We don't color-code our releases, but the levels we do use are mentioned.
Before GA goes final, we need a proper download.cgi page. But (first things first) the rest the infrastructure we need is in place and documented.
http://struts.apache.org/releases.html
On Sat, 17 Jul 2004 20:31:20 -0500, Vic Cekvenich wrote:
>�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.
Right now, we discussing infrastructure. This item (and the others) is another topic: what we are going to do once the infrastructure is in place.
Since our bandwidth is limited, let's keep the focus on infrastructure for now.
And speaking of bandwidth, I hear the church bells ringing .. so I'm off.
-Ted.
>�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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Vic Cekvenich <ce...@portalvu.com>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 20 Jul 2004 06:53:04 -0400, Ted Husted <hu...@apache.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Ted Husted <hu...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Martin Cooper <mf...@gmail.com>.
+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 <hu...@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Ted Husted <hu...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Martin Cooper <mf...@gmail.com>.
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
<cr...@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <hu...@apache.org>
To: "Struts Developers List" <de...@struts.apache.org>
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Ted Husted <hu...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Martin Cooper <mf...@gmail.com>.
On Mon, 19 Jul 2004 20:05:14 -0400, Ted Husted <hu...@apache.org> 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 infrastructure@.
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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Ted Husted <hu...@apache.org>.
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 infrastructure@.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Craig McClanahan <cr...@gmail.com>.
On Mon, 19 Jul 2004 19:25:02 -0400, Ted Husted <hu...@apache.org> wrote:
> 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".
>
That makes sense to me.
> 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 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?
> 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.
>
Sounds good ... I'll review it tonight, but don't think I have any
pending stuff to add to a 1.0 release of commons-chain.
> BTW, is it yet possible to put the Sun JSF JARs into a Maven repository for distribution, or does the license restrict that?
Unfortunately, that's still a problem at the moment ... what I do is
copy those kinds of JARs directly to my Maven repository. Had to
manually copy a commons-chain jar there as well, because my version of
"core" depends on it, until chain is released.
>
> -Ted.
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Ted Husted <hu...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Craig McClanahan <cr...@gmail.com>.
> [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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Martin Cooper <mf...@gmail.com>.
On Sun, 18 Jul 2004 08:52:21 -0400, Ted Husted <hu...@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Repository Reorg (Once More With Feeling)
Posted by Ted Husted <hu...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org