Re: Ant subproject packaging

[Christopher Lenz]

see intermixed...

Vincent Massol wrote:
[SNIP]

- 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.

yep

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

same here ;-). I even thought about submitting a patch but when I
thought what it would need to be generic, it stopped me from going
further!

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:

I'm with you. That's even maybe a better idea. However, my only concern
is about reusability. The idea of this "ant" subproject is not to make
any assumption about how the frontend/spine is going to use it. ATM, we
have 3 possible candidates:
- user Ant scripts,
- Eclipse plugin
- Maven plugin

So we should allow each piece of "functionality" (like
start/stop/deploy/etc) to be accessible standalone. I'm also +1 to have
a super Ant <cactus> task that does it all though.

What I liked about the runservertests approach is that:
1/ it is reusable in context other than cactus
2/ it was completely generic with the name of targets being specified as
attributes
3/ should another project becomes the reference in
starting/stopping/deploying containers, any cactus user could switch to
it right away.

I guess I was viewing more this "ant" subproject as an API subproject
(although at the level of Ant targets) rather than an integrated way of
doing it all. That said, we can probably have both in the same project.

Agreed.

<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

Nice. Is the <junit> Ant task nicely inheritable? I'm ok with this
provided we also leave the option to run cactus tests using the plain
<junit> ant task, i.e. that the <cactus> task simply calls different
other targets that are also made available to the end user/tools should
they want.

I don't know, but I would think so.

A potential <cactus> task should be a high-level wrapper for functionality also available using lower-level methods, i.e. the <junit> and <runservertests> tasks combined with buildfile-fragments. And there could be a "generic" container-type that would let you specify targets like the <runservertests> task does.

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


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