TLP layout (was Re: The future of actions)

[Ted Husted <hu...@apache.org>]

On Wed, 28 Apr 2004 11:06:13 -0500, Joe Germuska wrote:
> But the first steps are to get 1.2.1 out the door and get the TLP
> web site in order.  Is there anything I can do to help with
> struts.apache.org?   I don't really have a sense of the tasks, but
> if someone else does and wants to just dole a few out, I could try
> to help move that forward...

One of the next big steps will be to prototype a restructured code tree for CVS and post it where others can review it. The prototype would only need to be a filesystem, and wouldn't have to worry about CVS history. Though, we'd want to retain that when we did it for real on the server.

The general idea is that we want to subdivide the project into subprojects, each of which would represent a deliverable or Maven artifact. So at the top, there would probably something like: 

* core (including tiles and validator for now)
* apps
* site
* whiteboard (or "sandbox")

* opt-taglib
* opt-el
* opt-faces

We'd want to follow the Maven project layout recommendations for each deliverable. This will be the easiest for everyone to grok in the longrun.

http://maven.apache.org/reference/dirlayout.html

So, under each top-level directory, we would find a layout like

/src
�- java
�- test
�- webapp

/xdocs

/target (generated)
- *.jar
- distributions
- docs
- site
- ...

The example applications tree might be a tad different. Here we might want a master apps directory, with a directory for each application beneath that. This makes it easy for the apps to extend a common Maven project.xml. We could still offer a single zip/tarball with all the applications WARs within.

/apps
�- examples
�- mailreader
�- tilesPortal
�- userdb

This is what I've started to over in Commons Chain, since I envision having a couple of sample applications (using either Servlets or Filters). The Struts one I'd want to bring over here, once we've added a dependency on Chain.

As to "userDb", the UserDatabase code in the MailReader is getting reused in multiple applications these days, so we should make it a separate deliverable.

-Ted.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org