You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jeff Turner <je...@socialchange.net.au> on 2002/04/01 13:11:01 UTC
New dependency checking system in CVS
Hi,
I've got a dependency checking system for Excalibur working. In theory,
it allows you to type 'ant' anywhere in Excalibur, and never see a
compile error caused by missing dependencies. AFAICT, it works too :)
It's in CVS in the 'depchecking' branch. To try it, run:
cvs update -r depchecking
Only the build.xml and .properties files will update, so it shouldn't do
any harm.
I put this stuff in a branch because it contains sufficient changes to
deserve a vote before inclusion.
It works as follows:
- For internal dependencies (other components), it will recursively
build those components if they need building.
- For external dependencies like jmx.jar, junit.jar, altrmi, it will
either print an error message saying "define this property", or do a
HTTP GET to retrieve the file from somewhere.
For example, say you download Excalibur, and want to build the Command
component. It has these dependencies (in default.properties):
excalibur-event
excalibur-collections
excalibur-concurrent
excalibur-scratchpad
excalibur-core
excalibur-framework
Then there's secondary dependencies:
- event depends on collections and concurrent.
- core and scratchpad depend on collections, concurrent, instrument,
event and framework
.. and so it goes. LOTS of dependencies, and a real pain to build
manually. Now you no longer have to! The dep checking system recurses
through that dependency tree, and on each leaf either builds the
project, prints an error or does a HTTP GET to retrieve the jar. If a
project is already built (eg 'collections'), or already downloaded (say,
in your jar repository), then it's not built again.
The system is implemented in a single file, depchecker.xml, which is called by
each build.xml script. This is in the Excalibur root. If you type 'ant -d
depchecker.xml', a rather verbose description of how to use it is printed:
Buildfile: depchecker.xml
usage:
[echo]
=======================================================
This is Excalibur's dependency updater script.
Which has been called incorrectly :)
To use it, you must call the checkRequiredFile or
checkRequiredClass targets from your Ant script.
For example:
<ant antfile="depchecker.xml" target="checkRequiredFile">
<properties name="name" value="excalibur-concurrent.jar"/>
<properties name="path" value="${excalibur-concurrent.jar}"/>
<properties name="proj.home" value="../concurrent"/>
<properties name="proj.target" value="dist.lite"/>
</ant>
That will check if ${excalibur-concurrent.jar} points to a jar, and
if it doesn't, build the ${proj.home} project in order to generate
the jar
or:
<ant antfile="depchecker.xml" target="checkRequiredFile">
<property name="name" value="commons-io.jar"/>
<property name="path" value="${lib.repo}/commons-io.jar"/>
<property name="url" value="http://jakarta.apache.org/turbine/jars/commons-io.jar"/>
</ant>
That will check if ${lib.repo}/commons-io.jar exists, and if not,
download it from ${url}
The properties are as follows:
For checkRequiredFile:
name:
Name of the jar. Eg 'avalon-collections.jar'
path:
Path to named jar. Eg ${avalon-collections.jar}
proj.home (optional):
Path to local project which builds the jar. Only set if the jar
could be local, eg another component.
proj.target (optional) [dist.lite]:
Ant script target to run in local project to build the jar
url (optional):
URL to retrieve jar if not present on the local filesystem
For checkRequiredClass:
name:
Name of jar in which the class usually resides
class:
Name of class to check for
classpath:
String classpath (; or : separated) to search for ${class} in
=======================================================
main:
BUILD SUCCESSFUL
Total time: 2 seconds
I won't elaborate much on that here. Each build.xml has a "dependencies"
target, which invokes checkRequiredFile for each jar, and likewise for
classes.
To implement this system, I had to make a few related changes, whose purpose
isn't immediately obvious. I'll outline them here. This isn't required
reading unless you're very upset about a certain change. The issues are
complicated and multi-faceted. Not light reading. You have been warned
:P
- I renamed avalon-excalibur.jar to excalibur-core.jar, as discussed on
the list earlier. Similarly, avalon-scratchpad.jar is now
excalibur-scratchpad.jar. I haven't yet fixed excalibur-all.jar
(sorry Berin).
- I pulled all the build.xml properties into their own file,
default.properties, and changed the order in which properties files
are sourced to this:
<property file="${user.home}/.ant.properties"/>
<property file="../ant.properties"/>
<property file="ant.properties"/>
<property file="../default.properties"/>
<property file="default.properties"/>
Turbine people will find this familiar, because it's identical to how
Turbine and Maven do things, except renaming build.properties to
ant.properties.
The reason for this is because I wanted somewhere to put
default property values. With our old system, every user had to 'cp
ant.properties.sample ant.properties', even to get the defaults. This
explicit step should only be necessary for external dependencies,
where we can't make a reasonable guess. That's where
default.properties comes in. It is sourced last, and contains all the
properties previously defined in build.xml, plus properties to jars
of other components (eg "../foo/dist/excalibur-foo-1.0.jar").
Why 'default.properties' instead of the existing
'project.properties'? Because:
- It follows the Turbine/Torque/Fulcrum precedent
- 'default.properties' is more location-agnostic. "project" implies
that the file belongs to a project. Not true when you have
'project.properties' in a non-project directory like the Excalibur
root. Same as how "ant.properties" is more function-agnostic than
"build.properties".
Note also that ${user.home}/.ant.properties and ../ant.properties are
sourced before ./ant.properties. This is so that you can define
${base.path} or ${lib.repo}, or ${junit.jar} *once*. Previously, you
had to define it, or undefine it, in *every* ant.properties. Why?
Because our ant.properties.sample *must* have it, in case it's
standalone, but IF it's present, it would override ../ant.properties.
So our poor user is forced to either delete it if it's declared in
../ant.properties, or define it.
If you're worried about this change, please ask and I'll explain some
more. It's worked perfectly well for Turbine users for many years. It
just takes some getting used to.
- I added a 'dist.lite' target to all components. This generates a
directory structure identical to a real distribution, but in a
predictable location (../foo/dist) that can be pointed to from other
components' default.properties files.
- Other stuff I can't remember right now.
So please 'cvs up -r depchecking', have a play, and report back.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Apr 03, 2002 at 08:58:11AM -0400, Gonzalo A. Diethelm wrote:
> Is there any relation between this dependency checking system
> and what has been put into maven? I know Jason had planned to
> use BCEL to automatically determine the libraries required by
> a project; he even mentioned putting whatever code he came up
> with into the commons. Any overlap here? Just curious,
Excalibur's dependency checking is a cleaned-up, reusable version of
what already exists in many Jakarta projects. It requires no taglibs or
extra downloads. It can't do many things Maven can (eg construct
classpaths), but it can do other things Maven can't, like recursively
build projects. In time, I expect Maven will be able to do all sorts of
neat stuff like this, but for now.. :)
--Jeff
> --
> Gonzalo A. Diethelm
> gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Paul Hammant <Pa...@yahoo.com>.
Jeff ,
>Good-o.. still need to:
>
> - fix the instrument-client problem that Berin/Paul mentioned. Easily
> done by compiling before declaring the altrmi taskdef.
>
Do an update on the whole of excalibur....
> - Add a ${message} param for explaining where to get jars (Paul's
> suggestion).
> - fix the circular deps. Horrible problem..
> - put common checks in depchecker.xml targets, thereby building up a
> reusable library of dependency checks.
>
>I have Evil Designs on jakarta-avalon-apps with this system too.. cut
>down on that 20mb download.
>
:-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: New dependency checking system in CVS
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
Is there any relation between this dependency checking system
and what has been put into maven? I know Jason had planned to
use BCEL to automatically determine the libraries required by
a project; he even mentioned putting whatever code he came up
with into the commons. Any overlap here? Just curious,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
> -----Original Message-----
> From: Jeff Turner [mailto:jeff@snow.socialchange.net.au]On Behalf Of
> Jeff Turner
> Sent: Wednesday, April 03, 2002 08:11 AM
> To: Avalon Developers List
> Subject: Re: New dependency checking system in CVS
>
>
> On Wed, Apr 03, 2002 at 08:17:21PM +1000, Peter Donald wrote:
> > >
> > > So I've added 'depchecking.sh', a small script to do the
> correct update
> > > of just the relevant files. On Unix, run 'source depchecking.sh'. On
> > > Windows, cut'n'paste.
> >
> > all seems to work for me (once comment out scratchpads javac).
> >
> > Thanks heaps!
> >
> > +1 for moving it to the main tree
>
> Good-o.. still need to:
>
> - fix the instrument-client problem that Berin/Paul mentioned. Easily
> done by compiling before declaring the altrmi taskdef.
> - Add a ${message} param for explaining where to get jars (Paul's
> suggestion).
> - fix the circular deps. Horrible problem..
> - put common checks in depchecker.xml targets, thereby building up a
> reusable library of dependency checks.
>
> I have Evil Designs on jakarta-avalon-apps with this system too.. cut
> down on that 20mb download.
>
>
> --Jeff
>
> > --
> > Cheers,
> >
> > Pete
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Apr 03, 2002 at 08:17:21PM +1000, Peter Donald wrote:
> >
> > So I've added 'depchecking.sh', a small script to do the correct update
> > of just the relevant files. On Unix, run 'source depchecking.sh'. On
> > Windows, cut'n'paste.
>
> all seems to work for me (once comment out scratchpads javac).
>
> Thanks heaps!
>
> +1 for moving it to the main tree
Good-o.. still need to:
- fix the instrument-client problem that Berin/Paul mentioned. Easily
done by compiling before declaring the altrmi taskdef.
- Add a ${message} param for explaining where to get jars (Paul's
suggestion).
- fix the circular deps. Horrible problem..
- put common checks in depchecker.xml targets, thereby building up a
reusable library of dependency checks.
I have Evil Designs on jakarta-avalon-apps with this system too.. cut
down on that 20mb download.
--Jeff
> --
> Cheers,
>
> Pete
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Peter Donald <pe...@apache.org>.
On Tue, 2 Apr 2002 10:35, Jeff Turner wrote:
> On Mon, Apr 01, 2002 at 09:11:01PM +1000, Jeff Turner wrote:
> > Hi,
> >
> > It's in CVS in the 'depchecking' branch. To try it, run:
> >
> > cvs update -r depchecking
> >
> > Only the build.xml and .properties files will update, so it shouldn't do
> > any harm.
>
> Apologies; that is not correct; it would pull everything back to the
> version I tagged, and modified files would appear as conflicts (not
> damaged though).
>
> So I've added 'depchecking.sh', a small script to do the correct update
> of just the relevant files. On Unix, run 'source depchecking.sh'. On
> Windows, cut'n'paste.
all seems to work for me (once comment out scratchpads javac).
Thanks heaps!
+1 for moving it to the main tree
--
Cheers,
Pete
*-----------------------------------------------------*
| For those who refuse to understand, no explanation |
| will ever suffice. For those who refuse to believe, |
| no evidence will ever suffice. |
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Apr 01, 2002 at 09:11:01PM +1000, Jeff Turner wrote:
> Hi,
>
> It's in CVS in the 'depchecking' branch. To try it, run:
>
> cvs update -r depchecking
>
> Only the build.xml and .properties files will update, so it shouldn't do
> any harm.
Apologies; that is not correct; it would pull everything back to the
version I tagged, and modified files would appear as conflicts (not
damaged though).
So I've added 'depchecking.sh', a small script to do the correct update
of just the relevant files. On Unix, run 'source depchecking.sh'. On
Windows, cut'n'paste.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Paul Hammant <Pa...@yahoo.com>.
Jeff,
Yup, it now works for me. I like it a lot :-)
I am going to vote +1 for these to go into HEAD ass soon as possible.
I think the general fail case could benefit from ${remedy} and that
could be "Run target Get-JUnit" for Junit as the jar is in a zip....
- Paul
>On Mon, Apr 01, 2002 at 09:01:00PM +0100, Paul Hammant wrote:
>
>>Jeff,
>>
>>>>>>From the newbie's experience, this is still have an issue if junit is
>>>>
>>>>>missing....
>>>>>
>>>>Ah yes, forgot to do the junit checks for anything except
>>>>io. Will fix it now.
>>>>
>>>Done.
>>>
>>Afraid not dude, did you forget to commit the file? It is still failing
>>if junit jar is missing from ant/lib for me. It works if I readd it.
>>
>
>Hmm.. the commit went in (see the log). Did you update? To update now,
>I'd suggest doing 'cvs up -A ; source depchecking.sh'.
>
>Here's what I get:
>
>[jeff@kermit concurrent]$ echo $CLASSPATH
>/usr/local/jdk/jre/lib/rt.jar:/usr/local/jdk/lib/tools.jar
>[jeff@kermit concurrent]$ which ant
>/usr/share/java/ant/bin/ant
>[jeff@kermit concurrent]$ ls /usr/share/java/ant/lib
>README aspectj-ant.jar@ aspectjtools.jar@ jakarta-ant-1.4.1-optional.jar scoant.jar xerces.jar
>ant.jar aspectjrt.jar@ crimson.jar jaxp.jar xalan.jar
>[jeff@kermit concurrent]$ ant
>Buildfile: build.xml
>
>dependencies:
>
>checkRequiredClass:
>
>checkRequiredClass.fail:
> [echo]
> +----------------------------------------------------------------+
> | CLASS NOT FOUND: |
> | junit.framework.Test
> +----------------------------------------------------------------+
> | A jar containing class: |
> | junit.framework.Test
> | must be in your classpath or Ant lib directory |
> | /usr/share/java/ant/lib
> | Typically it is in a jar called: |
> | junit.jar
> +----------------------------------------------------------------+
>
>
>BUILD FAILED
>
>/home/jeff/apache/jakarta/jakarta-avalon-excalibur/depchecker.xml:217: Failed requirement: class not found
>
>Total time: 4 seconds
>
>
>--Jeff
>
>>>It's such a pain keeping 19 build files in synch..
>>>
>>We need a template system ;-)
>>
>>- Paul
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Apr 01, 2002 at 09:01:00PM +0100, Paul Hammant wrote:
> Jeff,
>
> >>>From the newbie's experience, this is still have an issue if junit is
> >>>missing....
> >>>
> >>Ah yes, forgot to do the junit checks for anything except
> >>io. Will fix it now.
> >>
> >
> >Done.
> >
> Afraid not dude, did you forget to commit the file? It is still failing
> if junit jar is missing from ant/lib for me. It works if I readd it.
Hmm.. the commit went in (see the log). Did you update? To update now,
I'd suggest doing 'cvs up -A ; source depchecking.sh'.
Here's what I get:
[jeff@kermit concurrent]$ echo $CLASSPATH
/usr/local/jdk/jre/lib/rt.jar:/usr/local/jdk/lib/tools.jar
[jeff@kermit concurrent]$ which ant
/usr/share/java/ant/bin/ant
[jeff@kermit concurrent]$ ls /usr/share/java/ant/lib
README aspectj-ant.jar@ aspectjtools.jar@ jakarta-ant-1.4.1-optional.jar scoant.jar xerces.jar
ant.jar aspectjrt.jar@ crimson.jar jaxp.jar xalan.jar
[jeff@kermit concurrent]$ ant
Buildfile: build.xml
dependencies:
checkRequiredClass:
checkRequiredClass.fail:
[echo]
+----------------------------------------------------------------+
| CLASS NOT FOUND: |
| junit.framework.Test
+----------------------------------------------------------------+
| A jar containing class: |
| junit.framework.Test
| must be in your classpath or Ant lib directory |
| /usr/share/java/ant/lib
| Typically it is in a jar called: |
| junit.jar
+----------------------------------------------------------------+
BUILD FAILED
/home/jeff/apache/jakarta/jakarta-avalon-excalibur/depchecker.xml:217: Failed requirement: class not found
Total time: 4 seconds
--Jeff
> >It's such a pain keeping 19 build files in synch..
> >
> We need a template system ;-)
>
> - Paul
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Paul Hammant <Pa...@yahoo.com>.
Jeff,
>>>>From the newbie's experience, this is still have an issue if junit is
>>>missing....
>>>
>>Ah yes, forgot to do the junit checks for anything except
>>io. Will fix it now.
>>
>
>Done.
>
Afraid not dude, did you forget to commit the file? It is still failing
if junit jar is missing from ant/lib for me. It works if I readd it.
>It's such a pain keeping 19 build files in synch..
>
We need a template system ;-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Apr 01, 2002 at 09:46:40PM +1000, Jeff Turner wrote:
> On Mon, Apr 01, 2002 at 12:32:06PM +0100, Paul Hammant wrote:
> > Jeff,
> >
> > From the newbie's experience, this is still have an issue if junit is
> > missing....
>
> Ah yes, forgot to do the junit checks for anything except
> io. Will fix it now.
Done. It's such a pain keeping 19 build files in synch..
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Apr 01, 2002 at 12:32:06PM +0100, Paul Hammant wrote:
> Jeff,
>
> From the newbie's experience, this is still have an issue if junit is
> missing....
Ah yes, forgot to do the junit checks for anything except
io. Will fix it now.
>
> I appreciate that we all have junit in Ant's lib dir, but the newbie
> does not. I think a simple warning would be good enough :
The warning would be:
+----------------------------------------------------------------+
| CLASS NOT FOUND: |
| junit.framework.Test
+----------------------------------------------------------------+
| A jar containing class: |
| junit.framework.Test
| must be in your classpath or Ant lib directory |
| ${ant.home}/lib
| Typically it is in a jar called: |
| junit.jar
+----------------------------------------------------------------+
That can be modified to include a customized message if you like.
--Jeff
> Hi, the compile of Exacilibur classes cannot happen without the
> the presence of the JUnit for the comiple env. You may eithether 1)
> put junit.jar in ant's lib directory, 2) rename the the
> ant.properties.sample file in excaliburs root dir or 3) run the
> 'get-junit' target. After any of those try the failing ant target
> again. Thanks for you patience.
>
> - Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New dependency checking system in CVS
Posted by Paul Hammant <Pa...@yahoo.com>.
Jeff,
From the newbie's experience, this is still have an issue if junit is
missing....
compile:
[mkdir] Created dir:
C:\Apache-CVS-UPD\jakarta-avalon-excalibur\concurrent\build\classes
[javac] Compiling 10 source files to
C:\Apache-CVS-UPD\jakarta-avalon-excalibur\concurrent\build\classes
[javac]
C:\Apache-CVS-UPD\jakarta-avalon-excalibur\concurrent\src\test\org\apache\avalon\excalibur\concurrent\test\ReadWriteLock
TestCase.java:10: package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac] ^
I appreciate that we all have junit in Ant's lib dir, but the newbie
does not. I think a simple warning would be good enough :
<target name="prepare">
// etc
<available classname="junit.framework.TestCase"
property="junit.present"/>
</target>
<target name="jnit-test" unless="junit.present">
<echo>*************************</echo>
<echo>
Hi, the compile of Exacilibur classes cannot happen without the
the presence of the JUnit for the comiple env. You may eithether 1)
put junit.jar in ant's lib directory, 2) rename the the
ant.properties.sample file in excaliburs root dir or 3) run the
'get-junit' target. After any of those try the failing ant target
again. Thanks for you patience.
</echo>
<echo>*************************</echo>
<fail message="Jnuit needed. See above."/>
</target>
Thoughts?
Good work Jeff, by the way :-)
- Paul
>Hi,
>
>I've got a dependency checking system for Excalibur working. In theory,
>it allows you to type 'ant' anywhere in Excalibur, and never see a
>compile error caused by missing dependencies. AFAICT, it works too :)
>
>It's in CVS in the 'depchecking' branch. To try it, run:
>
>cvs update -r depchecking
>
>Only the build.xml and .properties files will update, so it shouldn't do
>any harm.
>
>I put this stuff in a branch because it contains sufficient changes to
>deserve a vote before inclusion.
>
>
>It works as follows:
>
> - For internal dependencies (other components), it will recursively
> build those components if they need building.
>
> - For external dependencies like jmx.jar, junit.jar, altrmi, it will
> either print an error message saying "define this property", or do a
> HTTP GET to retrieve the file from somewhere.
>
>For example, say you download Excalibur, and want to build the Command
>component. It has these dependencies (in default.properties):
>
>excalibur-event
>excalibur-collections
>excalibur-concurrent
>excalibur-scratchpad
>excalibur-core
>excalibur-framework
>
>Then there's secondary dependencies:
> - event depends on collections and concurrent.
> - core and scratchpad depend on collections, concurrent, instrument,
> event and framework
>
>.. and so it goes. LOTS of dependencies, and a real pain to build
>manually. Now you no longer have to! The dep checking system recurses
>through that dependency tree, and on each leaf either builds the
>project, prints an error or does a HTTP GET to retrieve the jar. If a
>project is already built (eg 'collections'), or already downloaded (say,
>in your jar repository), then it's not built again.
>
>
>The system is implemented in a single file, depchecker.xml, which is called by
>each build.xml script. This is in the Excalibur root. If you type 'ant -d
>depchecker.xml', a rather verbose description of how to use it is printed:
>
>Buildfile: depchecker.xml
>
>usage:
> [echo]
> =======================================================
> This is Excalibur's dependency updater script.
> Which has been called incorrectly :)
>
> To use it, you must call the checkRequiredFile or
> checkRequiredClass targets from your Ant script.
>
> For example:
>
> <ant antfile="depchecker.xml" target="checkRequiredFile">
> <properties name="name" value="excalibur-concurrent.jar"/>
> <properties name="path" value="${excalibur-concurrent.jar}"/>
> <properties name="proj.home" value="../concurrent"/>
> <properties name="proj.target" value="dist.lite"/>
> </ant>
>
> That will check if ${excalibur-concurrent.jar} points to a jar, and
> if it doesn't, build the ${proj.home} project in order to generate
> the jar
>
> or:
>
> <ant antfile="depchecker.xml" target="checkRequiredFile">
> <property name="name" value="commons-io.jar"/>
> <property name="path" value="${lib.repo}/commons-io.jar"/>
> <property name="url" value="http://jakarta.apache.org/turbine/jars/commons-io.jar"/>
> </ant>
>
> That will check if ${lib.repo}/commons-io.jar exists, and if not,
> download it from ${url}
>
>
> The properties are as follows:
>
> For checkRequiredFile:
> name:
> Name of the jar. Eg 'avalon-collections.jar'
> path:
> Path to named jar. Eg ${avalon-collections.jar}
>
> proj.home (optional):
> Path to local project which builds the jar. Only set if the jar
> could be local, eg another component.
> proj.target (optional) [dist.lite]:
> Ant script target to run in local project to build the jar
>
> url (optional):
> URL to retrieve jar if not present on the local filesystem
>
> For checkRequiredClass:
> name:
> Name of jar in which the class usually resides
> class:
> Name of class to check for
> classpath:
> String classpath (; or : separated) to search for ${class} in
> =======================================================
>
>
>main:
>
>BUILD SUCCESSFUL
>
>Total time: 2 seconds
>
>
>I won't elaborate much on that here. Each build.xml has a "dependencies"
>target, which invokes checkRequiredFile for each jar, and likewise for
>classes.
>
>
>To implement this system, I had to make a few related changes, whose purpose
>isn't immediately obvious. I'll outline them here. This isn't required
>reading unless you're very upset about a certain change. The issues are
>complicated and multi-faceted. Not light reading. You have been warned
>:P
>
> - I renamed avalon-excalibur.jar to excalibur-core.jar, as discussed on
> the list earlier. Similarly, avalon-scratchpad.jar is now
> excalibur-scratchpad.jar. I haven't yet fixed excalibur-all.jar
> (sorry Berin).
>
> - I pulled all the build.xml properties into their own file,
> default.properties, and changed the order in which properties files
> are sourced to this:
>
> <property file="${user.home}/.ant.properties"/>
> <property file="../ant.properties"/>
> <property file="ant.properties"/>
> <property file="../default.properties"/>
> <property file="default.properties"/>
>
> Turbine people will find this familiar, because it's identical to how
> Turbine and Maven do things, except renaming build.properties to
> ant.properties.
>
> The reason for this is because I wanted somewhere to put
> default property values. With our old system, every user had to 'cp
> ant.properties.sample ant.properties', even to get the defaults. This
> explicit step should only be necessary for external dependencies,
> where we can't make a reasonable guess. That's where
> default.properties comes in. It is sourced last, and contains all the
> properties previously defined in build.xml, plus properties to jars
> of other components (eg "../foo/dist/excalibur-foo-1.0.jar").
>
> Why 'default.properties' instead of the existing
> 'project.properties'? Because:
> - It follows the Turbine/Torque/Fulcrum precedent
> - 'default.properties' is more location-agnostic. "project" implies
> that the file belongs to a project. Not true when you have
> 'project.properties' in a non-project directory like the Excalibur
> root. Same as how "ant.properties" is more function-agnostic than
> "build.properties".
>
> Note also that ${user.home}/.ant.properties and ../ant.properties are
> sourced before ./ant.properties. This is so that you can define
> ${base.path} or ${lib.repo}, or ${junit.jar} *once*. Previously, you
> had to define it, or undefine it, in *every* ant.properties. Why?
> Because our ant.properties.sample *must* have it, in case it's
> standalone, but IF it's present, it would override ../ant.properties.
> So our poor user is forced to either delete it if it's declared in
> ../ant.properties, or define it.
>
> If you're worried about this change, please ask and I'll explain some
> more. It's worked perfectly well for Turbine users for many years. It
> just takes some getting used to.
>
> - I added a 'dist.lite' target to all components. This generates a
> directory structure identical to a real distribution, but in a
> predictable location (../foo/dist) that can be pointed to from other
> components' default.properties files.
>
> - Other stuff I can't remember right now.
>
>
>So please 'cvs up -r depchecking', have a play, and report back.
>
>
>--Jeff
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>