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: <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]>
