> > You have an itch! Scratch it! :-)
>
> Okay - I started - and I may have gone a bit far :P
>
> I noticed someone already added new ant and build file - I
> had already adapted old build file to include what he had
> done.
>
Yup - that was me.
> The ant file I did mean't that you *never* have to set
> classpath via scripts. It is all done with ant via things
> like ../lib/*.jar. Unfortunately this means that the
> conflicting jars (webmacro and freemarker) have to go to
> another directory (I placed them in ../lib/optional). The
> particular instance is read from .ant.properties file.
>
+1 I personally cannot stand all those hard-links in build-turbine.bat/.sh, but
I haven't had a justifiable reason for removing them. To advance this one more
step, I think the Turbine build should do a lot more conditional compilation -
for instance, if I don't want to use the Castor service, I shouldn't have to
download all the requisite jars.
> The current turbine build file only allows per user
> .ant.properties - I added a per project .ant.properties
> aswell.
>
+1
> I redid the webapp target so that it creates a valid webapp
> and is off and running - with a line in .ant.properties
> (webapp.dir=/path/to/my/tomcat/webapp/myturbineapp) it is
> even *installed* in the correct place. The only thing you have to
> do is
>
> 1> set up database
> 2> edit proeprties files of both webmacro and turbine to
> point log to correct place
>
> You can also do it on per project basis by placing
> .ant.properties alongside build-turbine.xml file.
>
> For 1 I have a half written script (for another
> project) that I could convert to ant so that different
> databases are automatically setup ? Is it worth it ?
>
I would be strongly opposed to modifying the Turbine build process to
automatically build a database. In my view, the Turbine build should be geared
for compiling turbine.jar and (maybe) creating a WAR. Anything that is either
(1) Tomcat-specific or (2) creates a database should be limited to the TDK.
Rightly or wrongly (feel free to make a judgement), I see the following
dichotomy between the Turbine and TDK build processes: when I build Turbine
only, it's because I'm updating an existing installation, so the db-creation
code is completely orthogonal; when I build TDK, it's because I'm a new user
and/or developing a new project, so I want the db automatically created. Perhaps
this is just my opinion, but there it is.
> For 2 - would it be possible to let turbine pick a
> reasonable default. For instance if it is not setup then it
> logs to <webappdir>WEB-INF/logs/... and same with webmacro
> ???
>
> The only problem with what I have done is that I have been
> unable to test it properly with templates as I have no idea
> how they work yet :P.
>
> I can access screen/Error by default as it maps to a java
> object and if I add in org.apache.turbine.examples to module
> path I am sweet. However I imititate behaviour of old build
> file so I *shouldn't* have broken anything but you may want
> to check it out.
>
> So to use this build file you will have to download latest
> ant CVS snapshot. Move webmacro-* and freemarker-* to
> lib/optional, setup database, setup logs and drop a
> .ant.properties into build/ directory that looks something
> like
>
> deprecation=false
> database.jar=mysql.jar
> database.lib.dir=/RHI/lib
> jsdk.jar=/RHI/tomcat/lib/servlet.jar
> webmacro.jar=webmacro-jdk1.2-CVS.jar
>
> You then can practically delete all of
> build-turbine.[sh|bat] except for part that sets CLASSPATH
> for xerces and ant and then you are off.
>
> The reason for doing this is because I am trying to get
> Turbine used in uni classes next year (a summer course on
> web-applications) and thus it needs to be as painless as
> possible :P.
>
> I would also like to see a more standardised structure in
> turbine repository to make it look/behave a lot like some of
> the other apache projects. What I would like to see is a
> filesystem setup like
>
<snip>
Rather than using the structure of existing Apache projects as a de-facto
standard, I'd much rather see an organized effort to define a true standard. Sam
Ruby is headed in this direction, but I think he needs more input and/or support
from other projects.
http://oss.software.ibm.com/developerworks/opensource/jakarta/nightly.html
The problem, of course, with defining such a standard is that the core
developers of each project has their own preferences for setting up the
directory structure. Any "standard" would have to accommodate these local
differences if it were to succeed.
>
> Thoughts ???
>
>
> Cheers,
>
> Pete
>
--
Christopher Elkins
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]