Re: Ant subproject packaging

[Christopher Lenz]

Vincent Massol wrote:

Hi,

This is some brainstorming ideas about the new "ant" subproject which
would provide reusable Ant scriptlets for persons wishing to use Ant as
their front end to run Cactus tests. The idea is the same than Maven,
i.e. to provide reusable best practices, directly usable by project Ant
scripts.

+1

The only real question is packaging. I would suggest this subproject
should deliver a single jar file containing:

- Ant tasks (the existing ones): RunServerTestsTask, StartServerTask,
etc
- Ant scripts for different containers
- 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.

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.

This I'm not so sure about... what you're saying is that, basically, all we'd need was a subclass of the <ant>-task that would accept a URL like "jar:file:/path/to/jar!/path/to/buildfile" in the antfile-attribute.

[Actually, I hoped Ant could do this out of the box, but I wasn't able to get it working, so it probably doesn't support generic URLs in for the antfile-attr :-( ]

I'd actually like our Ant integration to be more... errm... integrated :-). Like having a <cactus>-task that is derived from <junit> and has some extras like the ability to have nested elements to control container startup/shutdown:

<cactus haltonfailure="no">
<classpath>...</classpath>
<container type="tomcat4" homedir="${tomcat.home.40}">
<webapp dir="${test.webapp.dir}"/>
</container>
<batchtest>...</batchtest>
</cactus>
<junitreport>...</junitreport>

... or something totally different :-P
Internally the task would use Ant scripts stored in the JAR. Haven't really thought this through, obviously.

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?

I second the motivation, just not sure about the approach :-P

However, Ant is the primary/only frontend I personally use in my projects, and I've got an itch with the current "smell" in that area... so count me in :-)

--
Christopher Lenz
/=/ cmlenz at gmx.de


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>