And we could achieve the same with some web.xml magic to locate the jars,
classes, and properties?
-----------------------------------------------------------------
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 2:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Standard Layout for Turbine apps in CVS
>
>
> On 7/24/01 3:23 PM, "Brekke, Jeff" <[EMAIL PROTECTED]> wrote:
>
> > 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?
>
> Copying the templates is not acceptable to me. I'd like to make an
> addition to the template service where it knows it's in development
> mode and takes a full path to the templates so they can be edited
> in place.
>
> > -----------------------------------------------------------------
> > 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]
>
> --
>
> 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]
