Refactor Ant integration to use Cargo

• Key: CACTUS-151
• Type: Task
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Petar Tahchiev
• Reporter: Vincent Massol
• Component/s: Ant Integration
• Fix Version/s: 1.8

Description

See http://cargo.codehaus.org

Comments

[Vincent Massol]

Hi Ricardo,

We are planning to migrate the Ant integration to use Cargo which supports Tomcat 5.x. Right now you could probably replace calling the <cactus> task by calling the Cargo Ant task for Tomcat 5.x. See http://cargo.codehaus.org. You can send emails on the cargo mailing list if you have any difficulty.

Thanks

[Felipe Leme]

I'm fine with that - just not sure if I will have time to do that then (as I'm not familiarized with Cargo yet). Anyway, I could at least create the test cases using jelly - they would be independent on how the fix is done.

[Vincent Massol]

Thanks Marcus. We're currently refactoring the Ant integration to use Cargo (http://cargo.codehaus.org) and in the near future all the container logic will be in Cargo. Your patch will not be lost as we'll be able to use it to implement JBoss 4.x support for Cargo. If you wish to participate to cargo please join us on the Cargo mailing list.

Thanks
-Vincent

[Vincent Massol]

WebLogic 8.x support is already implemented in Cargo 0.3.

[Vincent Massol]

Ability to change the JBoss port will be implemented in Cargo once it supports JBoss (very soon now hopefully).

[Vincent Massol]

This has to be addressed in Cargo.

[Vincent Massol]

Sven, you're right, this isn't suported in Cactus. We're now migrating to Cargo (http://cargo.codehaus.org) so this issue will be solved in Cargo land. Thanks.

[Vincent Massol]

Will be done in Cargo land (if someone provides a patch to support WebSphere).

[Vincent Massol]

This is being worked on in Cargo land.

[Nicolas Chalumeau]

Here is the curent state. It is the samples/servlet/src/script/share build.xml.
It work for tomcat5x (it is hard coded). The test are passe but I need to remove
TestSampleFilter.java, TestFilterHttpHeaders.java and TestBasicAuthentication.java from the
test execution. I don't know why they failed but continu to look at this.

Nicolas,

[Vincent Massol]

This feature is already supported by Cargo and once Cactus moves to use it, it'll be available for free :-)

[Felipe Leme]

Ok, I did the Ant changes on CACTUS-204 and once I get Maven working again on my environment I will finish this issue.

[Xuan Thang Nguyen]

Cargo&Cactus integration, first increment.

[Xuan Thang Nguyen]

First patch for CACTUS-151
New tag & update for samples to use cargo

[Felipe Leme]

I tried to apply the patch this morning, but CVS was down for maintenance :-(

[Xuan Thang Nguyen]

Correct patch agaist HEAD
New task for CactusTest and update on samples/servlet/src/scripts/share/build.xml to use cargo with cactus
Previous patch uses incorrect files

[Felipe Leme]

Hi Xuan,

I applied your patches but haven't ananlyzed the changes yet - although I realized you created a new class called CactusTestTask instead of replacing CactusTaks - is there a reason for that?

Also, I'm providing a new patch against the changes I did on the HEAD branch.

-- Felipe

PS: BTW, please use a 'cvs diff -uN' at the root directory next time you need to submit a patch

[Xuan Thang Nguyen]

No modification into common-build.xml is needed.

[Felipe Leme]

Same patch as above, but fixed checkstyle complaints and a problem on macrodef, where the comment:

      <!-- <@j2ee13.begin@mkdir dir="${target.testreports.dir}/jboss3x"/@j2ee13.end@> -->


produced:

      <!-- <!-- mkdir dir="${target.testreports.dir}/jboss3x"/ --> -->

which made the XML invalid (it cannot be nested comments)

[Felipe Leme]

Same patch as above, but fixed checkstyle complaints and a problem on macrodef, where the comment:

      <!-- <@j2ee13.begin@mkdir dir="${target.testreports.dir}/jboss3x"/@j2ee13.end@> -->


produced:

      <!-- <!-- mkdir dir="${target.testreports.dir}/jboss3x"/ --> -->

which made the XML invalid (it cannot be nested comments)

[Felipe Leme]

Sorry, clicked the submit button twice...

[Xuan Thang Nguyen]

Hi Felipe,
I merge your patch and mine into the patch-merge-all.diff against HEAD.
I don't know how to use the -uN option for cvs diff with anonymous account (I cannot cvs add a new file before that) :(. Perhaps you can tell me how to do this. In the patch there no info of the CactusTestTask.java. So maybe you have to help me by adding it into the repo.
Thanks
Xuan

[Felipe Leme]

> I don't know how to use the -uN option for cvs diff with anonymous account (I cannot cvs add a
> new file before that) :(.

That's one of the biggest mysteries of life :-)

> Perhaps you can tell me how to do this.

To be honest, I don't know neither. I mean, I never figured it out how to do using command line, but you can create such a patch using Eclipse.

> In the patch there no info of the CactusTestTask.java. So maybe you have to help me by adding
> it into the repo.

Hmm, it should be. Anyway, I will add it to the HEAD later tonight (I didn't in this morning because I left it running the tests before I left).

-- Felipe

[Felipe Leme]

Xuan,

I've applied your patch to the HEAD branch, so you can continue your work.

I've also reviewed the code and didn't find where the servers are start - I guess you didn't upload that part yet, right? (notice that I'm not complaining, just curious :-)

I also notice that just the servlet samples were changed - of course, it doesn't make sense to add other samples (like ejb and jetty) until they are not ready, but I'm adding this observation here so we don't forget it later on.

Finally, I haven't applied the fix for the cargo.jar.name hack yet (as I didn't receive it in the mailing list).


-- Felipe

PS: congratulations to Vincent for his new baby - ant let's all hope the CVS code will survive while he is out :-)

[Felipe Leme]

> I've also reviewed the code and didn't find where the servers are start

Nevermind - just now I've realized that job is going to be done by another task (one of the "5 steps tasks")...

[Xuan Thang Nguyen]

This patch is for the HEAD branch to fix following issues:
- Error of containerKey for build with cargo version >=5
- Remove the hard-link cargo version in build-common.xml

Thank you Felipe or anyone who will apply the patch

Regards
Xuan

[Xuan Thang Nguyen]

Update for HEAD:
- fix harcoding cargo version
- fix authentication test for servlet to use cargo.servlet.users (not cargo.servlet.security)
- update cactustest tag
- update ejb sample to use cargo

[Xuan Thang Nguyen]

Patch for HEAD
- Moving maven cactus:test-war to use cargo. Still problem with shutdown container

[Xuan Thang Nguyen]

Patch for HEAD branch:
- Allow cactus maven to use cargo. Fix stop container by redeclaring the container.

[Felipe Leme]

Xuan,

Yesterday I applied the 09-08 patch yesterday and got the following error:


/Users/felipeal/cvs/cactus/felipeal/HEAD/samples/ejb/target-13/sample/build.xml:369: org.codehaus.cargo.container.ContainerException: Cannot create configuration. Unknown container id [jboss3x] or unknown hint [standalone]


I guess that's the refid error you mentioned; will try the new patch. BTW, I have already applied the fix to the cargo property, on HEAD and 1.7 branch.

-- Felipe

[Felipe Leme]

Xuan,

I applied your last patch (11_08), but the Maven error still persists:

UILD FAILED
File...... /Users/felipeal/.maven/cache/cactus-maven-1.8dev/plugin.jelly
Element... ant:cargo
Line...... 495
Column.... 76
Cannot create configuration. Unknown container id [jboss3x] or unknown hint [standalone]
Total time: 13 seconds
Finished at: Thu Aug 11 15:48:01 BRT 2005

Did you fix that Jelly issue mentioned on the Cactus/Cargo lists?

Also, I have a newbie Cargo question: for now we would still need to have the containers installed prior to running maven, right? I mean, Cargo should also be able to download the container jars from internet, right? In order words, if I understood it correctly, Cargo would need a higher level of automation, but for now we would just keep the old behaviour, as we are just refactoring Cactus.

-- Felipe

[Xuan Thang Nguyen]

Hi Felipe,
If you have time to check these files again and commit them then you need to add
build.properties into jakarta-cactus/samples/jetty
Jetty4xTestSetup.java into jakarta-cactus/framework/src/java/share-13-14/org/apache/cactus/extension/jetty
Again, I cannot add these from cvs diff :)
Thanks
Xuan

Update for HEAD:
- Update for cactustest Task
- Move org.apache.cactus.extension.jetty.JettyTestSetup to org.apache.cactus.extension.jetty.Jetty4xTestSetup and refactor related classes

[Xuan Thang Nguyen]

Latest update agaist HEAD.

[Xuan Thang Nguyen]

I forgot to attach the above two files in previous patch
jakarta-cactus/integration/ant/src/test/org/apache/cactus/integration/ant/TestCactusTestTask.java
akarta-cactus/integration/ant/src/test-input/org/apache/cactus/integration/ant/test-cactustest.xml

Thanks
Xuan

[Vincent Massol]

Once we move to Cargo this will be supported OOB as Cargo already supports Tomcat 5.x and 5.5.x

[Felipe Leme]

I took some time to play with Cactus SVN code and realized we could get rid of the CACTUS_17_CARGO_BRANCH. Let me explain why..

First, I ran a command on the branch to check when it was created:

[[e-mail]]/Users/felipeal/cvs/cactus/CACTUS_17_CARGO_BRANCH: svn log -v --stop-on-copy
^Csubversion/libsvn_ra_dav/util.c:780: (apr_err=175002)
svn: PROPFIND request failed on '/repos/asf/jakarta/cactus/branches/CACTUS_17_CARGO_BRANCH'
subversion/libsvn_ra_dav/util.c:295: (apr_err=175002)
svn: PROPFIND of '/repos/asf/jakarta/cactus/branches/CACTUS_17_CARGO_BRANCH': SSL negotiation failed: SSL error: (null) (https://svn.apache.org)
[[e-mail]]/Users/felipeal/cvs/cactus/CACTUS_17_CARGO_BRANCH: svn log -v --stop-on-copy project.xml
------------------------------------------------------------------------
r239068 | (no author) | 2004-11-04 23:21:48 -0200 (Thu, 04 Nov 2004) | 2 lines
Changed paths:
   A /jakarta/cactus/branches/CACTUS_17_CARGO_BRANCH (from /jakarta/cactus/trunk:239067)

This commit was manufactured by cvs2svn to create branch
'CACTUS_17_CARGO_BRANCH'.
------------------------------------------------------------------------

So, the branch was created in 2004, on CVS, and imported on revision 239068.

Next, I tried to merge what has changed on the trunk:

[[e-mail]]/Users/felipeal/cvs/cactus/merged_trunk: svn merge -r 239068:HEAD https://svn.apache.org/repos/asf/jakarta/cactus/branches/CACTUS_17_CARGO_BRANCH
U build.xml
C samples/servlet/src/scripts/share/build.xml
C samples/servlet/build.xml
U download.xml
U dependencies.xml.default
U build.properties.vmassol
U build.properties.default

The merge was ok with 6 files (U) but produced 2 conflicts (2). Let's see what have changed:

[[e-mail]]/Users/felipeal/cvs/cactus/merged_trunk: svn st
? samples/servlet/build.xml.merge-left.r239068
? samples/servlet/build.xml.merge-right.r369165
? samples/servlet/build.xml.working
? samples/servlet/src/scripts/share/build.xml.merge-left.r239068
? samples/servlet/src/scripts/share/build.xml.merge-right.r369165
? samples/servlet/src/scripts/share/build.xml.working
C samples/servlet/src/scripts/share/build.xml
C samples/servlet/build.xml
M dependencies.xml.default
M build.properties.vmassol

Let's see the easy part first, the (M)odified files:

[[e-mail]]/Users/felipeal/cvs/cactus/merged_trunk: svn diff build.properties.vmassol dependencies.xml.default
Index: build.properties.vmassol
===================================================================
--- build.properties.vmassol (revision 367110)
+++ build.properties.vmassol (working copy)
@@ -186,6 +186,9 @@
 jsp.12.jar = ${servlet.23.jar}
 jsp.20.jar = ${lib.repo}/${jsp.20.project}/jars/${jsp.20.artifact}-${jsp.20.version}.jar
 
+# The location of the Cargo jar
+cargo.jar = ${lib.repo}/${cargo.project}/jars/${cargo.artifact}-${cargo.version}.jar
+
 # The location of the Commons Logging jar
 commons.logging.jar = ${lib.repo}/${commons.logging.project}/jars/${commons.logging.artifact}-${commons.logging.version}.jar
 
Index: dependencies.xml.default
===================================================================
--- dependencies.xml.default (revision 369123)
+++ dependencies.xml.default (working copy)
@@ -11,6 +11,8 @@
       artifact="aspectjtools" version="1.2.1"/>
   <cargo project="cargo"
       artifact="cargo" version="0.6"/>
+ <cargo project="cargo"
+ artifact="cargo" version="0.4-SNAPSHOT"/>
   <checkstyle project="checkstyle"
       artifact="checkstyle" version="3.4"/>
   <clover project="clover"

So, dependencies.xml.defaul can be reverted (as the branch) is using a more recent version and build.properties.vmassol can be merged.

Next, it was time to analyze the (C)onflcted files on samples/servlet. For the build.xml, most of the conflicts were caused by the location on cargo.jar on both files. After reverting the branch's version and switching a couple of lines, I got a clean merge:

[[e-mail]]/Users/felipeal/cvs/cactus/merged_trunk/samples/servlet: svn merge -r 239068:HEAD https://svn.apache.org/repos/asf/jakarta/cactus/branches/CACTUS_17_CARGO_BRANCH/samples/servlet/build.xml
G build.xml

For the src/scripts/share/build.xml, the changes were tougher, as the syntax of some Cargo tasks apparently changes. So, I manually changed the file and solved most of the conflicts using the trunk's working chunk. Still, a couple of differences remained:

[[e-mail]]/Users/felipeal/cvs/cactus/merged_trunk/samples/servlet: svn diff src/scripts/share/build.xml
Index: src/scripts/share/build.xml
===================================================================
--- src/scripts/share/build.xml (revision 367110)
+++ src/scripts/share/build.xml (working copy)
@@ -104,8 +104,6 @@
       location="../../lib/@cactus.jar.name@"/>
   <property name="cactus.ant.jar"
       location="../../lib/@cactus.ant.jar.name@"/>
- <!-- <property name="cargo.jar"
- location="../../lib/@cargo.jar.name@"/> -->
   <property name="commons.httpclient.jar"
       location="../../lib/@commons.httpclient.jar.name@"/>
   <property name="commons.logging.jar"
@@ -118,7 +116,7 @@
       location="../../lib/@junit.jar.name@"/>
   <property name="nekohtml.jar"
       location="../../lib/@nekohtml.jar.name@"/>
- <property name="cargo.jar"
+ <property name="cargo.jar"
       location="../../lib/@cargo.jar.name@"/>
 
   <!-- This is optional and only needed if you wish to debug and use
@@ -156,6 +154,7 @@
 
     <taskdef resource="cactus.tasks" classpathref="cactus.classpath"/>
     <taskdef resource="cargo.tasks" classpathref="cactus.classpath"/>
+
     <tstamp/>
 
   </target>
@@ -321,8 +320,7 @@
 
   </target>
 
-
-<!-- Start a container -->
+ <!-- Start a container -->
   <macrodef name="start-container">
     <attribute name="containerKey"/>
     <sequential>
@@ -345,7 +343,7 @@
         <!-- Additional jars that will be added to the classpath used to start
              the container -->
         <extraclasspath>
- <!-- pathelement location="${clover.jar}"/ -->
+ <@clover.begin@pathelement location="${clover.jar}"/@clover.end@>
         </extraclasspath>
       </cargo>
     </sequential>
@@ -458,14 +456,14 @@
       description="Run the tests on the defined containers">
 
     <!-- Need to add jboss 3.x once it is supported by Cargo:
- <test-container containerKey="jboss3x"/>-->
+ <@j2ee13.begin@test-container containerKey="jboss3x"/@j2ee13.end@>-->
 
     <test-container containerKey="oc4j9x"/>
     <test-container containerKey="orion1x"/>
     <test-container containerKey="orion2x"/>
     <test-container containerKey="resin2x"/>
     <test-container containerKey="resin3x"/>
- <!-- test-container containerKey="tomcat3x"/ -->
+ <@j2ee12.begin@test-container containerKey="tomcat3x"/@j2ee12.end@>
     <test-container containerKey="tomcat4x"/>
     <test-container containerKey="tomcat5x"/>
     <test-container containerKey="weblogic8x"/>

Anyway, after all changes, I regenerated Cactus 1.8dev and tried to run the servlet samples, but they failed due to a htmlunit issue (see CACTUS-220).

Long story short, I think it's safe to delete the branch:
- as the SVN Book says, you never actually delete anything from the repository, you just remove it from the HEAD
- if we keep the branch, people could accidentaly check code against it.

So, here are the revisions affected on the process:

trunk and branches before changes: 369227
after applying changes on trunk: 369230
before removing the branch: 369231 (the ids are global, so someone at ASF committed something else in between)
after removing the branch: 369232

-- Felipe
 

[Petar Tahchiev]

Already implemented in the svn HEAD. I am closing this issue.