You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/03/19 22:02:49 UTC
branching 1.2 and 1.3 and CVS reorg for TLP status
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
--
Joe Germuska
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Joe Germuska <Jo...@Germuska.com>.
>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
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Ted Husted <hu...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Martin Cooper <ma...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Ted Husted <hu...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Nathan Bubna <na...@esha.com>.
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
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Joe Germuska <Jo...@Germuska.com>:
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Tiles for alternative presentation technologies (RE: branching
1.2 and 1.3 and CVS reorg for TLP status)
Posted by Joe Germuska <Jo...@Germuska.com>.
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
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Martin Cooper <ma...@apache.org>:
> 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: 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]
> > > /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: struts-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Ted Husted <hu...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Martin Cooper <ma...@apache.org>.
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 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: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Martin Cooper <ma...@apache.org>.
On Sun, 21 Mar 2004, Craig R. McClanahan wrote:
> Quoting Martin Cooper <ma...@apache.org>:
>
> > 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.
Ah, yes, I'd forgotten all about modules in CVS. It's been quite some time
since I've used those.
>
> > 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.
Sounds good to me.
>
> > 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.
More than just an avail entry, I would think. It would at least need a new
directory under CVSROOT. But I can see that any cvs admin could do what's
needed.
>
> > 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?
Yes, 'original' sounds a little better. ;-)
> I'm also very willing to defer any decision to migrate to SVN ... CVS, for all
> its warts, sounds like it still offers everything we need at the moment.
Agreed.
--
Martin Cooper
>
> > --
> > Martin Cooper
>
> Craig
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Martin Cooper <ma...@apache.org>:
> 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, sounds like it still offers everything we need at the moment.
> --
> Martin Cooper
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Joe Germuska <Jo...@Germuska.com>.
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
Joe@Germuska.com
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Paul Speed <ps...@progeeks.com>.
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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Ted Husted <hu...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Martin Cooper <ma...@apache.org>.
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]
> /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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Ted Husted <hu...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Steve Raeburn <sr...@apache.org>.
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:martinc@apache.org]
> 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 <Jo...@Germuska.com>:
> >
> > > 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: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 20 Mar 2004, Craig R. McClanahan wrote:
> Quoting Joe Germuska <Jo...@Germuska.com>:
>
> > 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Joe Germuska <Jo...@Germuska.com>:
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by Ted Husted <hu...@apache.org>.
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
Posted by David Graham <gr...@yahoo.com>.
--- Joe Germuska <Jo...@Germuska.com> 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
> Joe@Germuska.com
> 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org