Hi,
Well eventually I want to handle it differently but in the meantime I was
thinking of just creating a ant.properties file that contained the paths to
the relevent jars. ie For example you would create an ant.properties.sample
file that looked like
ant.properties.sample:
--------------------------------------------------------------------------------
## Instrument dependencies
#-----------------------------------------------#
| JUnit - needed for running the unit tests but |
| not needed during operation |
#-----------------------------------------------#
junit.jar=/opt/junit-3.7/junit3.7.jar
#-----------------------------------------------#
| Avalon Framework - needed for operational |
| mode |
#-----------------------------------------------#
framework.jar=/opt/AvalonFramework-4.1/avalon-framework-4.1.jar
#-----------------------------------------------#
| Excalibur CM - optional,if present will build |
| in support for instrumentaiton/profiling into |
| the ECM |
#-----------------------------------------------#
framework.jar=../ecm/build/lib/excalibur-ecm.jar
--------------------------------------------------------------------------------
And the build would fail with useful messages if the dependencies were not
present. Thus the user is responsible for copying the ant.properties.sample
to ant.properties and editing as they see fit.
This makes all the packages capable of being built outside their hierarchies
and you can track dependencies much easier. The downside is that it is a
little extra work - especially if the package is unstable. In which case it
may be possible to store the jars in CVS - however I would really really
really want to avoid this in the long run. In the meantime it may be best to
just have all the packages reference jars in ../all/lib/X.jar by default.
Anyways thats the short term goal. In the long term I wish to do something
like the following. First have a read of guide/extensions/versioning.html in
jdk1.3+ distribution. It defines a standard way to declare "optional
packages"/libraries/extensions etc. It also defines a standard way of
defining dependencies on the libraries. So I would eventually like each
package to declare their dependencies using this mechanism. And then some
magic task goes and searches and finds the jar that satisfies the dependency.
It would then add this to the builds classpath and generate an appropriate
manifest for the package being built.
For instance in Instruments case you would declare dependencies using a task
like
<library>
<dependency>
<extension>org.apache.avalon.framework</extension>
<version>4.1</version>
</dependency>
<dependency>
<extension>org.apache.excalibur.ecm</extension>
</dependency>
<gen-manifest destfile="build/manifest.mf"/>
<gen-classpath id="project.class.path"/>
</library>
This would generate an appropriate manifest in build/manifest.mf that
declared dependencies appropriately. It would also generate an ant classpath
reference "project.class.path" that contained all the locations of the proper
jars.
Anyways I haven't written that task yet but I will as soon as excalibur is
broken up a bit more so we can test it out. If all goes well then it *should*
make things a lot easier. Thoughts?
--
Cheers,
Pete
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
