Vincent Massol wrote: [SNIP]
Okay, I've spent some more brain cells on this issue. IMHO, a separate <cactusCall> task is sorta ugly, and I'd rather opt for a simpler or a more elegant solution.- A special Ant task that would be the equivalent of the Ant <ant> task BUT that would allow to execute build files located inside a jar.
As I understand, our preliminary concern is reuse of the buildfile snippets in the sample-servlet. They should be packaged in the "Ant-Spine" JAR, and be usable without the need to extract them.
Now, consider the following snippet:
<?xml version="1.0"?>
<!DOCTYPE project [
<!ENTITY cactus_tomcat4_targets SYSTEM
"jar:file:cactus.jar!/.../build-tests-tomcat-40.xml">
]>
<project name="MyProject" default="test">
&cactus_tomcat4_targets;
<target name="test"
depends="test.tomcat.40">
</target>
</project>
(exact path inside the JAR ommitted for brevity).
The good news is: this actually works! :-)
So simply packaging up the buildfile fragments, and adding a tutorial with good documentation on properties and targets (like 'testwar') could be all we need...
In the long term, we should be watching and participating in the design of "Antlib", a target feature for Ant 1.6. Maybe, just maybe, we can sneek in support for calling targets defined in JARs... ;-)
Here are some potential usage scenarios:
<target name="test">
<property name="cactus.framework.jar" value="${lib.dir}/cactus.jar"/>
<property name="cactus.junit.jar" value="${lib.dir}/junit.jar"/> <property name="cactus.httpclient.jar"
value="${lib.dir}/httpclient.jar"/> <property name="cactus.commons-logging.jar"
value="${lib.dir}/commons-logging.jar"/>
[...]
<cactusCall buildfile="tomcat.4x.xml" jar="cactus-ant.jar"
target="test">
<param name="cactus.home" value="c:/apps/tomcat-4.1.18"/>
<param name="cactus.port" value="8080"/>
<param name="cactus.workdir" value="${target.dir}/tomcat"/>
<param name="cactus.war" value="${target.dir}/myapp.war"/>
</cactusCall>
</target>
Note1: The <params> can also be set as normal Ant properties.
Note2: The "test" target is the one that does it all, including
cactifying the application war by adding the cactus jars, etc.
Of course, we need to precisely define:
- the full list of properties that our Ant scriptlets will need
- the full list of targets provided by our Ant scriptlets
- the behaviours we want
Note: The only pity is that users still need to care about the cactus
jars. That's the advantage of Maven with its remote/local repositories.
So, what do you think?
Thanks
-Vincent
-- Christopher Lenz /=/ cmlenz at gmx.de
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
