Commecnts:
One thing that I like is having the turbine application directory structure
in a format where I can symbolically link the app directory under webapps,
blaze up tomcat and test. Change a template, hit the browser and see the
change. Having an extra step of 'ant prepare' or something to copy the
templates/classes/jars etc over seems to be a pain. Any ideas on preserving
a quick, local development deployment?
-----------------------------------------------------------------
Throw away my code, but never, never throw away my tests.
-----------------------------------------------------------------
Jeffrey D. Brekke Quad/Graphics
[EMAIL PROTECTED] http://www.qg.com
-----------------------------------------------------------------
> -----Original Message-----
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 24, 2001 1:41 PM
> To: [EMAIL PROTECTED]
> Subject: Standard Layout for Turbine apps in CVS
>
>
> Hi,
>
> Right now Turbine applications have many different layouts.
> Scarab, Tambora,
> Jetspeed and probably every individually developed Turbine app has a
> different layout.
>
> I would like to standardize this layout taking into consideration
> a) Ease of use and visibility and b) Adhering to Jakarta standards as
> much as possible.
>
> Scarab, the sample TDK app and Tambora are all pretty similar. Let's
> start with the Scarab layout and work with that as an example. This
> is what Scarab's layout looks like:
>
> .
> |-- build
> | |
> | |- build.properties
> | |- build.xml
> |
> |-- lib
> |-- src
> | |-- conf
> | |-- dtd
> | |-- html
> | |-- images
> | |-- java
> | |-- resources
> | |-- sql
> | |-- templates
> | |-- tomcat-4.0
> | `-- usecases
> | `-- xdocs
> `-- www
>
> Here is another simplified version with the following changes:
>
> 1) build.xml/build.properties are moved to the top level directory
> for easy of use and visibility. A lot of jakarta projects do this.
>
> 2) try to separate developer specific resources in src, so in cases
> where Samba/Netatalk shares are setup it might be easier to
> to keep designers changing something by mistake. It happended
> to me once where I didn't have the src/java directory locked
> out and a designer deleted it on me. It can happen.
>
> 3) servlet container is housed in the TDK
>
> 4) all sql is generated by the TDK, even test data could be
> handled by an XML config and Torque would generate the
> inserts for the target database.
>
> 5) resources/templates directories are moved to the top level
> as these are not strictly developer resources.
>
> 6) most things will be stored in the TDK and a turbine application
> will use the TDK for the generation of SQL and OM, and for
> testing the application. There will be targets in the applications
> build.xml file to allow easy integration between with the TDK. All
> the nifty features that are present in some builds
> (Tambora and Scarab
> have a few) can be pushed into the TDK so that all turbine
> apps benefit.
>
> .
> |- build.properties
> |- build.xml
> |
> |-- docs (for non generated docs, generated output won't be stored)
> |-- lib (jars for code not provided by the TDK)
> |-- templates
> |-- resources
> |-- src
> | |-- conf
> | |-- java
> |
> `-- xdocs
>
> Hopefully this will start some discussion and in a couple of days we
> can arrive at some standard that we can document and promote.
>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> ---------------------------------------------------------------------
> 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]
