Along those lines I moved the build.properties to a default.properties file
much like the other builds. This allows you to define your own 'turbine
build.properties' and I've also added a sample that points to all the jars
in lib. So to use this you would make sure your
${user.home}/build.properties doesn't define lib.repo or the jars and rename
build.properties.sample to build.properties. This should then use the jars
out of the lib directory for the time being and allow others to use newer
jars ( of the update-jars stuff later ) if they choose.
I also updated the build to conditionally compile the webmacro stuff if the
jar is in the classpath ( like freemarker ).
-----Original Message-----
From: Daniel Rall
To: Turbine Developers List
Sent: 1/30/02 6:54 PM
Subject: Re: cvs commit: jakarta-turbine-2 build-torque.xml build.properties
build.xml build-turbine-sql.xml
Paul Spencer <[EMAIL PROTECTED]> writes:
> The following jars, as define in build.properties, do NOT exist in the
> distribution.
> commons-collections.jar
> junit-3.7.jar
> log4j-1.1.3.jar
> servlet.jar
> velocity-1.3-dev.jar
> xalan-2.1.0.jar
> xerces-1.4.4.jar
> xmlrpc-helma.jar
> castor.jar
> freemarker.jar
> webmacro-0.94.jar
>
> In my case, I had to update the name of the velocity and xerces jars
to
> velocity-1.2-dev.jar and xerces-1.3.0.jar in order to get a good
build.
FWIW, you can override the default JAR file names in your own
~/build.properties file.
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
