On 7/29/01 9:20 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>> +----------------------------------------------------------------+
>> + F A I L E D R E Q U I R E M E N T |
>> +----------------------------------------------------------------+
>> | You must define the following property in order |
>> | to build Torque: |
>> | |
>> | log4j.jar
>> | |
>> | You can set this property in the provided build.properties |
>> | file, or you may set this property in your |
>> | /home/rubys/build.properties file.
>> +----------------------------------------------------------------+
>
> Sweet!
>
> I'm adjusting and testing the gump definition as I write this. Information
> such as the above is very helpful.
>
> Just a comment in passing - there are a number of constants defined in the
> build.properties.sample file that you would not often expect people to
> modify.
Yes, you're right. I was discussing this with John McNally: the setup
is a reflection of my setup and a universal build system I am trying
to work out with Geir using Gump, Maven (my java version of gump that
I am trying to get to work with Gump), jjar (geir's utility for
automatically downloading jars required to build a specific project),
a set of common property names (like log4j.jar), and some specific
patterns in Ant build files like what you see above.
> Examples: name, build.dir, src.dir, javadoc.destdir, etc.. My
> suggestion is that they also be defined in build.xml (entries in the
> properties file, if any, will override). This allows you to add new ones
> without people having to modify their existing properties file each time.
The reason why it was switched to build.properties.sample was because of
the order I was pulling in ~/build.properties vs project/build.properties
and where I was defining my jar properties. John and I decided that it
would be best to have a build.properties file as opposed to the sample,
and the jar properties should be defined in the project build.properties
for now as opposed to ~/build.properties.
I like the idea of not embedding any specific project information in
the build.xml file so that I can move all the turbine projects toward
a single build.xml file that works for all of them.
> Finally, there probably is no longer a need to echo the value of
> ${lib.repo}.
Yes, that's true too.
What I am trying to do is have a system where the requirment detection
automatically triggers the download of required jars if the requirements
are not satisfied. I have this mostly working with Torque, but checking
for the existence of a set of requirements is a real PITA with Ant as you
can tell from the torque build.xml file. I would like to make an Ant
task that simplifies this and uses properties instead. Maybe have something
like build.deps:
log4j = org.apache.log4j.Category
village = com.workingdogs.village.Column
and use these definitions in conjunction with an ant target to check
the requirements and if they are lacking download the jars and place
them in ${lib.repo}. Right now, a definition file in geir's jjar tool
knows what versions of a jar that a project needs.
All this needs to be refined and I've just cobbled some stuff together,
but I think it's very possible to never store jars in CVS and have
a completely transparent build system that could be used for any
java project if they use a set of compliant property names that
we store in a registry or something.
I am currently playing with the digester to turn a gump profile
into a java object, and than it profile object uses a dep engine that
geir made for me to sort build order of the projects. I finally had
some time to get back to working on a java version of gump. I'll have
more questions but I'll post them to the alexandria list.
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> 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]
