Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)
At 5:24 PM -0800 3/21/04, Craig R. McClanahan wrote: I think the presentation-tier-independent things about Tiles (like mapping forwards to definitions) should be built in to the core, so there isn't any such thing as a separate TilesRequestProcessor (or a separate chain or whatever). In turn, this probably means we might need an API abstraction that alternative presentation tier technologies can use to integrate themselves into the underlying support. I managed to make Tiles work with struts-chain with a single pre-processor Command. It basically looks up a tiles definition and replaces the ForwardConfig returned from an action with its own that has a path which RequestDispatcher to which can forward. But it still uses the TilesPlugIn... is that part of what you think should be moved up into the core? Or do you think even the single Command is not the best future implementation? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)
Quoting Joe Germuska [EMAIL PROTECTED]: At 5:24 PM -0800 3/21/04, Craig R. McClanahan wrote: I think the presentation-tier-independent things about Tiles (like mapping forwards to definitions) should be built in to the core, so there isn't any such thing as a separate TilesRequestProcessor (or a separate chain or whatever). In turn, this probably means we might need an API abstraction that alternative presentation tier technologies can use to integrate themselves into the underlying support. I managed to make Tiles work with struts-chain with a single pre-processor Command. It basically looks up a tiles definition and replaces the ForwardConfig returned from an action with its own that has a path which RequestDispatcher to which can forward. But it still uses the TilesPlugIn... is that part of what you think should be moved up into the core? Or do you think even the single Command is not the best future implementation? I'll express my goals for this from a couple of perspectives: From the user's perspective, the fact that I'm using Tiles (or not) should not require anything extra in the config (other than adding the definitions of the tiles themselves, of course). This probably implies that the configuration data migrates into struts-config.xml as well. From the Struts developer perspective, I don't want to have to maintain two request processors (or really even two command chains) -- the standard chain should handle requests whether or not you reference a Tile. So, if your command that looks up the Tiles definition works on non-Tiles requests as well, we can just build it in to the standard chain and call it good. Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. Steve -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: March 20, 2004 9:44 PM To: Struts Developers List Subject: Re: branching 1.2 and 1.3 and CVS reorg for TLP status On Sat, 20 Mar 2004, Craig R. McClanahan wrote: Quoting Joe Germuska [EMAIL PROTECTED]: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... I think there's a lot of merit in rationalizing the directory structures as part of the move to TLP-ness. Assuming we don't move to Subversion right now (see other thread), the move is effectively a CVS repo rename by the infrastructure folks, lock, stock and barrel. Any rationalisation is totally up to us. If we want to break up our existing repo, we have a couple of options: 1) One top-level 'struts' repo that we break down as we see fit. This option leaves everything in our control, since, as far as infrastructure@ is concerned, there is only one CVS repo. 2) Multiple top-level repos, one of which is a renamed version of our current repo, and the remainder of which are new empty repos. We would then migrate pieces of our current repo out to the new repos. 3) Same as (2) above, except that we don't ask for a repo rename, but just new repos, and we migrate everything ourselves to the appropriate new repo. While (3) is the cleanest insofar as we wouldn't have leftovers in the Attic of the renames repo, it's also a huge amount of work for us, and runs the risk of forgetting things. My preference is for (1). It is the simplest approach, and will allow us to move things around however we see fit, without having to decide up front which other repos we might want. If, at some point, we decide we do want other top-level repos, we can request them at that time. Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. There are ways to preserve history, but I suspect there will be difficulties if we decide to split up what has been a single repository (jakarta-struts) into per-subpackage repositories. A guru on CVS would definitely be useful here. A CVS repo rename will preserve all of our history, obviously. After that, I can take care of preserving history whatever we decide to do (as long as we stay with CVS ;). It's slightly easier if we have only one repo, but it can still be done across repos. -- Martin Cooper I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. I'm going to focus some energy as well on commons-chain and struts-chain now that JavaServer Faces is done. Joe 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. The problem is that is that we already have the simplest thing. And, if we want multiple Maven-based products with independent release cycles, then what we have won't work. :) We were already getting ready to change things around. And we *do* need to move things around if we are ever going to get away from a monolithic Struts to a modular Struts, were people can assemble the Struts platform they need for their application. If not now, then when? The resolution we submitted says we're suppose to rationalize Struts, so let's rationalize :) My preference would be to have a separate repository for each subproject. Each subproject represents a coherent software product or deliverable with its own release cycle. Another way of thinking of the subprojects/products is as Maven artifacts. As mentioned elsewhere, all Struts Committers can have access to all repositories, and all PMC Members have voting rights over all subprojects. I'd suggest that we setup a legacy jakarta repository that would be frozen. Directories could then be moved over to their new repositories, either from a second copy of the original repository or from a remote copy. The subprojects/repositories/artifacts/products I had in mind were: * core * taglib * app * opt-legacy * opt-el (or jstl) * opt-faces * opt-sandbox Here's some possible path-to-repository mappings. Later entries assume earlier entries were already moved. [taglib] /src/share/o.a.s/taglib - /src/o.a.s/taglib [app] /src/example,examples,tiles-docmentation - /src/ /web/ - /webapp/ [opt-el] /src/contrib/struts-el - / [opt-legacy] /src/contrib/struts-legacy - / [opt-faces] /src/contrib/struts-faces - / [opt-sandbox] /src/contrib/ - / [core] /src/share - core repository /src / - / Something like Struts 2.0 development might start out in the opt-sandbox and then move its own repository (like core2) once we had consensus. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004, Ted Husted wrote: On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. The problem is that is that we already have the simplest thing. And, if we want multiple Maven-based products with independent release cycles, then what we have won't work. :) We already have the simplest thing in terms of one repo, but we have far from the simplest thing when it comes to organising within that repo. The point I was trying to make with (1) is to distinguish between organising using multiple repos versus organising within one repo. For example, if we do what you suggest below, and have 7 separate CVS repos, we will face a number of problems, as I see it: a) We will not make friends with the infrastructure folks. Each time we add a new committer, they will have to add 7 separate avail entries with that account. b) People will need to do 7 separate 'cvs update' invocations to get all of the latest code. That just doesn't seem practical to me. c) It's not clear to me that the Maven reactor could be made to work across multiple repos. And even if it could, which repo would the Maven files live in? d) Any multi-repo build would have to make assumptions about the location of the other repos on the local disk. It would be reasonable to assume that they are peers within the same directory, but that is an assumption that we would have to make. e) Web site maintenance is going to be, um, challenging. We would actually need an 8th repo for site-wide documentation, and then we'd need to have some tools to avoid having to do 8 separate 'cvs update' invocations to update the entire site on www. f) Any time we want to add something new (e.g. opt-foo or core2), we would need to go back to infrastructure and ask for yet another repo. I see little advantage of all those separate repos over just one repo, since that one repo could be organised in exactly the same way. In other words, why use separate repos over something like this: struts/ core/ taglib/ app/ opt-legacy/ opt-el/ opt-faces/ opt-sandbox/ site/ or even this: struts/ core/ taglib/ app/ opt/ legacy/ el/ faces/ sandbox/ site/ Actually, I'm not sure that a sandbox should be under 'opt' at all. I could see us using a separate repo for that, since there is precedent in both Commons and Taglibs. I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. The reason I've changed my mind since yesterday about 2 repos versus 1 (ignoring the sandbox for the moment) is that I realised that all of the CVS shuffling we want to do will make it very hard, if not impossible, to continue to work on older (pre-shuffle) versions of the product. One other minor comment: I'd prefer to use something like 'archive' over 'legacy', since the latter has a more negative connotation, in my mind at least. But I won't make a big deal of it if other people prefer 'legacy'. ;-) -- Martin Cooper We were already getting ready to change things around. And we *do* need to move things around if we are ever going to get away from a monolithic Struts to a modular Struts, were people can assemble the Struts platform they need for their application. If not now, then when? The resolution we submitted says we're suppose to rationalize Struts, so let's rationalize :) My preference would be to have a separate repository for each subproject. Each subproject represents a coherent software product or deliverable with its own release cycle. Another way of thinking of the subprojects/products is as Maven artifacts. As mentioned elsewhere, all Struts Committers can have access to all repositories, and all PMC Members have voting rights over all subprojects. I'd suggest that we setup a legacy jakarta repository that would be frozen. Directories could then be moved over to their new repositories, either from a second copy of the original repository or from a remote copy. The subprojects/repositories/artifacts/products I had in mind were: * core * taglib * app * opt-legacy * opt-el (or jstl) * opt-faces * opt-sandbox Here's some possible path-to-repository mappings. Later entries assume earlier entries were already moved. [taglib] /src/share/o.a.s/taglib - /src/o.a.s/taglib [app]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004, Martin Cooper wrote:
On Sun, 21 Mar 2004, Ted Husted wrote:
On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote:
Option 1 works for me. Simplest thing that could possibly work. As
you've said, we can always change things around later.
The problem is that is that we already have the simplest thing. And, if we want
multiple Maven-based products with independent release cycles, then what we have
won't work. :)
We already have the simplest thing in terms of one repo, but we have far
from the simplest thing when it comes to organising within that repo. The
point I was trying to make with (1) is to distinguish between organising
using multiple repos versus organising within one repo.
For example, if we do what you suggest below, and have 7 separate CVS
repos, we will face a number of problems, as I see it:
a) We will not make friends with the infrastructure folks. Each time we
add a new committer, they will have to add 7 separate avail entries with
that account.
b) People will need to do 7 separate 'cvs update' invocations to get all
of the latest code. That just doesn't seem practical to me.
c) It's not clear to me that the Maven reactor could be made to work
across multiple repos. And even if it could, which repo would the Maven
files live in?
d) Any multi-repo build would have to make assumptions about the location
of the other repos on the local disk. It would be reasonable to assume
that they are peers within the same directory, but that is an assumption
that we would have to make.
e) Web site maintenance is going to be, um, challenging. We would actually
need an 8th repo for site-wide documentation, and then we'd need to have
some tools to avoid having to do 8 separate 'cvs update' invocations to
update the entire site on www.
f) Any time we want to add something new (e.g. opt-foo or core2), we would
need to go back to infrastructure and ask for yet another repo.
I see little advantage of all those separate repos over just one repo,
since that one repo could be organised in exactly the same way. In other
words, why use separate repos over something like this:
struts/
core/
taglib/
app/
opt-legacy/
opt-el/
opt-faces/
opt-sandbox/
site/
or even this:
struts/
core/
taglib/
app/
opt/
legacy/
el/
faces/
sandbox/
site/
Another thought on this. When we get to Struts 2, I'd like to see us
remove all of the JSP-ness of Struts from the core, and also add some
degree of support for other presentation technologies, such as XSLT and
Velocity. So, instead of having 'taglib' where it is in the above tree, we
might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
Incidentally, where would Tiles land in all of this? In theory, it's not
tied to JSP, but rather to Servlets, so it might be applicable to some
other presentation technologies, but clearly not all.
--
Martin Cooper
Actually, I'm not sure that a sandbox should be under 'opt' at all. I
could see us using a separate repo for that, since there is precedent in
both Commons and Taglibs.
I am now leaning towards 3 repos myself:
struts-legacy
This is our current repo, renamed. I don't really care for this
name, but I can't think of anything better right now, and I hate
sticking numbers in repo names, because they become invalid
quite rapidly if they are associated with versions (unless we
start a new repo for each major version, a la Tomcat, but I
don't like that idea either, for CVS history reasons).
struts
This would be structured per one of the suggestions above.
struts-sandbox
A separate sandbox, a la Commons and Taglibs.
The reason I've changed my mind since yesterday about 2 repos versus 1
(ignoring the sandbox for the moment) is that I realised that all of the
CVS shuffling we want to do will make it very hard, if not impossible, to
continue to work on older (pre-shuffle) versions of the product.
One other minor comment: I'd prefer to use something like 'archive' over
'legacy', since the latter has a more negative connotation, in my mind at
least. But I won't make a big deal of it if other people prefer 'legacy'.
;-)
--
Martin Cooper
We were already getting ready to change things around. And we *do* need to move
things around if we are ever going to get away from a monolithic Struts to a
modular Struts, were people can assemble the Struts platform they need for their
application. If not now, then when? The resolution we submitted says we're suppose
to rationalize Struts, so let's rationalize :)
My preference would be to have a separate repository for each subproject. Each
subproject represents a coherent software product or deliverable with its own
release cycle. Another
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Martin Cooper said:
...
Another thought on this. When we get to Struts 2, I'd like to see us
remove all of the JSP-ness of Struts from the core, and also add some
degree of support for other presentation technologies, such as XSLT and
Velocity. So, instead of having 'taglib' where it is in the above tree, we
might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
interesting. i've wondered before if the VelocityStruts code (but not all of
Velocity Tools, of course) might be better off in Struts land. something to
keep in mind i suppose.
Incidentally, where would Tiles land in all of this? In theory, it's not
tied to JSP, but rather to Servlets, so it might be applicable to some
other presentation technologies, but clearly not all.
Tiles works great for us, and we are able to use it in such a way that we can
mix and match JSP and Velocity tiles. i definitely think Tiles can and should
avoid dependence on any particular presentation technology.
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
At 10:55 AM -0800 3/21/04, Martin Cooper wrote: I see little advantage of all those separate repos over just one repo, since that one repo could be organised in exactly the same way. In other words, why use separate repos over something like this: I was trying to figure out what people meant by multiple repositories. I'm with Martin here. We don't need multiple repositories; I think we can organize a single repository in such a way that achieves the same goal with less administrative overhead. I do see some value to having struts-legacy distinct from struts (and have no strong opinion regarding archive vs. legacy). Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 12:05:44 -0800, Nathan Bubna wrote:
Martin Cooper said:
..
Another thought on this. When we get to Struts 2, I'd like to see
us remove all of the JSP-ness of Struts from the core, and also
add some degree of support for other presentation technologies,
such as XSLT and Velocity. So, instead of having 'taglib' where
it is in the above tree, we might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
interesting. i've wondered before if the VelocityStruts code (but
not all of Velocity Tools, of course) might be better off in Struts
land. something to keep in mind i suppose.
At this point, I'd be in favor of that. :)
I originally encouraged setting up VelocityStruts under Velocity, since the had a
broader base than Struts. (And projects like Maverick proved that to be so.)
Developing the Struts Toolset under Apache Struts might be a good idea now, especially
as we move into a 2.0 timeframe. I think exposure to the Velocity notion of Tools
would be a good thing for Struts developers.
Personally, I think it would be great if Velocity went TLP and brought N-Velocity in
under Apache. Especially now that HTTPD is moving toward adding .NET support.
But, that's just me.
Incidentally, where would Tiles land in all of this? In theory,
it's not tied to JSP, but rather to Servlets, so it might be
applicable to some other presentation technologies, but clearly
not all.
Tiles works great for us, and we are able to use it in such a way
that we can mix and match JSP and Velocity tiles. i definitely
think Tiles can and should avoid dependence on any particular
presentation technology.
Agreed. It might be a good idea of thinking of Tiles as a subproject, especially since
people may want to use it with JSF.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 10:55:00 -0800 (PST), Martin Cooper wrote: I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. This would be fine with me. Checkout granularity cuts both ways. If you are actually working in all aspects of a project, then it's more checkouts. If you are not, then you spend more time checking out code that you don't care about. (Commons is getting to be a chore these days.) My experience with multi-project Maven builds is that its not difficult so long as the JARs are placed in a local repository where other Maven builds can find them. But either way works, it's all good. My suggestions were colored by experience in environments like SourceForge where these sort of things are automated and easy to do. But, if a minimum number of repositories will make it easier for infrastructure, then, absolutely, I'm all for that. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 11:50:27 -0800 (PST), Martin Cooper wrote: Incidentally, where would Tiles land in all of this? In theory, it's not tied to JSP, but rather to Servlets, so it might be applicable to some other presentation technologies, but clearly not all. Yes, it might be a good idea to bring Tiles and Validator up as top-level directories. We might want to think about ways that other frameworks, like JSF, could use these without have to buy into the whole 900lb Struts gorilla. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Quoting Martin Cooper [EMAIL PROTECTED]: On Sun, 21 Mar 2004, Ted Husted wrote: On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. The problem is that is that we already have the simplest thing. And, if we want multiple Maven-based products with independent release cycles, then what we have won't work. :) We already have the simplest thing in terms of one repo, but we have far from the simplest thing when it comes to organising within that repo. The point I was trying to make with (1) is to distinguish between organising using multiple repos versus organising within one repo. For example, if we do what you suggest below, and have 7 separate CVS repos, we will face a number of problems, as I see it: a) We will not make friends with the infrastructure folks. Each time we add a new committer, they will have to add 7 separate avail entries with that account. That turns out not to be the case, for at least two reasons: * A single avail line can be attached to multiple repositories (as is already true, for example, for Tomcat's multiple repos). * Infrastructure needn't be bothered with CVS karma issues anyway ... lots of folks (including me) can do that edit directly. b) People will need to do 7 separate 'cvs update' invocations to get all of the latest code. That just doesn't seem practical to me. At work our CVS admins have set up aliases so you can do a single cvs co or cvs update on an alias and get them all at once. Don't know how that works with IDEs that interact, but it certainly works sweetly from the command line. c) It's not clear to me that the Maven reactor could be made to work across multiple repos. And even if it could, which repo would the Maven files live in? I plead clueless on the Maven-related aspects of this, but have seen that the Geronimo folks seem to have a pretty good multi-subproject setup going (albeit from a single repository). d) Any multi-repo build would have to make assumptions about the location of the other repos on the local disk. It would be reasonable to assume that they are peers within the same directory, but that is an assumption that we would have to make. e) Web site maintenance is going to be, um, challenging. We would actually need an 8th repo for site-wide documentation, and then we'd need to have some tools to avoid having to do 8 separate 'cvs update' invocations to update the entire site on www. I think we should rip the website stuff out of the webapps anyway. f) Any time we want to add something new (e.g. opt-foo or core2), we would need to go back to infrastructure and ask for yet another repo. Nope ... just an additional name on the avail list, something that I (or anyone else with cvsadmin karma) can do. I see little advantage of all those separate repos over just one repo, since that one repo could be organised in exactly the same way. In other words, why use separate repos over something like this: struts/ core/ taglib/ app/ opt-legacy/ opt-el/ opt-faces/ opt-sandbox/ site/ or even this: struts/ core/ taglib/ app/ opt/ legacy/ el/ faces/ sandbox/ site/ Actually, I'm not sure that a sandbox should be under 'opt' at all. I could see us using a separate repo for that, since there is precedent in both Commons and Taglibs. I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. The reason I've changed my mind since yesterday about 2 repos versus 1 (ignoring the sandbox for the moment) is that I realised that all of the CVS shuffling we want to do will make it very hard, if not impossible, to continue to work on older (pre-shuffle) versions of the product. One other minor comment: I'd prefer to use something like 'archive' over 'legacy', since the latter has a more negative connotation, in my mind at least. But I won't make a big deal of it if other people prefer 'legacy'. ;-) I'd be happy with either the seven approach or the three approach. As you've concluded, I don't see how we can gracefully refactor and continue to work on the old code with only one. Maybe struts-original has better connotations? I'm also very willing to defer any decision to migrate to SVN ... CVS, for all its warts,
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Quoting Martin Cooper [EMAIL PROTECTED]:
On Sun, 21 Mar 2004, Martin Cooper wrote:
On Sun, 21 Mar 2004, Ted Husted wrote:
On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote:
Option 1 works for me. Simplest thing that could possibly work. As
you've said, we can always change things around later.
The problem is that is that we already have the simplest thing. And, if
we want multiple Maven-based products with independent release cycles, then
what we have won't work. :)
We already have the simplest thing in terms of one repo, but we have far
from the simplest thing when it comes to organising within that repo. The
point I was trying to make with (1) is to distinguish between organising
using multiple repos versus organising within one repo.
For example, if we do what you suggest below, and have 7 separate CVS
repos, we will face a number of problems, as I see it:
a) We will not make friends with the infrastructure folks. Each time we
add a new committer, they will have to add 7 separate avail entries with
that account.
b) People will need to do 7 separate 'cvs update' invocations to get all
of the latest code. That just doesn't seem practical to me.
c) It's not clear to me that the Maven reactor could be made to work
across multiple repos. And even if it could, which repo would the Maven
files live in?
d) Any multi-repo build would have to make assumptions about the location
of the other repos on the local disk. It would be reasonable to assume
that they are peers within the same directory, but that is an assumption
that we would have to make.
e) Web site maintenance is going to be, um, challenging. We would actually
need an 8th repo for site-wide documentation, and then we'd need to have
some tools to avoid having to do 8 separate 'cvs update' invocations to
update the entire site on www.
f) Any time we want to add something new (e.g. opt-foo or core2), we would
need to go back to infrastructure and ask for yet another repo.
I see little advantage of all those separate repos over just one repo,
since that one repo could be organised in exactly the same way. In other
words, why use separate repos over something like this:
struts/
core/
taglib/
app/
opt-legacy/
opt-el/
opt-faces/
opt-sandbox/
site/
or even this:
struts/
core/
taglib/
app/
opt/
legacy/
el/
faces/
sandbox/
site/
Another thought on this. When we get to Struts 2, I'd like to see us
remove all of the JSP-ness of Struts from the core, and also add some
degree of support for other presentation technologies, such as XSLT and
Velocity. So, instead of having 'taglib' where it is in the above tree, we
might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
I think Ted's been advocating a similar philosophy, although any support for JSF
is going to be an interesting one in this kind of hierarchy, because you can
use JSF via JSP or through other presentation technologies as well.
Incidentally, where would Tiles land in all of this? In theory, it's not
tied to JSP, but rather to Servlets, so it might be applicable to some
other presentation technologies, but clearly not all.
I think the presentation-tier-independent things about Tiles (like mapping
forwards to definitions) should be built in to the core, so there isn't any
such thing as a separate TilesRequestProcessor (or a separate chain or
whatever). In turn, this probably means we might need an API abstraction that
alternative presentation tier technologies can use to integrate themselves into
the underlying support.
--
Martin Cooper
Craig
Actually, I'm not sure that a sandbox should be under 'opt' at all. I
could see us using a separate repo for that, since there is precedent in
both Commons and Taglibs.
I am now leaning towards 3 repos myself:
struts-legacy
This is our current repo, renamed. I don't really care for this
name, but I can't think of anything better right now, and I hate
sticking numbers in repo names, because they become invalid
quite rapidly if they are associated with versions (unless we
start a new repo for each major version, a la Tomcat, but I
don't like that idea either, for CVS history reasons).
struts
This would be structured per one of the suggestions above.
struts-sandbox
A separate sandbox, a la Commons and Taglibs.
The reason I've changed my mind since yesterday about 2 repos versus 1
(ignoring the sandbox for the moment) is that I realised that all of the
CVS shuffling we want to do will make it very hard, if not impossible, to
continue to work on older (pre-shuffle) versions of the product.
One other minor comment:
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Ted Husted wrote: On Sun, 21 Mar 2004 10:55:00 -0800 (PST), Martin Cooper wrote: I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. This would be fine with me. Checkout granularity cuts both ways. If you are actually working in all aspects of a project, then it's more checkouts. If you are not, then you spend more time checking out code that you don't care about. (Commons is getting to be a chore these days.) My experience with multi-project Maven builds is that its not difficult so long as the JARs are placed in a local repository where other Maven builds can find them. But either way works, it's all good. I think the point in favor of less repositories is that it's easy to make one module look like many modules (via aliases) but tricky to make many repositories look like one repository. Plus each repository has its own CVSROOT, etc.. -Paul My suggestions were colored by experience in environments like SourceForge where these sort of things are automated and easy to do. But, if a minimum number of repositories will make it easier for infrastructure, then, absolutely, I'm all for that. :) -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: branching 1.2 and 1.3 and CVS reorg for TLP status
I'm all for creating a 1.2.x branch so that work can begin on 1.3.x on HEAD, but I'm firmly against creating that branch on HEAD right now. I'm convinced. I'm not in a big hurry -- but I'm glad we're having this discussion. Commons Chain is still in the sandbox. I feel very strongly that we should not be relying on sandbox components in the mainstream of Struts. We've been through the pain of that several times before, and I don't want to have to deal with it again. I agree with this too. I haven't done enough with the code to feel like I can call for a vote for moving chain (or resources, for that matter) into commons-proper, and into a release, but if folks can flag any blockers, I might be able to start getting involved with that code. I kind of thought we could get away with just renaming the CVS stuff, and I'm happy to hear that that's true. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
On Fri, 19 Mar 2004 19:32:40 -0800 (PST), Martin Cooper wrote: If people want to start on 1.3.x, then I'd suggest we all pitch in and try to get 1.2.1 in shape for release ASAP. Works for me. There are a couple of tickets with patches that I can try tonight. If there's anything else on your list not represented by a problem ticket, please post one so that we know what's left to do. Then, when the problem count hits zero again, we can roll 1.2.1, and call it a branch :) Meanwhile, I would have no problem with calling for a VOTE on Commons Dev tonight to promote Commons Chain from the sandbox and roll the 1.0 release. I used it to good effect in an application based on Maverick, and it's certainly proved its worth in the Struts-Chain development. As mentioned elsewhere, I'm now taking a crack at a Commons-Chain-based MailReader. -Ted. On Fri, 19 Mar 2004, Joe Germuska wrote: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? I'm all for creating a 1.2.x branch so that work can begin on 1.3.x on HEAD, but I'm firmly against creating that branch on HEAD right now. I see little justification for creating a branch at a random point in the development cycle. IMNSHO, branches should only be created from a release point, especially given our newly adopted Tomcat- style release model, which means that the time between releases should be short. A bunch of stuff has changed since 1.2.0, so it clearly doesn't make sense to create a branch from there. A few more things need to happen before we're ready for 1.2.1, but not too many, IMO, so I believe we should create the 1.3.x branch at the point at which we release 1.2.1. If people want to start on 1.3.x, then I'd suggest we all pitch in and try to get 1.2.1 in shape for release ASAP. [Note: Technically, we should vote on how to categorise 1.2.0. However, I have not send out a vote request, since it seems fairly obvious to me that there was breakage enough to classify it as a test build and no more. If anyone else feels otherwise, please speak up! ;)] Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. There are a number of things that will need to be taken care of as part of the move to TLP, but I don't think they should impact this too much. The CVS repo move, as Ted suggests, is really a rename. Any reorganisation of the code base we want to do is independent of that. I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. Indeed. ;-) I'm looking forward to seeing Chain move forward too, but I have a big fat serious caveat before we do anything at all here to bring it into the mainstream. Commons Chain is still in the sandbox. I feel very strongly that we should not be relying on sandbox components in the mainstream of Struts. We've been through the pain of that several times before, and I don't want to have to deal with it again. So before we bring Struts Chain into the mainstream, Chain needs to be promoted out of the sandbox and into Commons Proper, preferably in good enough shape that it's not too far from being released. (Of course, the latter condition will affect a vote to promote it in the first place!) -- Martin Cooper Joe - 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: branching 1.2 and 1.3 and CVS reorg for TLP status
Quoting Joe Germuska [EMAIL PROTECTED]: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... I think there's a lot of merit in rationalizing the directory structures as part of the move to TLP-ness. Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. There are ways to preserve history, but I suspect there will be difficulties if we decide to split up what has been a single repository (jakarta-struts) into per-subpackage repositories. A guru on CVS would definitely be useful here. I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. I'm going to focus some energy as well on commons-chain and struts-chain now that JavaServer Faces is done. Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
- Original Message - From: Ted Husted [EMAIL PROTECTED] Date: Sat, 20 Mar 2004 18:09:53 -0500 To: Struts Developers List [EMAIL PROTECTED] Subject: Re: branching 1.2 and 1.3 and CVS reorg for TLP status snip / Meanwhile, I would have no problem with calling for a VOTE on Commons Dev tonight to promote Commons Chain from the sandbox and roll the 1.0 release. I used it to good effect in an application based on Maverick, and it's certainly proved its worth in the Struts-Chain development. As mentioned elsewhere, I'm now taking a crack at a Commons-Chain-based MailReader. I totally agree Commons Chain is ready for a release. I've been using the chain for an application for the US Naval Undersea Warfare Center to help decompose complex data transformation processes and its been working great. Of course the release stamp would also sit better with our client :) Don -Ted. -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sat, 20 Mar 2004, Craig R. McClanahan wrote: Quoting Joe Germuska [EMAIL PROTECTED]: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... I think there's a lot of merit in rationalizing the directory structures as part of the move to TLP-ness. Assuming we don't move to Subversion right now (see other thread), the move is effectively a CVS repo rename by the infrastructure folks, lock, stock and barrel. Any rationalisation is totally up to us. If we want to break up our existing repo, we have a couple of options: 1) One top-level 'struts' repo that we break down as we see fit. This option leaves everything in our control, since, as far as infrastructure@ is concerned, there is only one CVS repo. 2) Multiple top-level repos, one of which is a renamed version of our current repo, and the remainder of which are new empty repos. We would then migrate pieces of our current repo out to the new repos. 3) Same as (2) above, except that we don't ask for a repo rename, but just new repos, and we migrate everything ourselves to the appropriate new repo. While (3) is the cleanest insofar as we wouldn't have leftovers in the Attic of the renames repo, it's also a huge amount of work for us, and runs the risk of forgetting things. My preference is for (1). It is the simplest approach, and will allow us to move things around however we see fit, without having to decide up front which other repos we might want. If, at some point, we decide we do want other top-level repos, we can request them at that time. Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. There are ways to preserve history, but I suspect there will be difficulties if we decide to split up what has been a single repository (jakarta-struts) into per-subpackage repositories. A guru on CVS would definitely be useful here. A CVS repo rename will preserve all of our history, obviously. After that, I can take care of preserving history whatever we decide to do (as long as we stay with CVS ;). It's slightly easier if we have only one repo, but it can still be done across repos. -- Martin Cooper I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. I'm going to focus some energy as well on commons-chain and struts-chain now that JavaServer Faces is done. Joe 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]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
--- Joe Germuska [EMAIL PROTECTED] wrote: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. I have used the CVS log history many times when researching/fixing bugs so I'm very much against losing this data. David I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
I don't think there will be much actual moving involved. It's all the same machine. I believe it's just a matter of someone with sysadmin karma renaming things. If you check the Ant CVS, you'll see they have everything since the dawn of time. http://cvs.apache.org/viewcvs.cgi/ant/ There are questions about what the best way to reorganize (or rationalize) our now-rambling Struts project into several subprojects. But, I think we were going to do that regardless. And no one is going to want to sacrifice the CVS logs :) I do think we should start a 1.2 branch, in any event, and perhaps think about rolling 1.2.1 as soon as the name change is complete. And then use the HEAD for 1.3 development, including Struts Chain. I'm actually about to start work on a version of the MailReader that uses Commons Chain as a business facade. So, everything would goes through a CommandAction, which in turn calls a Command from the Catalog to do the deed. (Anyone else tried that yet?) -Ted. On Fri, 19 Mar 2004 15:02:49 -0600, Joe Germuska wrote: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
On Fri, 19 Mar 2004, Joe Germuska wrote: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? I'm all for creating a 1.2.x branch so that work can begin on 1.3.x on HEAD, but I'm firmly against creating that branch on HEAD right now. I see little justification for creating a branch at a random point in the development cycle. IMNSHO, branches should only be created from a release point, especially given our newly adopted Tomcat-style release model, which means that the time between releases should be short. A bunch of stuff has changed since 1.2.0, so it clearly doesn't make sense to create a branch from there. A few more things need to happen before we're ready for 1.2.1, but not too many, IMO, so I believe we should create the 1.3.x branch at the point at which we release 1.2.1. If people want to start on 1.3.x, then I'd suggest we all pitch in and try to get 1.2.1 in shape for release ASAP. [Note: Technically, we should vote on how to categorise 1.2.0. However, I have not send out a vote request, since it seems fairly obvious to me that there was breakage enough to classify it as a test build and no more. If anyone else feels otherwise, please speak up! ;)] Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. There are a number of things that will need to be taken care of as part of the move to TLP, but I don't think they should impact this too much. The CVS repo move, as Ted suggests, is really a rename. Any reorganisation of the code base we want to do is independent of that. I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. Indeed. ;-) I'm looking forward to seeing Chain move forward too, but I have a big fat serious caveat before we do anything at all here to bring it into the mainstream. Commons Chain is still in the sandbox. I feel very strongly that we should not be relying on sandbox components in the mainstream of Struts. We've been through the pain of that several times before, and I don't want to have to deal with it again. So before we bring Struts Chain into the mainstream, Chain needs to be promoted out of the sandbox and into Commons Proper, preferably in good enough shape that it's not too far from being released. (Of course, the latter condition will affect a vote to promote it in the first place!) -- Martin Cooper Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
