Re: Ant subproject packaging

[Christopher Lenz <cm...@gmx.de>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>