To be honest, I'm not sure what the goal is ;-)
I've been thinking there should be a place to post codebases that
haven't made it to distribution. Sometimes because we haven't had a
chance to look at them, sometimes because they wouldn't fit in with a
general-purpose lightweight framework. Some people have done this using
our own Web pages, but others have asked me to host the code on my Web
site instead. In the end, I'd like to put together an electronic catalog
where people can post and update their own ZIPs or WARs for all of
Jakarta and Java-land.
Craig suggested that we go ahead a put up a /contrib folder, and start
checking in anything appropriate (except for David's, Oleg's, and
Cedric's packages). I then began to wonder if checking in code authored
by someone without access to the CVS was the best way to go. And if I
check it in, it would seem like I'd be on the hook for any maintenance,
which implies I should take a good look at the code first. Since there
are a number of packages out there already, and I haven't gone through
them all yet, as an interim step, I expanded the contributor's section
on the Resources page, and will keep that updated.
Meanwhile, there seemed to be some uncertainity about whether David and
Oleg's codebases belonged in the core distribution or not (- not making
an opinion statement here ;-), so I suggested they all post them to
/contrib first -- really just to get things rolling.
As to your question:
The /contrib area is maintained by the Committers, who should take
responsiblity for managing the namespaces. My first inclination is to
suggest we name the packages so they could be moved under /src/shared at
any time, though I could easily be convinced otherwise. Perhaps we could
also open a dummy directory under shared to reserve a place for a
contrib package. Or, maybe skip the whole thing and just put them under
/src/shared now ;-)
As it stands, I would suggest that the goal of the Struts /contrib area
is to be a staging area for packages that may be moved into the main
source tree later (under /src/shared), or left in contrib indefinately.
For any packages being maintained anywhere else by anyone else, I would
suggest that they use their own namespace until it is moved under
/contrib or /src/shared in the Struts repository.
... Comments and alternatives welcome ...
-Ted.
Martin Cooper wrote:
>
> I think we will need to establish some guidelines for the structure of
> contributions, though. If the goal is that someone can pick up Struts, and
> add Contribution A and Contribution B, and have a combined package that
> works, then not only should the 'namespaces' (i.e. package names and taglib
> names) for A and B be distinct from each other, but they should both be
> distinct from Struts proper. Otherwise, it will be hard to migrate
> contributed code to Struts proper without breaking existing code that
> already uses the contributed functionality.
>
> --
> Martin Cooper
