You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Christopher Lenz <cm...@gmx.de> on 2003/04/17 11:15:30 UTC
Ant Integration
Hi Vincent and all,
I've been playing around more intensively with the new Ant integration,
and want to share some random thoughts on that topic here.
The first thing I noticed was that the means of integration into Ant
provided by this module is quite atypical. Usually, applications plug
into Ant by contributing tasks and types. They can be integrated into a
build by specifying <taskdef>s (and more seldomly, <typedef>s) as well
as copying a JAR into $ANT_HOME/lib or specifying the location in the
nested <classpath> of the <taskdef>. This is a pattern that all Ant
users have become quite familiar with.
The new Cactus/Ant-integration uses a different approach. It comes in a
ZIP archive that needs to be "installed" somewhere, and is integrated
into a build by setting some properties and calling targets in build
files somewhere in ${cactus.home}. The tasks we provide
(<runservertests> and <webxmlmerge>) are utility tasks that are not even
used directly by the importing build. This approach seems - at least to
me - very much influenced by the "Maven Way" of doing stuff. We are even
trying to hide the JARs required by Cactus from the user. Now, I
admit that I'm not really a big fan of Maven, but even still it seems
wrong to try to use Ant as if it was Maven.
I'd like to propose, and implement, a different integration concept,
that is more along the line of traditional Ant extensions. It would
provide a <cactus> task that'd be an extension of the <junit> task, but
provided means to manage container startup/shutdown as well running the
tests against multiple containers. It would *not* try to hide the Cactus
JARs from the user, simply because I as an Ant user want pretty complete
control and conscience about third-party libraries required for the
build, and I might even want to check those JARs into CVS. I also want
to perform the compilation and WAR packaging myself, to retain maximum
flexibility over what is going on. For example, I currently cannot pass
multiple source-paths (like src/java/share and src/java/j2ee13) to the
Ant integration for compilation, but rather need to copy them into a
single directory. Etc, etc.
I had posted something like this when the new Ant integration was first
proposed by Vincent, but here come some examples for the usage of the
proposed <cactus>-Task:
<cactus printsummary="yes" haltonfailure="yes">
<formatter type="xml"/>
<container type="tomcat4x" dir="${tomcat4x.home}"
url="http://localhost:${test.port}/${test.context}"
todir="${test.reports.tomcat4x.dir}"
timeout="180"/>
<container type="resin2x" dir="${resin2x.home}"
url="http://localhost:${test.port}/${test.context}"
todir="${test.reports.resin2x.dir}"/>
<batchtest>
<fileset dir="${src.tests}">
<include name="**/*Test*.java"/>
<exclude name="**/AllTests.java"/>
</fileset>
</batchtest>
</cactus>
The nested <container> elements here would work similarly to the script
fragments currently provided. It would reuse a lot of code from the
<runservertests> task. Note that the tests defined by the <batchtest>
element would be run twice: first on Tomcat 4.x, then on Resin 2.x. The
test report directory can be specified per container ('todir' attr).
But I want the <cactus> task to support more flexibility, too:
<cactus printsummary="yes" haltonfailure="yes">
...
<container
url="http://localhost:${test.port}/${test.context}"
todir="${test.reports.tomcat4x.dir}"
timeout="180">
<startup target="start.mycontainer"/>
<shutdown target="stop.mycontainer"/>
</container>
...
</cactus>
And even:
<cactus printsummary="yes" haltonfailure="yes">
...
<container
url="http://localhost:${test.port}/${test.context}"
todir="${test.reports.tomcat4x.dir}"
timeout="180">
<startup>
<java classname="com.evermind.server.ApplicationServer"
fork="yes">
<arg value="-config"/>
<arg file="conf/server.xml"/>
<classpath>
<fileset dir="${orion1x.home}" includes="*.jar"/>
</classpath>
</java>
</startup>
<shutdown>
...
</shutdown>
</container>
...
</cactus>
By means of implementing org.apache.tools.ant.TaskContainer, the
<startup> and <shutdown> nested elements can contain arbritrary tasks
that are then invoked to perform the actual startup and shutdown of the
container.
That's all for now. I've started experimenting with these ideas
yesterday, and think the above is doable. I personally like the approach
much better than the current one, as it is a more traditional way to
provide integration into Ant. Tight and easy integration is provided
while staying in the Ant mindset and offering much flexibility and power.
As quite some work has gone into the current integration module, and
also the Eclipse-plugin is very much dependant on it, this proposal is
naturally controversial. So, what do you think?
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Ant Integration
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
> Hi Chris,
>
> That looks very very cool. I have put some remarks below. Please don't
> take them negatively. I'm just trying to play the devil's advocate so
> that I understand how it works.
>
[snip]
>>
>> <cactus warfile="${test.dir}/test.war"
>
> that's the input war file right? The one that will get cactified?
No automatic "cactification" yet. Not sure whether that should really be
a goal either (see below).
>> printsummary="yes" haltonfailure="yes">
>> <sysproperty key="cactus.filterRedirectorName"
>> value="/test/filterRedirector.jsp"/>
>
> This is to override the default value, right?
Yep.
>> <classpath>
>> <path refid="cactus.runtime.classpath"/>
>
> hum... so does this mean users will have to get all Cactus-related jars
> and in their correct versions? I think that's a pain compared to the
> other integrations (existing Ant integration, Eclipse integration, Maven
> integration).
Well, yes. However, as I think I've pointed out in the original message
in this thread, I think it's wrong to try to hide the dependancies of
Cactus from an Ant build file. Ant is a lower-level tool than Eclipse or
Maven. No other application I know approaches its integration into Ant
in a way our current Ant integration does. That is my main criticism.
Rather than providing a ZIP with all the Cactus libs and many
configuration files and build file fragments, I'd like to provide a
single cactus-ant.jar that provides Ant tasks to integrate into Ant.
Compared to the tasks provided by Cactus 1.4.1, the <cactus> task would
provide a good abstraction that focusses on the core task of running
Cactus tasks from Ant. The user would, however, still need compile her
test code against the JUnit/Cactus framework, "cactify" the WAR, and
care about what libraries Cactus depends on.
That might sound like a step back, but as an Ant build manager I *want*
that control. Otherwise I could just use Maven ;-)
As a quick start path, we could provide a JAR that bundles all
dependancies, similar to what Checkstyle is doing with the
checkstyle-all.jar.
>> <pathelement location="${build.classes.dir}"/>
>> <pathelement location="${test.classes.dir}"/>
>> </classpath>
>> <formatter type="brief" usefile="false"/>
>> <formatter type="xml"/>
>> <batchtest>
>> <fileset dir="${src.test.dir}">
>> <include name="**/Test*.java"/>
>> <exclude name="**/TestAll.java"/>
>> </fileset>
>> </batchtest>
>> <containers>
>> <tomcat4x dir="${tomcat4x.home}" port="8080"
>> url="http://localhost:8080/test/..."
>> todir="${test.reports.dir}/tomcat4x"
>> output="tomcat4x.out">
>> </tomcat4x>
>> </containers>
>> </cactus>
>>
>>The last part is the most important of course :-)
>
> yep. Does it work dynamically? I mean is there a generic "container" tag
Yes, there's a generic container that works like I described initially:
<containers>
<generic url="http://localhost:8080/test/...">
<startup target="start.tomcat4x"/>
<shutdown target="stop.tomcat4x"/>
</generic>
</containers>
(and also works with embedded tasks instead of specifying a target).
> so that adding a new container is made easy? Where is the default
> behavior of the setup, configuration and deployment of the tomcat4x
The containers are implemented in code, using Ant APIs/Tasks. The
configuration files are stored in the JAR and are copied into the temp
container directory with filtering applied.
> container? How does the user knows what it does?
Documentation and, if that's not enough, source code.
>>I'm planning to remove the duplication that occurs for example in the
>>'url' attribute. The URL to ping could be easily assembled using the
>>WAR file name, the port and the redirector mappings in web.xml.
>
> +1
>
>>Also, the
>>required system properties cactus.contextURL and
>>cactus.*RedirectorName
>>could automatically be set from that information.
>
> I can't see where the webapp context is set in the <cactus> task. Is it
> taken from the name of the war that is passed? Is it overridable? Is it
> a fixed name liked cactustest?
Currently it's hard-wired to 'test', but that'll need to change of
course. I'd want to extract it from the WAR file name, I guess.
>>All in all, I'm pretty confident that this task is going to provide a
>>very good integration of Cactus into Ant. Not sure about creating an
>>integration/ant2 directory in CVS to commit this stuff to. I'll keep
>>hacking locally for now, and send some stuff to this list in the next
>>couple of days.
>
> Ok. Don't forget that we will need a transition period with the 2 Ant
> integration until we finish migrating all the front ends that currently
> use our ant integration: Sample Servlet, Eclipse plugin and Maven
> plugin.
Right. As I said, I wouldn't really like to see the current Ant
integration released, but I won't hold back a release if the
implementation of my proposal and the migration of the above subprojects
takes too long.
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Ant Integration
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Chris,
That looks very very cool. I have put some remarks below. Please don't
take them negatively. I'm just trying to play the devil's advocate so
that I understand how it works.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 21 April 2003 00:27
> To: Cactus Developers List
> Subject: Re: Ant Integration
>
> Hi Vincent,
>
> Vincent Massol wrote:
> [snip mucho]
> > -1. Lots of work has already been put in the Ant/Maven/Eclipse
> > integrations and there are lots of other things in Cactus that have
been
> > added and that we need to release.
> >
> > However +1 for implementing your idea in a integration/ant2
directory.
> > Or whatever name we want to use.
> >
> > Note: I'm getting more and more excited by your idea but I really
want
> > to release Cactus. That said, if you succeed in effectively
implementing
> > the new ant integration before we release, I would see no problem
> > swapping.
>
> Okay, I understand we shouldn't hold up a release for this stuff.
> However, we've been in close-to-release mode for a couple of months
now,
> and lots of changes have happened. So maybe I wasn't quite aware that
a
> release was closer than "close to" :-P
hehe :-). We're extremely late for the release. However, we only have a
few docs holding us before we can release. If we could all put our
energy on finishing these docs, we would be able to release in 2-3 days
I guess (In normal times I would have finished the doc long ago.
However, as you know I'm in the last stage of my junit book and this
currently takes all my time...). The list of docs to write is listed in
the todo page... :-). I'm loathe to release without these docs.
>
> In the meantime, I'm making nice progress on the implementation of
this
> proposal. I have the sample tests running against Tomcat 3.x and 4.x,
> and other containers should hopefully follow soon. This is what the
> corresponding part of my test build file looks like:
>
> <cactus warfile="${test.dir}/test.war"
that's the input war file right? The one that will get cactified?
> printsummary="yes" haltonfailure="yes">
> <sysproperty key="cactus.filterRedirectorName"
> value="/test/filterRedirector.jsp"/>
This is to override the default value, right?
> <classpath>
> <path refid="cactus.runtime.classpath"/>
hum... so does this mean users will have to get all Cactus-related jars
and in their correct versions? I think that's a pain compared to the
other integrations (existing Ant integration, Eclipse integration, Maven
integration).
> <pathelement location="${build.classes.dir}"/>
> <pathelement location="${test.classes.dir}"/>
> </classpath>
> <formatter type="brief" usefile="false"/>
> <formatter type="xml"/>
> <batchtest>
> <fileset dir="${src.test.dir}">
> <include name="**/Test*.java"/>
> <exclude name="**/TestAll.java"/>
> </fileset>
> </batchtest>
> <containers>
> <tomcat4x dir="${tomcat4x.home}" port="8080"
> url="http://localhost:8080/test/..."
> todir="${test.reports.dir}/tomcat4x"
> output="tomcat4x.out">
> </tomcat4x>
> </containers>
> </cactus>
>
> The last part is the most important of course :-)
yep. Does it work dynamically? I mean is there a generic "container" tag
so that adding a new container is made easy? Where is the default
behavior of the setup, configuration and deployment of the tomcat4x
container? How does the user knows what it does?
>
> This runs the tests against Tomcat 4.x, with the XML test reports
> generated in a container-specific directory, and the output of the
> container redirected into a file. There is also support for excluding
> specific test cases by name patterns from specific containers, and to
> exclude specific containers entirely (if/unless attributes). Specific
> containers can support individual attributes and elements of course,
so
> I could easily add a 'serverxml' attribute to the <tomcat4x> element,
or
> nested <user> elements to specify entries in the generated
> tomcat-users.xml configuration file. As so often, the options are
> infinite :-)
yep. ATM I'm more interested in the default behaviors which should mimic
what we currently have.
>
> I'm planning to remove the duplication that occurs for example in the
> 'url' attribute. The URL to ping could be easily assembled using the
WAR
> file name, the port and the redirector mappings in web.xml.
+1
> Also, the
> required system properties cactus.contextURL and
cactus.*RedirectorName
> could automatically be set from that information.
I can't see where the webapp context is set in the <cactus> task. Is it
taken from the name of the war that is passed? Is it overridable? Is it
a fixed name liked cactustest?
>
> All in all, I'm pretty confident that this task is going to provide a
> very good integration of Cactus into Ant. Not sure about creating an
> integration/ant2 directory in CVS to commit this stuff to. I'll keep
> hacking locally for now, and send some stuff to this list in the next
> couple of days.
Ok. Don't forget that we will need a transition period with the 2 Ant
integration until we finish migrating all the front ends that currently
use our ant integration: Sample Servlet, Eclipse plugin and Maven
plugin.
Thanks a lot
-Vincent
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Ant Integration
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Vincent,
Vincent Massol wrote:
[snip mucho]
> -1. Lots of work has already been put in the Ant/Maven/Eclipse
> integrations and there are lots of other things in Cactus that have been
> added and that we need to release.
>
> However +1 for implementing your idea in a integration/ant2 directory.
> Or whatever name we want to use.
>
> Note: I'm getting more and more excited by your idea but I really want
> to release Cactus. That said, if you succeed in effectively implementing
> the new ant integration before we release, I would see no problem
> swapping.
Okay, I understand we shouldn't hold up a release for this stuff.
However, we've been in close-to-release mode for a couple of months now,
and lots of changes have happened. So maybe I wasn't quite aware that a
release was closer than "close to" :-P
In the meantime, I'm making nice progress on the implementation of this
proposal. I have the sample tests running against Tomcat 3.x and 4.x,
and other containers should hopefully follow soon. This is what the
corresponding part of my test build file looks like:
<cactus warfile="${test.dir}/test.war"
printsummary="yes" haltonfailure="yes">
<sysproperty key="cactus.filterRedirectorName"
value="/test/filterRedirector.jsp"/>
<classpath>
<path refid="cactus.runtime.classpath"/>
<pathelement location="${build.classes.dir}"/>
<pathelement location="${test.classes.dir}"/>
</classpath>
<formatter type="brief" usefile="false"/>
<formatter type="xml"/>
<batchtest>
<fileset dir="${src.test.dir}">
<include name="**/Test*.java"/>
<exclude name="**/TestAll.java"/>
</fileset>
</batchtest>
<containers>
<tomcat4x dir="${tomcat4x.home}" port="8080"
url="http://localhost:8080/test/..."
todir="${test.reports.dir}/tomcat4x"
output="tomcat4x.out">
</tomcat4x>
</containers>
</cactus>
The last part is the most important of course :-)
This runs the tests against Tomcat 4.x, with the XML test reports
generated in a container-specific directory, and the output of the
container redirected into a file. There is also support for excluding
specific test cases by name patterns from specific containers, and to
exclude specific containers entirely (if/unless attributes). Specific
containers can support individual attributes and elements of course, so
I could easily add a 'serverxml' attribute to the <tomcat4x> element, or
nested <user> elements to specify entries in the generated
tomcat-users.xml configuration file. As so often, the options are
infinite :-)
I'm planning to remove the duplication that occurs for example in the
'url' attribute. The URL to ping could be easily assembled using the WAR
file name, the port and the redirector mappings in web.xml. Also, the
required system properties cactus.contextURL and cactus.*RedirectorName
could automatically be set from that information.
All in all, I'm pretty confident that this task is going to provide a
very good integration of Cactus into Ant. Not sure about creating an
integration/ant2 directory in CVS to commit this stuff to. I'll keep
hacking locally for now, and send some stuff to this list in the next
couple of days.
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Ant Integration
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 17 April 2003 13:47
> To: Cactus Developers List
> Subject: Re: Ant Integration
>
[snip]
> > actually you need 5 tags I believe:
> >
> > <configure>
> > <deploy>
> > <start>
> > <test>
> > <stop>
> >
>
> I don't think so. configure/deploy/start can be grouped into a single
> <startup> element, because they run sequentially directly after each
> other. <test> isn't needed because the tests defined as
> <batchtest>/<test> as nested element of the <cactus> task will be run
> for every container.
Right. I agree.
[snip]
> [snip]
> > I'm all for creating a proposal/ directory in Cactus where you can
> > experiment with this. I believe you'll find several issues, one
being to
> > answer how to provide default container configuration files. Only
> > solution I can see so far is by packaging them in the
> > cactus-integration-ant jar as resources.
>
> Do you see any problem with that?
No, not really.
>
> >>As quite some work has gone into the current integration module, and
> >>also the Eclipse-plugin is very much dependant on it, this proposal
is
> >>naturally controversial. So, what do you think?
> >
> > I think it's an excellent proposal. However, I would like us to
release
> > cactus 1.5 soon now (it's been way too long already). Thus I'd like
to
> > release with the current way of doing things (potentially explaining
> > that we are researching other ways), let you make your experiment in
> > HEAD and if successful roll it in Cactus 1.6 that we can release any
> > time after 1.5 is out.
>
> This I'm not sure about. Once the integration module currently in CVS
is
> released, it will no longer be easily possible to switch to the type
of
> integration I propose here, as it follows a radically different
approach
> (with major effects on packaging, for example).
I don't see any problem with that. The Ant Integration we have is very
similar to what was already there in Cactus 1.4.1. The difference is
that it has been made generic so that it provides a better quick start.
However, the rest is exactly the same and the same strategy than Cactus
1.4.1 can still be used.
> I realize this may sound
> too strong, but I personally have the feeling that the Ant integration
> module needs to be "fixed" before a release.
-1
We really need to release. Ideally we should really much more
frequently. That would help get feedback (which we are missing) and tell
users where we are going. We do not have to be perfect for a release.
If you wish we can add a statement that we are working developing a
better Ant integration that will replace the current one in the next
release. We can even add a web page with some ideas about where we are
going.
>
> But maybe we can find a compromise here. Requirements would be:
> - The distribution includes the scripts for starting/stopping
containers
> (which may need to be refactored into real standalone build files with
> dependancies on externally set properties), as well as the
configuration
> files
> - It would *not* contain the build-share.xml, meaning that users are
> themselves responsible for compiling the test cases and packaging the
> test WAR.
> - The distribution of the Ant integration would only contain the Ant
> integration JAR
> - The build of the Ant integration would only depend on the Ant
runtime
> (including Xerces).
> - Thus there would be no need to distribute separate packages for J2EE
> 1.2 and J2EE 1.3 (another gripe I have about the current solution)
>
> In that scenario there'd be an easy migration path to the proposed
> <cactus> task. Of course there'd be an initial loss of ease-of-use,
but
> then that's why it's a "compromise". Thoughts?
-1. Lots of work has already been put in the Ant/Maven/Eclipse
integrations and there are lots of other things in Cactus that have been
added and that we need to release.
However +1 for implementing your idea in a integration/ant2 directory.
Or whatever name we want to use.
Note: I'm getting more and more excited by your idea but I really want
to release Cactus. That said, if you succeed in effectively implementing
the new ant integration before we release, I would see no problem
swapping.
Thanks
-Vincent
>
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: Ant Integration
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Vincent,
thanks for the quick response.
Vincent Massol wrote:
[snip]
> Agreed but running Cactus from Ant has never been easier. For power
> users like you it may seem simple but most (if not all) cactus users are
> complaining about how difficult it is to use. With our current solution,
> it is really simple. To make it as simple we need to provide default
I agree that integrating Cactus into an Ant build has been challenging
with <= 1.4.x. The reason is of course that setting up, starting and
shutting down containers is in itself pretty complex, and Cactus only
provided the glue task <runservertests> and some helper classes to make
the process somewhat less painful.
However, I also find the the current integration module somewhat
confusing, and as I said, it feels "alien"-ish. While it provides an
easier way to integrate Cactus, I feel it's not "The Right Way" (tm).
> behaviour and package default config files. It must be able to work with
> the following minimal config:
>
> <cactus printsummary="yes" haltonfailure="yes">
> <formatter type="xml"/>
> <container type="tomcat4x" dir="${tomcat4x.home}"
> url="http://localhost:${test.port}/${test.context}"
> todir="${test.reports.tomcat4x.dir}"
> timeout="180"/>
> <batchtest>
> <fileset dir="${src.tests}">
> <include name="**/*Test*.java"/>
> <exclude name="**/AllTests.java"/>
> </fileset>
> </batchtest>
> </cactus>
Well, that would be a core requirement.
[snip]
>>But I want the <cactus> task to support more flexibility, too:
>>
>> <cactus printsummary="yes" haltonfailure="yes">
>> ...
>> <container
>> url="http://localhost:${test.port}/${test.context}"
>> todir="${test.reports.tomcat4x.dir}"
>> timeout="180">
>> <startup target="start.mycontainer"/>
>> <shutdown target="stop.mycontainer"/>
>> </container>
>> ...
>> </cactus>
>
> actually you need 5 tags I believe:
>
> <configure>
> <deploy>
> <start>
> <test>
> <stop>
>
I don't think so. configure/deploy/start can be grouped into a single
<startup> element, because they run sequentially directly after each
other. <test> isn't needed because the tests defined as
<batchtest>/<test> as nested element of the <cactus> task will be run
for every container.
You can think also think of these elements as pre/post hooks. <startup>
defines what will be done before the tests are run, <shutdown> defines
what will be run when the tests are done.
[snip]
> ... but you do realize that in practice it will be more complex that
> this as you also need to provide all container configuration files,
Well, if the user defines a custom container (i.e. not using the
<container type="..."> syntax), she will need to provide custom
configuration files. For the containers with builtin support, the
configuration files would be packaged in the JAR.
> define how to deploy containers, etc. In the end, if you want
> flexibility you'll end up having a full Ant script nested within the
> <container> tags... ;-)
The script doesn't need to be nested in the <startup>/<shutdown>
elements, as you can also define a target that should be called instead,
similar to <runservertests>.
[snip]
> I'm all for creating a proposal/ directory in Cactus where you can
> experiment with this. I believe you'll find several issues, one being to
> answer how to provide default container configuration files. Only
> solution I can see so far is by packaging them in the
> cactus-integration-ant jar as resources.
Do you see any problem with that?
>>As quite some work has gone into the current integration module, and
>>also the Eclipse-plugin is very much dependant on it, this proposal is
>>naturally controversial. So, what do you think?
>
> I think it's an excellent proposal. However, I would like us to release
> cactus 1.5 soon now (it's been way too long already). Thus I'd like to
> release with the current way of doing things (potentially explaining
> that we are researching other ways), let you make your experiment in
> HEAD and if successful roll it in Cactus 1.6 that we can release any
> time after 1.5 is out.
This I'm not sure about. Once the integration module currently in CVS is
released, it will no longer be easily possible to switch to the type of
integration I propose here, as it follows a radically different approach
(with major effects on packaging, for example). I realize this may sound
too strong, but I personally have the feeling that the Ant integration
module needs to be "fixed" before a release.
But maybe we can find a compromise here. Requirements would be:
- The distribution includes the scripts for starting/stopping containers
(which may need to be refactored into real standalone build files with
dependancies on externally set properties), as well as the configuration
files
- It would *not* contain the build-share.xml, meaning that users are
themselves responsible for compiling the test cases and packaging the
test WAR.
- The distribution of the Ant integration would only contain the Ant
integration JAR
- The build of the Ant integration would only depend on the Ant runtime
(including Xerces).
- Thus there would be no need to distribute separate packages for J2EE
1.2 and J2EE 1.3 (another gripe I have about the current solution)
In that scenario there'd be an easy migration path to the proposed
<cactus> task. Of course there'd be an initial loss of ease-of-use, but
then that's why it's a "compromise". Thoughts?
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: Ant Integration
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 17 April 2003 11:16
> To: Cactus Developers List
> Subject: Ant Integration
>
> Hi Vincent and all,
>
> I've been playing around more intensively with the new Ant
integration,
> and want to share some random thoughts on that topic here.
>
> The first thing I noticed was that the means of integration into Ant
> provided by this module is quite atypical.
Yes, Ant is limited in that regard (although this is by design :-)).
Which is why we have invented Maven... I believe Ant is really missing a
plugin feature (it is probably coming in the future).
> Usually, applications plug
> into Ant by contributing tasks and types. They can be integrated into
a
> build by specifying <taskdef>s (and more seldomly, <typedef>s) as well
> as copying a JAR into $ANT_HOME/lib or specifying the location in the
> nested <classpath> of the <taskdef>. This is a pattern that all Ant
> users have become quite familiar with.
Yes, but that does not cover the use case where you also want to
distribute any type of files (potentially configurable by the user).
>
> The new Cactus/Ant-integration uses a different approach. It comes in
a
> ZIP archive that needs to be "installed" somewhere, and is integrated
> into a build by setting some properties and calling targets in build
> files somewhere in ${cactus.home}.
Yes. If you want to remove the "installation" approach, another approach
is to put the Ant integration under your project (same as what the
sample-servlet is doing) and check it in your source repo:
myproject/
|_ build
|_ cactus-ant-integration/
|_ [...]
|_ src/java
|_ [...]
|_ build.xml
Note: Users can even customize it if they wish by:
- removing scripts they don't need
- modifying default configuration files
etc.
> The tasks we provide
> (<runservertests> and <webxmlmerge>) are utility tasks that are not
even
> used directly by the importing build. This approach seems - at least
to
> me - very much influenced by the "Maven Way" of doing stuff. We are
even
> trying to hide the JARs required by Cactus from the user. Now, I
> admit that I'm not really a big fan of Maven, but even still it seems
> wrong to try to use Ant as if it was Maven.
Hehe... I was surely biased by my Maven experience! :-)
>
> I'd like to propose, and implement, a different integration concept,
> that is more along the line of traditional Ant extensions. It would
> provide a <cactus> task that'd be an extension of the <junit> task,
but
> provided means to manage container startup/shutdown as well running
the
> tests against multiple containers. It would *not* try to hide the
Cactus
> JARs from the user, simply because I as an Ant user want pretty
complete
> control and conscience about third-party libraries required for the
> build, and I might even want to check those JARs into CVS. I also want
> to perform the compilation and WAR packaging myself, to retain maximum
> flexibility over what is going on. For example, I currently cannot
pass
> multiple source-paths (like src/java/share and src/java/j2ee13) to the
> Ant integration for compilation, but rather need to copy them into a
> single directory. Etc, etc.
Agreed but running Cactus from Ant has never been easier. For power
users like you it may seem simple but most (if not all) cactus users are
complaining about how difficult it is to use. With our current solution,
it is really simple. To make it as simple we need to provide default
behaviour and package default config files. It must be able to work with
the following minimal config:
<cactus printsummary="yes" haltonfailure="yes">
<formatter type="xml"/>
<container type="tomcat4x" dir="${tomcat4x.home}"
url="http://localhost:${test.port}/${test.context}"
todir="${test.reports.tomcat4x.dir}"
timeout="180"/>
<batchtest>
<fileset dir="${src.tests}">
<include name="**/*Test*.java"/>
<exclude name="**/AllTests.java"/>
</fileset>
</batchtest>
</cactus>
>
> I had posted something like this when the new Ant integration was
first
> proposed by Vincent, but here come some examples for the usage of the
> proposed <cactus>-Task:
>
> <cactus printsummary="yes" haltonfailure="yes">
> <formatter type="xml"/>
> <container type="tomcat4x" dir="${tomcat4x.home}"
> url="http://localhost:${test.port}/${test.context}"
> todir="${test.reports.tomcat4x.dir}"
> timeout="180"/>
> <container type="resin2x" dir="${resin2x.home}"
> url="http://localhost:${test.port}/${test.context}"
> todir="${test.reports.resin2x.dir}"/>
> <batchtest>
> <fileset dir="${src.tests}">
> <include name="**/*Test*.java"/>
> <exclude name="**/AllTests.java"/>
> </fileset>
> </batchtest>
> </cactus>
>
> The nested <container> elements here would work similarly to the
script
> fragments currently provided. It would reuse a lot of code from the
> <runservertests> task. Note that the tests defined by the <batchtest>
> element would be run twice: first on Tomcat 4.x, then on Resin 2.x.
The
> test report directory can be specified per container ('todir' attr).
>
> But I want the <cactus> task to support more flexibility, too:
>
> <cactus printsummary="yes" haltonfailure="yes">
> ...
> <container
> url="http://localhost:${test.port}/${test.context}"
> todir="${test.reports.tomcat4x.dir}"
> timeout="180">
> <startup target="start.mycontainer"/>
> <shutdown target="stop.mycontainer"/>
> </container>
> ...
> </cactus>
actually you need 5 tags I believe:
<configure>
<deploy>
<start>
<test>
<stop>
>
> And even:
>
> <cactus printsummary="yes" haltonfailure="yes">
> ...
> <container
> url="http://localhost:${test.port}/${test.context}"
> todir="${test.reports.tomcat4x.dir}"
> timeout="180">
> <startup>
> <java classname="com.evermind.server.ApplicationServer"
> fork="yes">
> <arg value="-config"/>
> <arg file="conf/server.xml"/>
> <classpath>
> <fileset dir="${orion1x.home}" includes="*.jar"/>
> </classpath>
> </java>
> </startup>
> <shutdown>
> ...
> </shutdown>
> </container>
> ...
> </cactus>
I very much like the idea! :-)
... but you do realize that in practice it will be more complex that
this as you also need to provide all container configuration files,
define how to deploy containers, etc. In the end, if you want
flexibility you'll end up having a full Ant script nested within the
<container> tags... ;-)
>
> By means of implementing org.apache.tools.ant.TaskContainer, the
> <startup> and <shutdown> nested elements can contain arbritrary tasks
> that are then invoked to perform the actual startup and shutdown of
the
> container.
>
> That's all for now. I've started experimenting with these ideas
> yesterday, and think the above is doable. I personally like the
approach
> much better than the current one, as it is a more traditional way to
> provide integration into Ant. Tight and easy integration is provided
> while staying in the Ant mindset and offering much flexibility and
power.
I'm all for creating a proposal/ directory in Cactus where you can
experiment with this. I believe you'll find several issues, one being to
answer how to provide default container configuration files. Only
solution I can see so far is by packaging them in the
cactus-integration-ant jar as resources.
>
> As quite some work has gone into the current integration module, and
> also the Eclipse-plugin is very much dependant on it, this proposal is
> naturally controversial. So, what do you think?
>
I think it's an excellent proposal. However, I would like us to release
cactus 1.5 soon now (it's been way too long already). Thus I'd like to
release with the current way of doing things (potentially explaining
that we are researching other ways), let you make your experiment in
HEAD and if successful roll it in Cactus 1.6 that we can release any
time after 1.5 is out.
Thanks a lot
-Vincent
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org