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 jr...@apache.org on 2003/04/22 17:41:57 UTC
cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
jruaux 2003/04/22 08:41:57
Modified: integration/ant/src/java/org/apache/cactus/integration/ant
RunServerTestsTask.java
integration/ant/src/scripts/j2ee12 build-tests-tomcat3x.xml
integration/ant/src/scripts/j2ee13 build-tests-jboss3x.xml
integration/ant/src/scripts/share build-tests-orion1x.xml
build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml
build-tests-weblogic7x.xml
Log:
Added capability to specify a task to run instead of the 'cactus.test' target. This is needed for the Eclipse plug-in.
Revision Changes Path
1.3 +89 -3 jakarta-cactus/integration/ant/src/java/org/apache/cactus/integration/ant/RunServerTestsTask.java
Index: RunServerTestsTask.java
===================================================================
RCS file: /home/cvs/jakarta-cactus/integration/ant/src/java/org/apache/cactus/integration/ant/RunServerTestsTask.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- RunServerTestsTask.java 7 Feb 2003 17:16:58 -0000 1.2
+++ RunServerTestsTask.java 22 Apr 2003 15:41:57 -0000 1.3
@@ -56,7 +56,12 @@
*/
package org.apache.cactus.integration.ant;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+
import org.apache.tools.ant.BuildException;
+import org.apache.tools.ant.Project;
+import org.apache.tools.ant.ProjectComponent;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.taskdefs.CallTarget;
@@ -95,6 +100,11 @@
private String testTarget;
/**
+ * the fully qualified name of the test task.
+ */
+ private String testTask;
+
+ /**
* The helper object used to start the server. We use a helper so that it
* can also be reused in the <code>StartServerTask</code> task. Indeed,
* with Ant 1.3 and before there are classloaders issues with calling a
@@ -127,7 +137,7 @@
try
{
callStart();
- callTests();
+ callTestTaskOrTarget();
}
finally
{
@@ -141,6 +151,26 @@
}
/**
+ * Call the test task or test target.
+ */
+ private void callTestTaskOrTarget() throws BuildException
+ {
+ if (testTarget != null)
+ {
+ callTestTarget();
+ }
+ else
+ if (testTask != null)
+ {
+ callTestTask();
+ }
+ else
+ {
+ throw new BuildException("Missing required attribute, one of testTarget or testTask");
+ }
+ }
+
+ /**
* Call the start server task
*/
private void callStart()
@@ -159,7 +189,7 @@
/**
* Call the run tests target
*/
- private void callTests()
+ private void callTestTarget()
{
CallTarget callee;
@@ -175,6 +205,52 @@
}
/**
+ * Call the run tests target
+ */
+ private void callTestTask() throws BuildException
+ {
+ // Create task object
+ try
+ {
+
+ Class taskClass = Class.forName(testTask);
+ Object task = taskClass.newInstance();
+ Method[] methods = task.getClass().getMethods();
+ for (int i = 0; i < methods.length; i++)
+ {
+ if (methods[i].getName().equals("setProject")) {
+ Class[] parameters = methods[i].getParameterTypes();
+ Object[] arg = new Object[parameters.length];
+ for (int j=0;j<parameters.length;j++) {
+ arg[j] = parameters[j].newInstance();
+ }
+ arg[0] = project;
+ methods[i].invoke(task, arg);
+ }
+ }
+ taskClass.getMethod("execute", null).invoke(task, null);
+ }
+ catch (ClassNotFoundException e)
+ {
+ throw new BuildException(e);
+ }
+ catch (InstantiationException e)
+ {
+ throw new BuildException(e);
+ }
+ catch (IllegalAccessException e)
+ {
+ throw new BuildException(e);
+ }
+ catch (InvocationTargetException e) {
+ throw new BuildException(e);
+ }
+ catch (NoSuchMethodException e) {
+ throw new BuildException(e);
+ }
+ }
+
+ /**
* Sets the target to call to start the server.
*
* @param theStartTarget the Ant target to call
@@ -213,6 +289,16 @@
public void setTestTarget(String theTestTarget)
{
this.testTarget = theTestTarget;
+ }
+
+ /**
+ * Sets the target to call to run the tests.
+ *
+ * @param theTestTarget the Ant target to call
+ */
+ public void setTestTask(String theTestTask)
+ {
+ this.testTask = theTestTask;
}
/**
1.3 +18 -0 jakarta-cactus/integration/ant/src/scripts/j2ee12/build-tests-tomcat3x.xml
Index: build-tests-tomcat3x.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/integration/ant/src/scripts/j2ee12/build-tests-tomcat3x.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build-tests-tomcat3x.xml 2 Apr 2003 09:19:56 -0000 1.2
+++ build-tests-tomcat3x.xml 22 Apr 2003 15:41:57 -0000 1.3
@@ -16,6 +16,24 @@
unit tests, stop the servlet engine, wait for it to be stopped.
The servlet engine is stopped if the tests fail for any reason -->
+ <antcall target="cactus.runservertests.tomcat3x" inheritRefs="true"/>
+
+ </target>
+
+ <target name="cactus.runservertests.tomcat3x" depends="cactus.runservertests.task.tomcat3x, cactus.runservertests.target.tomcat3x"/>
+
+ <target name="cactus.runservertests.task.tomcat3x" if ="cactus.test.task">
+
+ <runservertests
+ testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
+ startTarget="cactus.start.tomcat3x"
+ stopTarget="cactus.stop.tomcat3x"
+ testTask="${cactus.test.task}"/>
+
+ </target>
+
+ <target name="cactus.runservertests.target.tomcat3x" unless="cactus.test.task">
+
<runservertests
testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
startTarget="cactus.start.tomcat3x"
1.6 +18 -0 jakarta-cactus/integration/ant/src/scripts/j2ee13/build-tests-jboss3x.xml
Index: build-tests-jboss3x.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/integration/ant/src/scripts/j2ee13/build-tests-jboss3x.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- build-tests-jboss3x.xml 3 Apr 2003 18:43:19 -0000 1.5
+++ build-tests-jboss3x.xml 22 Apr 2003 15:41:57 -0000 1.6
@@ -26,6 +26,24 @@
unit tests, stop the container, wait for it to be stopped.
The container is stopped if the tests fail for any reason -->
+ <antcall target="cactus.runservertests.jboss3x" inheritRefs="true"/>
+
+ </target>
+
+ <target name="cactus.runservertests.jboss3x" depends="cactus.runservertests.task.jboss3x, cactus.runservertests.target.jboss3x"/>
+
+ <target name="cactus.runservertests.task.jboss3x" if ="cactus.test.task">
+
+ <runservertests
+ testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
+ startTarget="cactus.start.jboss3x"
+ stopTarget="cactus.stop.jboss3x"
+ testTask="${cactus.test.task}"/>
+
+ </target>
+
+ <target name="cactus.runservertests.target.jboss3x" unless="cactus.test.task">
+
<runservertests
testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
startTarget="cactus.start.jboss3x"
1.3 +18 -0 jakarta-cactus/integration/ant/src/scripts/share/build-tests-orion1x.xml
Index: build-tests-orion1x.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/integration/ant/src/scripts/share/build-tests-orion1x.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build-tests-orion1x.xml 2 Apr 2003 09:19:56 -0000 1.2
+++ build-tests-orion1x.xml 22 Apr 2003 15:41:57 -0000 1.3
@@ -16,6 +16,24 @@
unit tests, stop the servlet engine, wait for it to be stopped.
The servlet engine is stopped if the tests fail for any reason -->
+ <antcall target="cactus.runservertests.orion1x" inheritRefs="true"/>
+
+ </target>
+
+ <target name="cactus.runservertests.orion1x" depends="cactus.runservertests.task.orion1x, cactus.runservertests.target.orion1x"/>
+
+ <target name="cactus.runservertests.task.orion1x" if ="cactus.test.task">
+
+ <runservertests
+ testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
+ startTarget="cactus.start.orion1x"
+ stopTarget="cactus.stop.orion1x"
+ testTask="${cactus.test.task}"/>
+
+ </target>
+
+ <target name="cactus.runservertests.target.orion1x" unless="cactus.test.task">
+
<runservertests
testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
startTarget="cactus.start.orion1x"
1.3 +18 -0 jakarta-cactus/integration/ant/src/scripts/share/build-tests-resin2x.xml
Index: build-tests-resin2x.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/integration/ant/src/scripts/share/build-tests-resin2x.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build-tests-resin2x.xml 2 Apr 2003 09:19:56 -0000 1.2
+++ build-tests-resin2x.xml 22 Apr 2003 15:41:57 -0000 1.3
@@ -16,6 +16,24 @@
unit tests, stop the servlet engine, wait for it to be stopped.
The servlet engine is stopped if the tests fail for any reason -->
+ <antcall target="cactus.runservertests.resin2x" inheritRefs="true"/>
+
+ </target>
+
+ <target name="cactus.runservertests.resin2x" depends="cactus.runservertests.task.resin2x, cactus.runservertests.target.resin2x"/>
+
+ <target name="cactus.runservertests.task.resin2x" if ="cactus.test.task">
+
+ <runservertests
+ testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
+ startTarget="cactus.start.resin2x"
+ stopTarget="cactus.stop.resin2x"
+ testTask="${cactus.test.task}"/>
+
+ </target>
+
+ <target name="cactus.runservertests.target.resin2x" unless="cactus.test.task">
+
<runservertests
testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
startTarget="cactus.start.resin2x"
1.3 +17 -0 jakarta-cactus/integration/ant/src/scripts/share/build-tests-tomcat4x.xml
Index: build-tests-tomcat4x.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/integration/ant/src/scripts/share/build-tests-tomcat4x.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build-tests-tomcat4x.xml 2 Apr 2003 09:19:56 -0000 1.2
+++ build-tests-tomcat4x.xml 22 Apr 2003 15:41:57 -0000 1.3
@@ -15,6 +15,23 @@
<!-- Start the servlet engine, wait for it to be started, run the
unit tests, stop the servlet engine, wait for it to be stopped.
The servlet engine is stopped if the tests fail for any reason -->
+ <antcall target="cactus.runservertests.tomcat4x" inheritRefs="true"/>
+
+ </target>
+
+ <target name="cactus.runservertests.tomcat4x" depends="cactus.runservertests.task.tomcat4x, cactus.runservertests.target.tomcat4x"/>
+
+ <target name="cactus.runservertests.task.tomcat4x" if ="cactus.test.task">
+
+ <runservertests
+ testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
+ startTarget="cactus.start.tomcat4x"
+ stopTarget="cactus.stop.tomcat4x"
+ testTask="${cactus.test.task}"/>
+
+ </target>
+
+ <target name="cactus.runservertests.target.tomcat4x" unless="cactus.test.task">
<runservertests
testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
1.4 +18 -0 jakarta-cactus/integration/ant/src/scripts/share/build-tests-weblogic6x.xml
Index: build-tests-weblogic6x.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/integration/ant/src/scripts/share/build-tests-weblogic6x.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- build-tests-weblogic6x.xml 2 Apr 2003 09:19:56 -0000 1.3
+++ build-tests-weblogic6x.xml 22 Apr 2003 15:41:57 -0000 1.4
@@ -24,6 +24,24 @@
unit tests, stop the servlet engine, wait for it to be stopped.
The servlet engine is stopped if the tests fail for any reason -->
+ <antcall target="cactus.runservertests.weblogic6x" inheritRefs="true"/>
+
+ </target>
+
+ <target name="cactus.runservertests.weblogic6x" depends="cactus.runservertests.task.weblogic6x, cactus.runservertests.target.weblogic6x"/>
+
+ <target name="cactus.runservertests.task.weblogic6x" if ="cactus.test.task">
+
+ <runservertests
+ testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
+ startTarget="cactus.start.weblogic6x"
+ stopTarget="cactus.stop.weblogic6x"
+ testTask="${cactus.test.task}"/>
+
+ </target>
+
+ <target name="cactus.runservertests.target.weblogic6x" unless="cactus.test.task">
+
<runservertests
testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
startTarget="cactus.start.weblogic6x"
1.3 +19 -0 jakarta-cactus/integration/ant/src/scripts/share/build-tests-weblogic7x.xml
Index: build-tests-weblogic7x.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/integration/ant/src/scripts/share/build-tests-weblogic7x.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build-tests-weblogic7x.xml 2 Apr 2003 09:19:56 -0000 1.2
+++ build-tests-weblogic7x.xml 22 Apr 2003 15:41:57 -0000 1.3
@@ -24,6 +24,24 @@
unit tests, stop the servlet engine, wait for it to be stopped.
The servlet engine is stopped if the tests fail for any reason -->
+ <antcall target="cactus.runservertests.weblogic7x" inheritRefs="true"/>
+
+ </target>
+
+ <target name="cactus.runservertests.weblogic7x" depends="cactus.runservertests.task.weblogic7x, cactus.runservertests.target.weblogic7x"/>
+
+ <target name="cactus.runservertests.task.weblogic7x" if ="cactus.test.task">
+
+ <runservertests
+ testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
+ startTarget="cactus.start.weblogic7x"
+ stopTarget="cactus.stop.weblogic7x"
+ testTask="${cactus.test.task}"/>
+
+ </target>
+
+ <target name="cactus.runservertests.target.weblogic7x" unless="cactus.test.task">
+
<runservertests
testURL="http://localhost:${cactus.port}/${cactus.context}/ServletRedirector?Cactus_Service=RUN_TEST"
startTarget="cactus.start.weblogic7x"
@@ -31,6 +49,7 @@
testTarget="cactus.test"/>
</target>
+
<!--
========================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 23 Apr 2003, Christopher Lenz <cm...@gmx.de> wrote:
> Right now, I can't even think of a single task that doesn't require
> at least one parameter except <tstamp>...
<fail/> ;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 23 Apr 2003, Christopher Lenz <cm...@gmx.de> wrote:
> Right, but Ant doesn't (AFAIK) have a routine to copy resources from
> ZIP/JAR files. (Hmm, does <copy> support a nested <zipfileset>?)
Not yet, we are working towards this. This means, don't hold your
breath 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent Massol wrote:
[snip]
>>In many ways, the implementation in Java improves the clarity of the
>>actions taken IMHO. I'm using the Ant API mostly for invoking the
>>container bootstrap classes (with the <java> task). For other things,
>>like copying resources from the Ant-integration JAR with filters
>>applied, I've written my own routines, or use standard JDK stuff.
>
>
> Be careful about not reinventing the wheel though. For example the Ant
> <copy> task has some nice features like verifying time stamps and not
> copying files when not necessary, ability to copy full directories, etc.
Right, but Ant doesn't (AFAIK) have a routine to copy resources from
ZIP/JAR files. (Hmm, does <copy> support a nested <zipfileset>?)
Really, when I wrote "written my own routines" I meant I've copied them
from the Ant code base and adapted them to fit my needs ;-)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 23 April 2003 19:11
> To: Cactus Developers List
> Subject: Re: cvs commit:
jakarta-cactus/integration/ant/src/scripts/share
> build-tests-orion1x.xml build-tests-resin2x.xml
build-tests-tomcat4x.xml
> build-tests-weblogic6x.xml build-tests-weblogic7x.xml
>
[snip]
> > I'm curious to see how you've implemented the packaging of
application
> > servers in java (the mkdir, copy, unzip, war, etc). Are you using
> > directly the Ant tasks (that would be the way I would do it)?
However it
>
> There's not soooo much magic to the container interaction. :-)
>
> In many ways, the implementation in Java improves the clarity of the
> actions taken IMHO. I'm using the Ant API mostly for invoking the
> container bootstrap classes (with the <java> task). For other things,
> like copying resources from the Ant-integration JAR with filters
> applied, I've written my own routines, or use standard JDK stuff.
Be careful about not reinventing the wheel though. For example the Ant
<copy> task has some nice features like verifying time stamps and not
copying files when not necessary, ability to copy full directories, etc.
[snip]
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Vincent,
Vincent Massol wrote:
>>-----Original Message-----
>>From: Christopher Lenz [mailto:cmlenz@gmx.de]
>>Sent: 23 April 2003 18:10
>>To: Cactus Developers List
>>Subject: Re: cvs commit:
[snip]
>>BTW my feeling that the Ant integration has started into a "wrong"
>>direction is getting stronger :-(
>
> If what you want to say is that Java is easier to reuse than a script
> language like Ant XML, I completely agree. Which is why I believe your
> proposed solution is better... It will make it easier to reuse the Ant
> integration from the Eclipse plugin, for sure :-)
Well, it's been a long time since I've looked at the code of the Eclipse
plugin, so I'm not sure how it is utilizing the Ant stuff. I don't know
whether the Eclipse plugin could benefit from the <cactus> task, but I
suspect it might simplify things a lot.
> I'm curious to see how you've implemented the packaging of application
> servers in java (the mkdir, copy, unzip, war, etc). Are you using
> directly the Ant tasks (that would be the way I would do it)? However it
There's not soooo much magic to the container interaction. :-)
In many ways, the implementation in Java improves the clarity of the
actions taken IMHO. I'm using the Ant API mostly for invoking the
container bootstrap classes (with the <java> task). For other things,
like copying resources from the Ant-integration JAR with filters
applied, I've written my own routines, or use standard JDK stuff.
The good thing is that you of course have *much* more power implementing
this stuff in Java than in Ant build file fragments. For example, I can
extract the mappings of the redirectors from the supplied WAR file and
set the corresponding Cactus system properties automatically. Or, I
detect the version of JBoss being used, and slightly alter the shutdown
command if the version is >= 3.2.
> is very flexible and if a user wants to do it slightly differently he is
> stuck... or has to use AOP programming (provided we offer some hooks)!
> :-) ... or has to rewrite it... or we'll introduce a scripting
> language... hehe ... we're closing the loop here! ;-)
Customization is of course important. That's why I think we should
continue to provide the build file fragments even when there's a
<cactus> task (and thus container support implemented in Java), so that
users have a template for writing custom targets for container interaction.
Apart from that, the <cactus> task already offers more control over the
in-container tests than the build file fragments ever have, and
container-specific features are easily added. For example, the
<tomcat*x> containers support a 'serverxml' attribute for user-provided
server configuration files, the <jboss3x> container supports a
'configname' attribute to specify the configuration, and the <weblogic>
container supports a 'beahome' attribute to specify the bea.home
property independently from the installation directory of the WL server.
> But I guess the advantages far outweight the few disadvantages and I
> very much like the approach you're taking.
Cool. I hope I can send you something tomorrow.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 23 April 2003 18:10
> To: Cactus Developers List
> Subject: Re: cvs commit:
jakarta-cactus/integration/ant/src/scripts/share
> build-tests-orion1x.xml build-tests-resin2x.xml
build-tests-tomcat4x.xml
> build-tests-weblogic6x.xml build-tests-weblogic7x.xml
>
> jruaux@apache.org wrote:
> > jruaux 2003/04/22 08:41:57
> >
> > Modified:
> integration/ant/src/java/org/apache/cactus/integration/ant
> > RunServerTestsTask.java
> > integration/ant/src/scripts/j2ee12 build-tests-
> tomcat3x.xml
> > integration/ant/src/scripts/j2ee13 build-tests-
> jboss3x.xml
> > integration/ant/src/scripts/share
build-tests-orion1x.xml
> > build-tests-resin2x.xml
build-tests-tomcat4x.xml
> > build-tests-weblogic6x.xml
> > build-tests-weblogic7x.xml
> > Log:
> > Added capability to specify a task to run instead of the
'cactus.test'
> target. This is needed for the Eclipse plug-in.
>
> Hold on... specifying a task class name as an attribute to
> <runservertests> seems very hack-ish. For example, it assumes that the
> task can be executed without parameters. Right now, I can't even think
> of a single task that doesn't require at least one parameter except
> <tstamp>...
>
> Can you please provide more details about what exactly the use case is
> in the Eclipse plugin?
>
> There are other ways to support calling tasks directly from
> <runservertests>, like:
>
> <runservertests starttarget="x" stoptarget="x">
> <test>
> <mytask/>
> </test>
> </runservertests>
>
> Would that work?
>
> BTW my feeling that the Ant integration has started into a "wrong"
> direction is getting stronger :-(
If what you want to say is that Java is easier to reuse than a script
language like Ant XML, I completely agree. Which is why I believe your
proposed solution is better... It will make it easier to reuse the Ant
integration from the Eclipse plugin, for sure :-)
I'm curious to see how you've implemented the packaging of application
servers in java (the mkdir, copy, unzip, war, etc). Are you using
directly the Ant tasks (that would be the way I would do it)? However it
is very flexible and if a user wants to do it slightly differently he is
stuck... or has to use AOP programming (provided we offer some hooks)!
:-) ... or has to rewrite it... or we'll introduce a scripting
language... hehe ... we're closing the loop here! ;-)
But I guess the advantages far outweight the few disadvantages and I
very much like the approach you're taking.
Thanks
-Vincent
>
> -chris
>
>
> ---------------------------------------------------------------------
> 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: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Julien Ruaux <jr...@octo.com>.
Yep, that was it : move the taskdef out of the inner target.
I'll modify the scripts.
Julien
-----Original Message-----
From: Christopher Lenz [mailto:cmlenz@gmx.de]
Sent: Tuesday, April 29, 2003 3:49 PM
To: Cactus Developers List
Subject: Re: cvs commit:
jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml
build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Hi Julien,
Julien Ruaux wrote:
> Hi Chris,
>
> I've just tried the new Ant integration with the Eclipse plug-in. I
> get an error while trying to run 'cactus.runservertests.task.tomcat4x'
> : could not create the task cactus.testTask.
Damn :-(
> I'll investigate and get back to you as soon as I find the problem.
Thanks. Please also try moving the <taskdef> outside of the <test>
element, i.e. directly above the <runservertests>.
-chris
---------------------------------------------------------------------
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: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Julien,
Julien Ruaux wrote:
> Hi Chris,
>
> I've just tried the new Ant integration with the Eclipse plug-in. I get
> an error while trying to run 'cactus.runservertests.task.tomcat4x' :
> could not create the task cactus.testTask.
Damn :-(
> I'll investigate and get back to you as soon as I find the problem.
Thanks. Please also try moving the <taskdef> outside of the <test>
element, i.e. directly above the <runservertests>.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Julien Ruaux wrote:
> Chris,
>
> I have tried to narrow down the problem. I've come to this :
>
> <target name="cactus.runservertests.task.tomcat4x" if
> ="cactus.test.task">
> <runservertests
> testURL="..."
> startTarget="cactus.start.tomcat4x"
> stopTarget="cactus.stop.tomcat4x">
> <test>
> <antcall target="cactus.test.eclipse"/>
> </test>
> </runservertests>
>
> </target>
>
> <target name="cactus.test.eclipse">
> <taskdef name="cactus.testTask" classname="${cactus.test.task}"/>
> <cactus.testTask/>
> </target>
>
>
> This works fine.
>
> Now if you replace the antcall by :
> <taskdef name="cactus.testTask"
> classname="${cactus.test.task}"/>
> <cactus.testTask>
>
> An error is thrown :
> "Could not create task or type of type: cactus.testTask.
> Ant could not find the task or a class this task relies upon."
>
> Any idea ?
In a simple test (using <fail>), the following worked:
<target name="cactus.runservertests.task.tomcat4x"
if="cactus.test.task">
<taskdef name="cactus.testTask" classname="${cactus.test.task}"/>
<runservertests
testURL="..."
startTarget="cactus.start.tomcat4x"
stopTarget="cactus.stop.tomcat4x">
<test>
<cactus.testTask>
</test>
</runservertests>
</target>
I'll commit that change in a second.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Man, there's a huge delay in mail delivery from Apache to day (at least
for me). I see that you've already committed the fix (pushing the
<taskdef> up. Does that it works and we can remove the 'testtask'
related stuff from <runservertests> again?
-chris
Julien Ruaux wrote:
> Chris,
>
> I have tried to narrow down the problem. I've come to this :
>
> <target name="cactus.runservertests.task.tomcat4x" if
> ="cactus.test.task">
> <runservertests
> testURL="..."
> startTarget="cactus.start.tomcat4x"
> stopTarget="cactus.stop.tomcat4x">
> <test>
> <antcall target="cactus.test.eclipse"/>
> </test>
> </runservertests>
>
> </target>
>
> <target name="cactus.test.eclipse">
> <taskdef name="cactus.testTask" classname="${cactus.test.task}"/>
> <cactus.testTask/>
> </target>
>
>
> This works fine.
>
> Now if you replace the antcall by :
> <taskdef name="cactus.testTask"
> classname="${cactus.test.task}"/>
> <cactus.testTask>
>
> An error is thrown :
> "Could not create task or type of type: cactus.testTask.
> Ant could not find the task or a class this task relies upon."
>
> Any idea ?
>
> Julien
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Julien Ruaux <jr...@octo.com>.
Chris,
I have tried to narrow down the problem. I've come to this :
<target name="cactus.runservertests.task.tomcat4x" if
="cactus.test.task">
<runservertests
testURL="..."
startTarget="cactus.start.tomcat4x"
stopTarget="cactus.stop.tomcat4x">
<test>
<antcall target="cactus.test.eclipse"/>
</test>
</runservertests>
</target>
<target name="cactus.test.eclipse">
<taskdef name="cactus.testTask" classname="${cactus.test.task}"/>
<cactus.testTask/>
</target>
This works fine.
Now if you replace the antcall by :
<taskdef name="cactus.testTask"
classname="${cactus.test.task}"/>
<cactus.testTask>
An error is thrown :
"Could not create task or type of type: cactus.testTask.
Ant could not find the task or a class this task relies upon."
Any idea ?
Julien
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Julien Ruaux <jr...@octo.com>.
Hi Chris,
I've just tried the new Ant integration with the Eclipse plug-in. I get
an error while trying to run 'cactus.runservertests.task.tomcat4x' :
could not create the task cactus.testTask.
I'll investigate and get back to you as soon as I find the problem.
Julien
-----Original Message-----
From: Christopher Lenz [mailto:cmlenz@gmx.de]
Sent: Monday, April 28, 2003 6:15 PM
To: Cactus Developers List
Subject: Re: cvs commit:
jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml
build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Okay. I've committed the changes to CVS. Please try whether it works for
you.
-chris
Julien Ruaux wrote:
> Yes, exactly. The Ant runner's classloader in Eclipse has already
> loaded the task class when I'm running the build.
>
> Julien
>
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
> Sent: Monday, April 28, 2003 5:50 PM
> To: cactus-dev@jakarta.apache.org
> Subject: Re: cvs commit:
> jakarta-cactus/integration/ant/src/scripts/share
> build-tests-orion1x.xml build-tests-resin2x.xml
> build-tests-tomcat4x.xml build-tests-weblogic6x.xml
> build-tests-weblogic7x.xml
>
>
> Julien Ruaux wrote:
>
>>Hi Chris,
>>
>>this looks better than the actual solution, so I wholly agree !
>
>
> Okay, cool. Only problem is the classpath of the <taskdef>. Do you
> have
> the task class in a parent loader when executing the Ant stuff?
>
>
>>Julien
>>
>>-----Original Message-----
>>From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
>>Sent: Monday, April 28, 2003 3:36 PM
>>To: cactus-dev@jakarta.apache.org
>>Subject: Re: cvs commit:
>>jakarta-cactus/integration/ant/src/scripts/share
>>build-tests-orion1x.xml build-tests-resin2x.xml
>>build-tests-tomcat4x.xml build-tests-weblogic6x.xml
>>build-tests-weblogic7x.xml
>>
>>
>>Hi Julien,
>>
>>I'd really like to avoid bloating the <runservertests> task with
>>features that are only usable in a very specific context, which I
>
> think
>
>>applies here.
>>
>>In this case, I think there's a better way to do this: make the
>><runservertests> accept nested elements <start>, <test> and <stop>
>
> that
>
>>were TaskContainers. These elements would be alternatives to the
>>starttarget, testtarget and stopstarget attributes. So you could
>
> write:
>
>> <runservertests starttarget="bla" stoptarget="blabla">
>> <test>
>> <taskdef name="cactustesttask" classname="${cactus.test.task}">
>> <cactustesttask/>
>> </test>
>> </runservertests>
>>
>>Of course this doesn't look nice, but in the long term we should
>>migrate
>>
>>the Eclipse plugin to use the container support classes I committed to
>>the CACTUS_14_ANT_BRANCH anyway, IMHO.
>>
>>The above is usable from any Ant script and may be a nice alternative
>>to
>>
>>writing targets for everything in some situations. If you can agree on
>>this, I volunteer to implement it in the RunServerTestsTask, as all of
>
>
>>the code required is already in GenericContainer.java in the Ant
>>integration proposal branch.
>>
>>What do you think?
>>
>>-chris
>>
>>Julien Ruaux wrote:
>>
>>
>>>Hi Chris,
>>>
>>>The use-case for the Eclipse plug-in is to be able to make
>>>runservertests execute a custom task (which is part of the Eclipse
>>>plug-in : o.a.c.eclipse.runner.containers.ant.EclipseRunTests).
>>>To do so without having the definition of this custom task hard coded
>>>in the script, the property 'cactus.test.task' was introduced which
>>>specifies the fully qualified name of an Ant task class.
>>>
>>>Julien
>
---------------------------------------------------------------------
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: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Okay. I've committed the changes to CVS. Please try whether it works for
you.
-chris
Julien Ruaux wrote:
> Yes, exactly. The Ant runner's classloader in Eclipse has already loaded
> the task class when I'm running the build.
>
> Julien
>
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
> Sent: Monday, April 28, 2003 5:50 PM
> To: cactus-dev@jakarta.apache.org
> Subject: Re: cvs commit:
> jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml
> build-tests-resin2x.xml build-tests-tomcat4x.xml
> build-tests-weblogic6x.xml build-tests-weblogic7x.xml
>
>
> Julien Ruaux wrote:
>
>>Hi Chris,
>>
>>this looks better than the actual solution, so I wholly agree !
>
>
> Okay, cool. Only problem is the classpath of the <taskdef>. Do you have
> the task class in a parent loader when executing the Ant stuff?
>
>
>>Julien
>>
>>-----Original Message-----
>>From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
>>Sent: Monday, April 28, 2003 3:36 PM
>>To: cactus-dev@jakarta.apache.org
>>Subject: Re: cvs commit:
>>jakarta-cactus/integration/ant/src/scripts/share
>>build-tests-orion1x.xml build-tests-resin2x.xml
>>build-tests-tomcat4x.xml build-tests-weblogic6x.xml
>>build-tests-weblogic7x.xml
>>
>>
>>Hi Julien,
>>
>>I'd really like to avoid bloating the <runservertests> task with
>>features that are only usable in a very specific context, which I
>
> think
>
>>applies here.
>>
>>In this case, I think there's a better way to do this: make the
>><runservertests> accept nested elements <start>, <test> and <stop>
>
> that
>
>>were TaskContainers. These elements would be alternatives to the
>>starttarget, testtarget and stopstarget attributes. So you could
>
> write:
>
>> <runservertests starttarget="bla" stoptarget="blabla">
>> <test>
>> <taskdef name="cactustesttask" classname="${cactus.test.task}">
>> <cactustesttask/>
>> </test>
>> </runservertests>
>>
>>Of course this doesn't look nice, but in the long term we should
>>migrate
>>
>>the Eclipse plugin to use the container support classes I committed to
>>the CACTUS_14_ANT_BRANCH anyway, IMHO.
>>
>>The above is usable from any Ant script and may be a nice alternative
>>to
>>
>>writing targets for everything in some situations. If you can agree on
>>this, I volunteer to implement it in the RunServerTestsTask, as all of
>
>
>>the code required is already in GenericContainer.java in the Ant
>>integration proposal branch.
>>
>>What do you think?
>>
>>-chris
>>
>>Julien Ruaux wrote:
>>
>>
>>>Hi Chris,
>>>
>>>The use-case for the Eclipse plug-in is to be able to make
>>>runservertests execute a custom task (which is part of the Eclipse
>>>plug-in : o.a.c.eclipse.runner.containers.ant.EclipseRunTests).
>>>To do so without having the definition of this custom task hard coded
>>>in the script, the property 'cactus.test.task' was introduced which
>>>specifies the fully qualified name of an Ant task class.
>>>
>>>Julien
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Julien Ruaux <jr...@octo.com>.
Yes, exactly. The Ant runner's classloader in Eclipse has already loaded
the task class when I'm running the build.
Julien
-----Original Message-----
From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
Sent: Monday, April 28, 2003 5:50 PM
To: cactus-dev@jakarta.apache.org
Subject: Re: cvs commit:
jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml
build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Julien Ruaux wrote:
> Hi Chris,
>
> this looks better than the actual solution, so I wholly agree !
Okay, cool. Only problem is the classpath of the <taskdef>. Do you have
the task class in a parent loader when executing the Ant stuff?
> Julien
>
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
> Sent: Monday, April 28, 2003 3:36 PM
> To: cactus-dev@jakarta.apache.org
> Subject: Re: cvs commit:
> jakarta-cactus/integration/ant/src/scripts/share
> build-tests-orion1x.xml build-tests-resin2x.xml
> build-tests-tomcat4x.xml build-tests-weblogic6x.xml
> build-tests-weblogic7x.xml
>
>
> Hi Julien,
>
> I'd really like to avoid bloating the <runservertests> task with
> features that are only usable in a very specific context, which I
think
> applies here.
>
> In this case, I think there's a better way to do this: make the
> <runservertests> accept nested elements <start>, <test> and <stop>
that
> were TaskContainers. These elements would be alternatives to the
> starttarget, testtarget and stopstarget attributes. So you could
write:
>
> <runservertests starttarget="bla" stoptarget="blabla">
> <test>
> <taskdef name="cactustesttask" classname="${cactus.test.task}">
> <cactustesttask/>
> </test>
> </runservertests>
>
> Of course this doesn't look nice, but in the long term we should
> migrate
>
> the Eclipse plugin to use the container support classes I committed to
> the CACTUS_14_ANT_BRANCH anyway, IMHO.
>
> The above is usable from any Ant script and may be a nice alternative
> to
>
> writing targets for everything in some situations. If you can agree on
> this, I volunteer to implement it in the RunServerTestsTask, as all of
> the code required is already in GenericContainer.java in the Ant
> integration proposal branch.
>
> What do you think?
>
> -chris
>
> Julien Ruaux wrote:
>
>>Hi Chris,
>>
>>The use-case for the Eclipse plug-in is to be able to make
>>runservertests execute a custom task (which is part of the Eclipse
>>plug-in : o.a.c.eclipse.runner.containers.ant.EclipseRunTests).
>>To do so without having the definition of this custom task hard coded
>>in the script, the property 'cactus.test.task' was introduced which
>>specifies the fully qualified name of an Ant task class.
>>
>>Julien
---------------------------------------------------------------------
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: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Julien Ruaux wrote:
> Hi Chris,
>
> this looks better than the actual solution, so I wholly agree !
Okay, cool. Only problem is the classpath of the <taskdef>. Do you have
the task class in a parent loader when executing the Ant stuff?
> Julien
>
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
> Sent: Monday, April 28, 2003 3:36 PM
> To: cactus-dev@jakarta.apache.org
> Subject: Re: cvs commit:
> jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml
> build-tests-resin2x.xml build-tests-tomcat4x.xml
> build-tests-weblogic6x.xml build-tests-weblogic7x.xml
>
>
> Hi Julien,
>
> I'd really like to avoid bloating the <runservertests> task with
> features that are only usable in a very specific context, which I think
> applies here.
>
> In this case, I think there's a better way to do this: make the
> <runservertests> accept nested elements <start>, <test> and <stop> that
> were TaskContainers. These elements would be alternatives to the
> starttarget, testtarget and stopstarget attributes. So you could write:
>
> <runservertests starttarget="bla" stoptarget="blabla">
> <test>
> <taskdef name="cactustesttask" classname="${cactus.test.task}">
> <cactustesttask/>
> </test>
> </runservertests>
>
> Of course this doesn't look nice, but in the long term we should migrate
>
> the Eclipse plugin to use the container support classes I committed to
> the CACTUS_14_ANT_BRANCH anyway, IMHO.
>
> The above is usable from any Ant script and may be a nice alternative to
>
> writing targets for everything in some situations. If you can agree on
> this, I volunteer to implement it in the RunServerTestsTask, as all of
> the code required is already in GenericContainer.java in the Ant
> integration proposal branch.
>
> What do you think?
>
> -chris
>
> Julien Ruaux wrote:
>
>>Hi Chris,
>>
>>The use-case for the Eclipse plug-in is to be able to make
>>runservertests execute a custom task (which is part of the Eclipse
>>plug-in : o.a.c.eclipse.runner.containers.ant.EclipseRunTests).
>>To do so without having the definition of this custom task hard coded
>>in the script, the property 'cactus.test.task' was introduced which
>>specifies the fully qualified name of an Ant task class.
>>
>>Julien
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Julien Ruaux <jr...@octo.com>.
Hi Chris,
this looks better than the actual solution, so I wholly agree !
Julien
-----Original Message-----
From: news [mailto:news@main.gmane.org] On Behalf Of Christopher Lenz
Sent: Monday, April 28, 2003 3:36 PM
To: cactus-dev@jakarta.apache.org
Subject: Re: cvs commit:
jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml
build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Hi Julien,
I'd really like to avoid bloating the <runservertests> task with
features that are only usable in a very specific context, which I think
applies here.
In this case, I think there's a better way to do this: make the
<runservertests> accept nested elements <start>, <test> and <stop> that
were TaskContainers. These elements would be alternatives to the
starttarget, testtarget and stopstarget attributes. So you could write:
<runservertests starttarget="bla" stoptarget="blabla">
<test>
<taskdef name="cactustesttask" classname="${cactus.test.task}">
<cactustesttask/>
</test>
</runservertests>
Of course this doesn't look nice, but in the long term we should migrate
the Eclipse plugin to use the container support classes I committed to
the CACTUS_14_ANT_BRANCH anyway, IMHO.
The above is usable from any Ant script and may be a nice alternative to
writing targets for everything in some situations. If you can agree on
this, I volunteer to implement it in the RunServerTestsTask, as all of
the code required is already in GenericContainer.java in the Ant
integration proposal branch.
What do you think?
-chris
Julien Ruaux wrote:
> Hi Chris,
>
> The use-case for the Eclipse plug-in is to be able to make
> runservertests execute a custom task (which is part of the Eclipse
> plug-in : o.a.c.eclipse.runner.containers.ant.EclipseRunTests).
> To do so without having the definition of this custom task hard coded
> in the script, the property 'cactus.test.task' was introduced which
> specifies the fully qualified name of an Ant task class.
>
> Julien
---------------------------------------------------------------------
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: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Julien,
I'd really like to avoid bloating the <runservertests> task with
features that are only usable in a very specific context, which I think
applies here.
In this case, I think there's a better way to do this: make the
<runservertests> accept nested elements <start>, <test> and <stop> that
were TaskContainers. These elements would be alternatives to the
starttarget, testtarget and stopstarget attributes. So you could write:
<runservertests starttarget="bla" stoptarget="blabla">
<test>
<taskdef name="cactustesttask" classname="${cactus.test.task}">
<cactustesttask/>
</test>
</runservertests>
Of course this doesn't look nice, but in the long term we should migrate
the Eclipse plugin to use the container support classes I committed to
the CACTUS_14_ANT_BRANCH anyway, IMHO.
The above is usable from any Ant script and may be a nice alternative to
writing targets for everything in some situations. If you can agree on
this, I volunteer to implement it in the RunServerTestsTask, as all of
the code required is already in GenericContainer.java in the Ant
integration proposal branch.
What do you think?
-chris
Julien Ruaux wrote:
> Hi Chris,
>
> The use-case for the Eclipse plug-in is to be able to make
> runservertests execute a custom task (which is part of the Eclipse
> plug-in : o.a.c.eclipse.runner.containers.ant.EclipseRunTests).
> To do so without having the definition of this custom task hard coded in
> the script, the property 'cactus.test.task' was introduced which
> specifies the fully qualified name of an Ant task class.
>
> Julien
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Julien Ruaux <jr...@octo.com>.
Hi Chris,
The use-case for the Eclipse plug-in is to be able to make
runservertests execute a custom task (which is part of the Eclipse
plug-in : o.a.c.eclipse.runner.containers.ant.EclipseRunTests).
To do so without having the definition of this custom task hard coded in
the script, the property 'cactus.test.task' was introduced which
specifies the fully qualified name of an Ant task class.
Julien
-----Original Message-----
From: Christopher Lenz [mailto:cmlenz@gmx.de]
Sent: Wednesday, April 23, 2003 6:58 PM
To: Cactus Developers List
Subject: Re: cvs commit:
jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml
build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Hi Julien,
I don't quite understand yet... what *is* the Eclipse plug-in use case?
What is the task that should get called to perform the tests?
-chris
Julien Ruaux wrote:
> The idea was first to support the Eclipse plug-in use case in Ant
> integration. Then Vincent thought it would be better to provide
> something generic, where the task running the tests could be
> specified. That is why this 'cactus.test.task' property was
> introduced. Do you see any better way of doing this ?
>
> Julien
>
>
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: Wednesday, April 23, 2003 6:10 PM
> To: Cactus Developers List
> Subject: Re: cvs commit:
> jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml
> build-tests-resin2x.xml build-tests-tomcat4x.xml
> build-tests-weblogic6x.xml build-tests-weblogic7x.xml
>
>
> jruaux@apache.org wrote:
>
>>jruaux 2003/04/22 08:41:57
>>
>> Modified:
>
> integration/ant/src/java/org/apache/cactus/integration/ant
>
>> RunServerTestsTask.java
>> integration/ant/src/scripts/j2ee12
>
> build-tests-tomcat3x.xml
>
>> integration/ant/src/scripts/j2ee13
>
> build-tests-jboss3x.xml
>
>> integration/ant/src/scripts/share
>
> build-tests-orion1x.xml
>
>> build-tests-resin2x.xml
>
> build-tests-tomcat4x.xml
>
>> build-tests-weblogic6x.xml
>> build-tests-weblogic7x.xml
>> Log:
>> Added capability to specify a task to run instead of the
>>'cactus.test' target. This is needed for the Eclipse plug-in.
>
>
> Hold on... specifying a task class name as an attribute to
> <runservertests> seems very hack-ish. For example, it assumes that the
> task can be executed without parameters. Right now, I can't even think
> of a single task that doesn't require at least one parameter except
> <tstamp>...
>
> Can you please provide more details about what exactly the use case is
> in the Eclipse plugin?
>
> There are other ways to support calling tasks directly from
> <runservertests>, like:
>
> <runservertests starttarget="x" stoptarget="x">
> <test>
> <mytask/>
> </test>
> </runservertests>
>
> Would that work?
>
> BTW my feeling that the Ant integration has started into a "wrong"
> direction is getting stronger :-(
>
> -chris
---------------------------------------------------------------------
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: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Julien,
I don't quite understand yet... what *is* the Eclipse plug-in use case?
What is the task that should get called to perform the tests?
-chris
Julien Ruaux wrote:
> The idea was first to support the Eclipse plug-in use case in Ant
> integration. Then Vincent thought it would be better to provide
> something generic, where the task running the tests could be specified.
> That is why this 'cactus.test.task' property was introduced.
> Do you see any better way of doing this ?
>
> Julien
>
>
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: Wednesday, April 23, 2003 6:10 PM
> To: Cactus Developers List
> Subject: Re: cvs commit:
> jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml
> build-tests-resin2x.xml build-tests-tomcat4x.xml
> build-tests-weblogic6x.xml build-tests-weblogic7x.xml
>
>
> jruaux@apache.org wrote:
>
>>jruaux 2003/04/22 08:41:57
>>
>> Modified:
>
> integration/ant/src/java/org/apache/cactus/integration/ant
>
>> RunServerTestsTask.java
>> integration/ant/src/scripts/j2ee12
>
> build-tests-tomcat3x.xml
>
>> integration/ant/src/scripts/j2ee13
>
> build-tests-jboss3x.xml
>
>> integration/ant/src/scripts/share
>
> build-tests-orion1x.xml
>
>> build-tests-resin2x.xml
>
> build-tests-tomcat4x.xml
>
>> build-tests-weblogic6x.xml
>> build-tests-weblogic7x.xml
>> Log:
>> Added capability to specify a task to run instead of the
>>'cactus.test' target. This is needed for the Eclipse plug-in.
>
>
> Hold on... specifying a task class name as an attribute to
> <runservertests> seems very hack-ish. For example, it assumes that the
> task can be executed without parameters. Right now, I can't even think
> of a single task that doesn't require at least one parameter except
> <tstamp>...
>
> Can you please provide more details about what exactly the use case is
> in the Eclipse plugin?
>
> There are other ways to support calling tasks directly from
> <runservertests>, like:
>
> <runservertests starttarget="x" stoptarget="x">
> <test>
> <mytask/>
> </test>
> </runservertests>
>
> Would that work?
>
> BTW my feeling that the Ant integration has started into a "wrong"
> direction is getting stronger :-(
>
> -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: cvs commit: jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Julien Ruaux <jr...@octo.com>.
The idea was first to support the Eclipse plug-in use case in Ant
integration. Then Vincent thought it would be better to provide
something generic, where the task running the tests could be specified.
That is why this 'cactus.test.task' property was introduced.
Do you see any better way of doing this ?
Julien
-----Original Message-----
From: Christopher Lenz [mailto:cmlenz@gmx.de]
Sent: Wednesday, April 23, 2003 6:10 PM
To: Cactus Developers List
Subject: Re: cvs commit:
jakarta-cactus/integration/ant/src/scripts/share build-tests-orion1x.xml
build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
jruaux@apache.org wrote:
> jruaux 2003/04/22 08:41:57
>
> Modified:
integration/ant/src/java/org/apache/cactus/integration/ant
> RunServerTestsTask.java
> integration/ant/src/scripts/j2ee12
build-tests-tomcat3x.xml
> integration/ant/src/scripts/j2ee13
build-tests-jboss3x.xml
> integration/ant/src/scripts/share
build-tests-orion1x.xml
> build-tests-resin2x.xml
build-tests-tomcat4x.xml
> build-tests-weblogic6x.xml
> build-tests-weblogic7x.xml
> Log:
> Added capability to specify a task to run instead of the
> 'cactus.test' target. This is needed for the Eclipse plug-in.
Hold on... specifying a task class name as an attribute to
<runservertests> seems very hack-ish. For example, it assumes that the
task can be executed without parameters. Right now, I can't even think
of a single task that doesn't require at least one parameter except
<tstamp>...
Can you please provide more details about what exactly the use case is
in the Eclipse plugin?
There are other ways to support calling tasks directly from
<runservertests>, like:
<runservertests starttarget="x" stoptarget="x">
<test>
<mytask/>
</test>
</runservertests>
Would that work?
BTW my feeling that the Ant integration has started into a "wrong"
direction is getting stronger :-(
-chris
---------------------------------------------------------------------
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: cvs commit: jakarta-cactus/integration/ant/src/scripts/share
build-tests-orion1x.xml build-tests-resin2x.xml build-tests-tomcat4x.xml
build-tests-weblogic6x.xml build-tests-weblogic7x.xml
Posted by Christopher Lenz <cm...@gmx.de>.
jruaux@apache.org wrote:
> jruaux 2003/04/22 08:41:57
>
> Modified: integration/ant/src/java/org/apache/cactus/integration/ant
> RunServerTestsTask.java
> integration/ant/src/scripts/j2ee12 build-tests-tomcat3x.xml
> integration/ant/src/scripts/j2ee13 build-tests-jboss3x.xml
> integration/ant/src/scripts/share build-tests-orion1x.xml
> build-tests-resin2x.xml build-tests-tomcat4x.xml
> build-tests-weblogic6x.xml
> build-tests-weblogic7x.xml
> Log:
> Added capability to specify a task to run instead of the 'cactus.test' target. This is needed for the Eclipse plug-in.
Hold on... specifying a task class name as an attribute to
<runservertests> seems very hack-ish. For example, it assumes that the
task can be executed without parameters. Right now, I can't even think
of a single task that doesn't require at least one parameter except
<tstamp>...
Can you please provide more details about what exactly the use case is
in the Eclipse plugin?
There are other ways to support calling tasks directly from
<runservertests>, like:
<runservertests starttarget="x" stoptarget="x">
<test>
<mytask/>
</test>
</runservertests>
Would that work?
BTW my feeling that the Ant integration has started into a "wrong"
direction is getting stronger :-(
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org