17 messages in org.apache.struts.devRe: Repository Reorg (Once More With ...| From | Sent On | Attachments |
|---|---|---|
| Craig McClanahan | Jul 17, 2004 2:56 pm | |
| Martin Cooper | Jul 17, 2004 5:06 pm | |
| Vic Cekvenich | Jul 17, 2004 6:30 pm | |
| Ted Husted | Jul 18, 2004 5:51 am | |
| Ted Husted | Jul 18, 2004 5:59 am | |
| Ted Husted | Jul 18, 2004 6:01 am | |
| Craig McClanahan | Jul 18, 2004 1:15 pm | |
| Ted Husted | Jul 19, 2004 4:24 pm | |
| Craig McClanahan | Jul 19, 2004 4:48 pm | |
| Ted Husted | Jul 19, 2004 5:04 pm | |
| Martin Cooper | Jul 19, 2004 9:06 pm | |
| Martin Cooper | Jul 19, 2004 9:12 pm | |
| Martin Cooper | Jul 19, 2004 9:21 pm | |
| Ted Husted | Jul 20, 2004 3:52 am | |
| Ted Husted | Jul 20, 2004 5:15 am | |
| Niall Pemberton | Jul 20, 2004 6:52 am | |
| Craig McClanahan | Jul 20, 2004 7:48 am |
| Subject: | Re: Repository Reorg (Once More With Feeling) | |
|---|---|---|
| From: | Martin Cooper (mfnc...@gmail.com) | |
| Date: | Jul 19, 2004 9:21:30 pm | |
| List: | org.apache.struts.dev | |
+1 to all of this. :-)
One point about dependencies on 'core', though. It's seldom likely to be as clear cut as depending on core or not. For example, it's likely that, once we split out Tiles, there will still be some glue that depends on 'core', even if Tiles per se does not. Then the question arises of where the glue should live - here or as part of the glued-on project. ;-) (BTW, that's something I think we should develop a policy on, so that we're not seen as making arbitrary decisions in this area, but that's another topic entirely.)
-- Martin Cooper
On Sun, 18 Jul 2004 08:59:38 -0400, Ted Husted <hus...@apache.org> wrote:
On Sat, 17 Jul 2004 17:06:44 -0700, Martin Cooper wrote:
kind of repackaging seems fairly drastic as part of a point �release, since it will affect how people download and build their �Struts apps. But if everyone else is OK with that, I won't object.
If we want to call this Struts 2.x, that would be OK with me. Then, everything
we slated for 2.x moves up to 3.x.
(Which underscores the evil of framing development roadmaps around version
numbers. The tail starts to wag the dog.)
�2) Is this presuming a change of Servlet / JSP version �dependencies? Otherwise I'm not sure how feasible it would be to �move 'upload' to 'addons', because of all the wrapping and �unwrapping we have to do for Servlet 2.2 compatibility.
If we want to move the minimum to Servlet 2.3 that would be OK with me too.
Then we have Struts 1.x, 2.x, and 3.x, for the Servlet 2.2, 2.3, and 2.4
respectively.
�7) I think we need a better term than 'module', since that's �already taken in the context of Struts apps. ;-)
I'd favor going back to referring these as "subprojects" and make subprojects
artifacts the units of release.
The idea being we can make a new release of struts-core without making a new
release of struts-taglibs, and vice versa.
�5) I'd like us to find some kind of plugin mechanism for the web �site, so that the non-core modules had add their piece to the main �site without a lot of dependencies. Not sure how that would work, �off the top of my head, but I think it would be a good goal.
As subprojects, each of these would have their own documentation and Maven site.
Struts-site would need only link to each subproject (or module).
While this starts to have the look-and-feel of an umbrella project like the
Commons it is NOT AN UMBRELLA project, since all the subprojects are dependant
on the struts-core distribution.
The latter might even be a rule. If a subproject is not dependant on
struts-core, then it can be hosted elsewhere.
So, for example, if we can spin-off Tiles so that it has no struts-core
dependencies, then it wouldn't belong here. It could live in the Jakarta or
Apache Commons, or SourceForge.
-Ted.