> -----Original Message-----
> From: Christopher Lenz [mailto:[EMAIL PROTECTED]]
> Sent: 25 December 2002 21:48
> To: Cactus Developers List
> Subject: Re: Ant subproject packaging
>
> 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.
>
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.
>
> <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.
> 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 :-)
cool :-)
Thanks
-Vincent
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
