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: 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: [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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
