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