On Wed, 24 Mar 2004, Ted Husted wrote:
> On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote:
> > So, there are pros and cons both ways, of course. Now we just need
> > to make a decision and move on it. ;-)
>
> The consensus seems to be to use a single module with top-level-directories
> representing each subproject, so lets move forward with that.
>
> So I believe we're talking about something like this:
>
> \core (including tiles and validator)
> \apps
> \site
> \opt-dev (whiteboard or "sandbox")
So 'dev', 'whiteboard' or 'sandbox'? ;-) I don't have a strong preference,
although 'sandbox' is used by at least 4 Jakarta sub-projects. (In those,
it's a separate repo, though. Do we want to do the same?)
> \opt-taglib
I still like the idea of pushing this down under a generic presentation
directory, or at least under a JSP directory, so that we can move JSP
specific stuff out of core and into this.
> \opt-el
Hmm. This is also a taglib...
> \opt-faces
>
> The example applications we will have to juggle a bit:
>
> [apps]
> /src/example -> /mailreader/src/java
> /src/examples -> /examples/src/java
> /src/tiles-documentation -> /portal/src/java
>
> And the same for /web
> /web/{1} -> {1}/src/webapp/
>
> The other directory moving might go something like this:
>
> [opt-el]
> src/contrib/struts-el -> opt-el
>
> [opt-legacy]
> /src/contrib/struts-legacy -> opt-legacy
>
> [opt-faces]
> /src/contrib/struts-faces -> opt-faces
>
> [opt-dev]
> /src/contrib/ -> opt-dev
>
> [opt-taglib]
> src/share/o.a.s/taglib -> opt-taglib/src/java/o.a.s/taglib
> src/test/o.a.s/taglib -> opt-taglib/src/test/o.a.s/taglib
> doc/userGuide/dev_*.* -> opt-taglib/xdocs
> doc/userGuide/struts*.* -> opt-taglib/xdocs
>
> [site]
> /doc/ - site/xdocs
>
> [core]
> /src/share -> core/src/java
> /src/test -> core/src/test
> / -> /
>
> This is just a rough starting point. I'd want to try a dry-run offline first, and
> post it where people could browse it :)
+1. I was thinking along the same lines.
> One question is the packaging of Struts-el. Right now it's org.apache.strutsel. I'm
> thinking we might want that to be org.apache.struts.el instead.
Maybe either:
org.apache.struts.taglib.el.${foo}
org.apache.struts.taglib.${foo}.el
The latter just extends the original package names with ".el".
> We might also want to shuffle some things around in opt-faces to make it more Maven
> friendly. It's also sharing the UserDatabase package with the original example, and
> so we might want to break the UserDatabase out as a deliverable that multiple
> applications could share.
>
> Next question. In making changes like this, at what point do we start breaking the
> CVS history? I'd definitely want to keep it all for core and taglibs. The other
> components might be less important.
We can arrange to keep CVS history indefinitely. However, we'd want to
stop moving things around as soon as possible, really, and certainly not
move anything after we've created labels or branches in the new tree.
> ** Last but not least: What else do we need to do for 1.2.1 ? -- Just the three
> problem tickets on the bugzilla list now?
Actually, contrary to your comment in the "Counting down" thread, I don't
have anything up my sleeve (unless I forgot something myself). ;-) It
would be nice to resolve the issue with the Cactus tests not stopping
properly on Tomcat 5.0, but I can live without that if necessary.
--
Martin Cooper
>
>
> -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]
