Set WAR deployment file name on remote wildfly server with gradle cargo plugin

[Lucas Skywalker]

Hi there,

we're using cargo to deploy our application to a Wildfly server. It works fine, but we'd like to change the name of the deployment file on Wildfly. Following code generates a file called app/api.war, but we'd like to name it app_core.war. If I got it correctly, cargo picks this name from the context root. Any idea on how to set it via script? I took a look at the container properties to set via "containerProperties", but couldn't find any property to use for this purpose.

Thanks in advance!

cargo {
    containerId = 'wildfly16x'
    port = 9990

    deployable {
        file = file("$project.buildDir/libs/app_core.war")
        context = 'app_core'
    }

    remote {
        hostname = XXXXX
        username = XXXXX
        password = XXXXX
    }
}

[S. Ali Tokmen]

Hi Lucas

As per the documentation on https://github.com/bmuschko/gradle-cargo-plugin I have the impression you should not have to set the file attribute of the deployable.

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

--
You received this message because you are subscribed to the Google Groups "Codehaus Cargo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-carg...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/a760ab74-1d2b-4aeb-a01f-f2361a16055bn%40googlegroups.com.

[Lucas Skywalker]

Hi Ali,

thanks for the quick answer. It doesn't matter if I set the file attribute or not.. the deployment file will always be created as "app/api.war" on wildfly. Any idea on how to set it? Thanks! :)

[S. Ali Tokmen]

Hi Lucas

Thanks for this, and what is the WAR context set to, still is it /app/api, or /api, or the context you specified?

During the preparation of the configuration, you should be seeing messages such as:

Deploying [deployable.getFile()] to [deployableDir]...

What do these messages indicate?

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/fa0b63e6-ca82-469a-9921-764c830103f0n%40googlegroups.com.

[Lucas Skywalker]

Hi Ali,

I'm doing this via GitLab & Jenkins with Gradle. So here's the whole setup:

In my Jenkinsfile:

    stages {
        stage("Build") {
            steps {
                echo 'executing gradle...'
                withGradle {
                    sh './gradlew build -i'
                }
            }
        }
        stage("Code analysis") {
            steps {
                echo 'executing code analysis...'
                sh './gradlew sonarqube'
            }
        }
        stage("Deploy") {
            steps {
                echo 'deploying to Wildfly...'
                sh './gradlew CargoRedeployRemote -i'
            }
        }
    }

In my build.gradle:

plugins {
    id 'java'
    id 'war'
    id "org.sonarqube" version "2.7"
    id "com.bmuschko.cargo" version "2.8.0"
}

war {
    baseName = 'app_core'
    archiveName 'app_core.war'
}

...

dependencies {
    def cargoVersion = '1.8.3'
    cargo "org.codehaus.cargo:cargo-core-uberjar:$cargoVersion",
          "org.codehaus.cargo:cargo-licensed-dtds:$cargoVersion",
          "org.codehaus.cargo:cargo-ant:$cargoVersion"

}

cargo {
    containerId = 'wildfly16x'
    port = 9990

   deployable {

        file = file("$project.buildDir/libs/app_core.war")
        context = 'app_core'
    }

    remote {
        hostname = XXXXX
        username = XXXXX
        password = XXXXX
    }
}

When run it in Jenkins, I get the output below (sorry, I can't attach any file from this PC, that's why I need to paste everything here):

+ ./gradlew build -i
Initialized native services in: /var/jenkins_home/.gradle/native
Initialized jansi services in: /var/jenkins_home/.gradle/native
Removing 0 daemon stop events from registry
Starting a Gradle Daemon (subsequent builds will be faster)
Starting process 'Gradle build daemon'. Working directory: /var/jenkins_home/.gradle/daemon/7.2 Command: /opt/java/openjdk/bin/java -XX:MaxMetaspaceSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xms256m -Xmx512m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /var/jenkins_home/.gradle/wrapper/dists/gradle-7.2-bin/2dnblmf4td7x66yl1d74lt32g/gradle-7.2/lib/gradle-launcher-7.2.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 7.2
Successfully started process 'Gradle build daemon'
An attempt to start the daemon took 1.118 secs.
The client will now receive all logging from the daemon (pid: 363). The daemon log file: /var/jenkins_home/.gradle/daemon/7.2/daemon-363.out.log
Starting build in new daemon [memory: 455.5 MiB]
Closing daemon's stdin at end of input.
The daemon will no longer process any standard input.
Using 2 worker leases.
Watching the file system is configured to be enabled if available
Now considering [/var/jenkins_home/workspace/app_develop] as hierarchies to watch
File system watching is active
Starting Build
Settings evaluated using settings file '/var/jenkins_home/workspace/app_develop/settings.gradle'.
Projects loaded. Root project using build file '/var/jenkins_home/workspace/app_develop/build.gradle'.
Included projects: [root project 'app_core']

> Configure project :
Evaluating root project 'app_core' using build file '/var/jenkins_home/workspace/app_develop/build.gradle'.
All projects evaluated.
Selected primary task 'build' from project :
Starting process 'command '/var/jenkins_home/.gradle/jdks/jdk-11.0.14+9/bin/java''. Working directory: /var/jenkins_home/.gradle/.tmp/tmp-jvm5956286780667259052probe Command: /var/jenkins_home/.gradle/jdks/jdk-11.0.14+9/bin/java -cp . JavaProbe
Successfully started process 'command '/var/jenkins_home/.gradle/jdks/jdk-11.0.14+9/bin/java''
Tasks to be executed: [task ':compileJava', task ':processResources', task ':classes', task ':war', task ':assemble', task ':compileTestJava', task ':processTestResources', task ':testClasses', task ':test', task ':check', task ':build']
Tasks that were excluded: []
:compileJava (Thread[Daemon worker,5,main]) started.

> Task :compileJava UP-TO-DATE
Watching 37 directories to track changes
Watching 46 directories to track changes
Watching 48 directories to track changes
Watching 49 directories to track changes
Watching 50 directories to track changes
Caching disabled for task ':compileJava' because:
  Build cache is disabled
Skipping task ':compileJava' as it is up-to-date.
:compileJava (Thread[Daemon worker,5,main]) completed. Took 1.214 secs.
:processResources (Thread[Daemon worker,5,main]) started.

> Task :processResources UP-TO-DATE
Watching 55 directories to track changes
Watching 60 directories to track changes
Caching disabled for task ':processResources' because:
  Build cache is disabled
Skipping task ':processResources' as it is up-to-date.
:processResources (Thread[Daemon worker,5,main]) completed. Took 0.02 secs.
:classes (Thread[Daemon worker,5,main]) started.

> Task :classes UP-TO-DATE
Skipping task ':classes' as it has no actions.
:classes (Thread[Daemon worker,5,main]) completed. Took 0.0 secs.
:war (Thread[Daemon worker,5,main]) started.

> Task :war UP-TO-DATE
Watching 61 directories to track changes
Watching 64 directories to track changes
Watching 65 directories to track changes
Caching disabled for task ':war' because:
  Build cache is disabled
Skipping task ':war' as it is up-to-date.
:war (Thread[Daemon worker,5,main]) completed. Took 0.142 secs.
:assemble (Thread[Daemon worker,5,main]) started.

> Task :assemble UP-TO-DATE
Skipping task ':assemble' as it has no actions.
:assemble (Thread[Daemon worker,5,main]) completed. Took 0.0 secs.
:compileTestJava (Thread[Daemon worker,5,main]) started.

> Task :compileTestJava UP-TO-DATE
Watching 75 directories to track changes
Watching 76 directories to track changes
Watching 77 directories to track changes
Watching 78 directories to track changes
Watching 89 directories to track changes
Caching disabled for task ':compileTestJava' because:
  Build cache is disabled
Skipping task ':compileTestJava' as it is up-to-date.
:compileTestJava (Thread[Daemon worker,5,main]) completed. Took 0.126 secs.
:processTestResources (Thread[Execution worker for ':',5,main]) started.

> Task :processTestResources NO-SOURCE
file or directory '/var/jenkins_home/workspace/app_develop/src/test/resources', not found
Skipping task ':processTestResources' as it has no source files and no previous output files.
:processTestResources (Thread[Execution worker for ':',5,main]) completed. Took 0.006 secs.
:testClasses (Thread[Execution worker for ':',5,main]) started.

> Task :testClasses UP-TO-DATE
Skipping task ':testClasses' as it has no actions.
:testClasses (Thread[Execution worker for ':',5,main]) completed. Took 0.0 secs.
:test (Thread[Daemon worker,5,main]) started.

> Task :test UP-TO-DATE
Watching 91 directories to track changes
Watching 97 directories to track changes
Watching 98 directories to track changes
Watching 98 directories to track changes
Caching disabled for task ':test' because:
  Build cache is disabled
Skipping task ':test' as it is up-to-date.
:test (Thread[Daemon worker,5,main]) completed. Took 0.083 secs.
:check (Thread[Daemon worker,5,main]) started.

> Task :check UP-TO-DATE
Skipping task ':check' as it has no actions.
:check (Thread[Daemon worker,5,main]) completed. Took 0.0 secs.
:build (Thread[Daemon worker,5,main]) started.

> Task :build UP-TO-DATE
Skipping task ':build' as it has no actions.
:build (Thread[Daemon worker,5,main]) completed. Took 0.0 secs.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 9s
5 actionable tasks: 5 up-to-date
Not watching anything anymore
Watching 0 directories to track changes
Some of the file system contents retained in the virtual file system are on file systems that Gradle doesn't support watching. The relevant state was discarded to ensure changes to these locations are properly detected. You can override this by explicitly enabling file system watching.
Watching 0 directories to track changes
[Pipeline] }
[Pipeline] // withGradle
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Code analysis)
[Pipeline] echo
executing code analysis...
[Pipeline] sh
+ ./gradlew sonarqube
> Task :compileJava UP-TO-DATE
> Task :processResources UP-TO-DATE
> Task :classes UP-TO-DATE
> Task :compileTestJava UP-TO-DATE
> Task :processTestResources NO-SOURCE
> Task :testClasses UP-TO-DATE
> Task :test UP-TO-DATE

> Task :sonarqube
SonarScanner will require Java 11 to run, starting in SonarQube 9.x
Unresolved imports/types have been detected during analysis. Enable DEBUG mode to see them.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 27s
5 actionable tasks: 1 executed, 4 up-to-date
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Deploy)
[Pipeline] echo
deploying to Wildfly...
[Pipeline] sh
+ ./gradlew CargoRedeployRemote -i
Initialized native services in: /var/jenkins_home/.gradle/native
Initialized jansi services in: /var/jenkins_home/.gradle/native
The client will now receive all logging from the daemon (pid: 363). The daemon log file: /var/jenkins_home/.gradle/daemon/7.2/daemon-363.out.log
Starting 3rd build in daemon [uptime: 38.556 secs, performance: 95%, GC rate: 0.27/s, heap usage: 7% of 341.5 MiB, non-heap usage: 38% of 256 MiB]
Using 2 worker leases.
Closing daemon's stdin at end of input.
The daemon will no longer process any standard input.
Now considering [/var/jenkins_home/workspace/app_develop] as hierarchies to watch
Watching the file system is configured to be enabled if available
File system watching is active
Starting Build
Settings evaluated using settings file '/var/jenkins_home/workspace/app_develop/settings.gradle'.
Projects loaded. Root project using build file '/var/jenkins_home/workspace/app_develop/build.gradle'.
Included projects: [root project 'app_core']

> Configure project :
Evaluating root project 'app_core' using build file '/var/jenkins_home/workspace/app_develop/build.gradle'.
All projects evaluated.
Selected primary task 'cargoRedeployRemote' from project :
Tasks to be executed: [task ':cargoRedeployRemote']
Tasks that were excluded: []
:cargoRedeployRemote (Thread[Daemon worker,5,main]) started.

> Task :cargoRedeployRemote
Watching 1 directories to track changes
Caching disabled for task ':cargoRedeployRemote' because:
  Build cache is disabled
Task ':cargoRedeployRemote' is not up-to-date because:
  Task.upToDateWhen is false.
Deployable artifacts = [/var/jenkins_home/workspace/app_develop/build/libs/app_core.war]
Starting action 'redeploy' for remote container 'wildfly16x'
Container properties = [:]
:cargoRedeployRemote (Thread[Daemon worker,5,main]) completed. Took 7.935 secs.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 9s
1 actionable task: 1 executed
Not watching anything anymore
Watching 0 directories to track changes
Some of the file system contents retained in the virtual file system are on file systems that Gradle doesn't support watching. The relevant state was discarded to ensure changes to these locations are properly detected. You can override this by explicitly enabling file system watching.
Watching 0 directories to track changes
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS

[S. Ali Tokmen]

Hi Lucas

Thanks for the details, I then misunderstood what you have been doing: I thought you were using a local deployer, while I see you're using a remote deployer. And, when I cross-check with the Codehaus Cargo code I see the WAR deployable name should be the context, and that's what the deployer shall be using when sending over the file and deploying it.

Are you sure the file $project.buildDir/libs/app_core.war exists? I am suspecting that since that file doesn't exist, the Gradle Cargo container is loading the default WAR file for your Gradle project.

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/fe903cd6-3ab7-4a77-9306-bb17d4323ffan%40googlegroups.com.

[Lucas Skywalker]

Hi Ali,

thanks for the answer. The file does exist in the directory. The jenkins log shows the line below, which points to the fact that the file has been found:

"Deployable artifacts = [/var/jenkins_home/workspace/app_develop/build/libs/app_core.war]"

Also, if the file doesn't exist, the deployment fails with this paremeter:

file = file("$project.buildDir/libs/app_core.war")

I think that Cargo picks this file and deploys it to Wildfly under the name of the context root of my project.

Any other ideas?

Kind regards,

Lucas

[S. Ali Tokmen]

Hi Lucas

Another idea: does your WAR file have a jboss-web.xml file with the context you’re mentioning? Independent of the WAR file name, what you define in the jboss-web.xml file takes precedence for WildFly.

Regards

S. Ali Tokmen

https://ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/959d339d-3040-4deb-80c3-b8a9d7f61ea7n%40googlegroups.com.

[Lucas Skywalker]

Hi Ali,

yes! That's what I meant with "context root". My jboss-web.xml has following line:

<context-root>app/api</context-root>

We can't simply change it to "app_core", since it defines the base URL where the REST services of the application can be reached.

Kind regards,

Lucas

[S. Ali Tokmen]

Hi Lucas

I see, but then I’m confused: what do you want your web application context to be? I don’t understand the problem statement…

S. Ali Tokmen

https://ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/f1c19fee-a4b6-4bf5-9011-f41b1be0385cn%40googlegroups.com.

[S. Ali Tokmen]

Hi Lucas

I think I understand now: do you actually expect that when the JBoss or WildFly WAR file has the context root set in the jboss-web.xml file, then the original WAR file name should be kept when deploying?

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/8DD27381-F041-42CF-B3DD-33D2FBE13B41%40alishomepage.com.

[Lucas Skywalker]

Hi Ali,

yes, that's exactly what I expected. If this is not possible, it's okay. I'll check with my team if we can keep it like that. I just need an official answer that this can't be done.

Thanks!

[S. Ali Tokmen]

Hi Lucas

Getting code changed in line with requirements is important 👍 I hence raised https://codehaus-cargo.atlassian.net/browse/CARGO-1577

May I ask you to try out the 1.9.10-SNAPSHOT version? The instructions for Maven are on https://codehaus-cargo.github.io/cargo/Maven+3+Plugin+Installation.html#Maven3PluginInstallation-snapshots yet I’m unsure how to instruct Grails to get SNAPSHOT dependencies.

Regards

S. Ali Tokmen

https://ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/0366b7f0-2bf9-4716-bf19-fa0c94b7d736n%40googlegroups.com.

[Lucas Skywalker]

Hi Ali,

this is great! I've changed to the cargo version to 1.9.10-SNAPSHOT and now the deployment file gets deployed as app_core.war on Wildfly!

Thank you so much for the help :))

Kind regards,

Lucas

[S. Ali Tokmen]

Hi Lucas

Excellent - Thanks for your rapid feedback!

As this would be a breaking change, I added another property, cargo.jboss.deployer.keepOriginalWarFilename, to control the behaviour.

Would you mind doing another couple tests, with the updated 1.9.10-SNAPSHOT version please?

• When you refresh to the latest 1.9.10-SNAPSHOT version, the WAR file will again have the name based on the context root in the jboss-web.xml file
• Then, as described in https://github.com/bmuschko/gradle-cargo-plugin#container-properties, add the property cargo.jboss.deployer.keepOriginalWarFilename and set it to true
  Once you do that then the WAR file should have the original file name, exactly as you need
  

Once you confirm that this works, if you need the new version to be "official", I'm happy to release it. If not urgent, I can also wait a little - Just in case you hit other bugs or things that would need change 😉

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/2687d06b-9826-413c-80f5-54c864134e34n%40googlegroups.com.

[Lucas Skywalker]

Hi Ali,

the updated version didn't work for me. I added following lines to my build.gradle under remote:

remote {
        containerProperties {
            property 'cargo.jboss.deployer.keepOriginalWarFilename', 'true'
        }

        hostname = XXXX
        username =  XXXX
        password =  XXXX
    }
}

But the file was deployed again as "app/api.war". Here's the jenkins log:

Starting action 'redeploy' for remote container 'wildfly16x' on XXXXXXXXXXXXXX
Container properties = [cargo.jboss.deployer.keepOriginalWarFilename:true]
The WAR file [app_core.war] has a context root set in its jboss-web.xml file, which will override any other context set in the Codehaus Cargo deployable
The undeployment phase of the redeploy action has failed: org.codehaus.cargo.util.CargoException: HTTP request failed, response code: 500, response message: Internal Server Error, response body: {
    "outcome" : "failed",
    "failure-description" : "WFLYCTL0216: Management resource '[(\"deployment\" => \"app/api.war\")]' not found",
    "rolled-back" : true
}
The WAR file [app_core.war] has a context root set in its jboss-web.xml file, which will override any other context set in the Codehaus Cargo deployable
The WAR file [app_core.war] has a context root set in its jboss-web.xml file, which will override any other context set in the Codehaus Cargo deployable
:cargoRedeployRemote (Thread[Daemon worker,5,main]) completed. Took 6.946 secs.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 8s

[S. Ali Tokmen]

Hi Lucas

It seems, I put the if statement the wrong way round - In the version you have, setting the property to anything else than true actually does the job 😕

I checked in https://github.com/codehaus-cargo/cargo/commit/5a54473722f9ad9ac2f44c4731cb2fa1ef54c827 now to correct this, once https://semaphoreci.com/codehaus-cargo/cargo/branches/master/builds/1191 is finished building (probably in about 90 minutes from now) the proper version 1.9.10-SNAPSHOT should be deployed in the repository.

I am looking forward to your observations. That version should fix the issue, moreover it should only be displaying the information messages about the context root once per JBoss WAR (I noticed it was displayed 3 times in your execution).

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/bdcdf7ad-2d4b-421c-9b0b-ee7e2155a729n%40googlegroups.com.

[Lucas Skywalker]

Hello Ali,

I've just tested it and got exactly the same result. I did refresh the dependencies and performed a clean build. No changes. Can you please take a look again?

Thanks

[S. Ali Tokmen]

Hi Lucas

That’s very bizarre - When I read the file https://github.com/bmuschko/gradle-cargo-plugin/blob/master/src/main/groovy/com/bmuschko/gradle/cargo/tasks/AbstractCargoContainerTask.groovy I have the impression that these properties are actually not set. But, I’m no Groovy expert 😕

Do you have the possibility to set the Java environment variable cargo.jboss.deployer.keepOriginalWarFilename to true in the build? If that fixed the issue, then we’ll have to submit a PR to the Gradle plugin.

Regards

S. Ali Tokmen

https://ali.tokmen.com/

On 11 Feb 2022, at 08:41, Lucas Skywalker <lucas...@live.com> wrote:

Hello Ali,

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/6dbbf847-5df3-4cfe-a1a3-5df66496eeddn%40googlegroups.com.

[Lucas Skywalker]

Hi Ali,

I've just tested setting the environment   cargo.jboss.deployer.keepOriginalWarFilename to true before the build and it didn't work as well.

Can you please provide me again that version that worked for me? I'll use it until we find a solution for this.

Thanks!

[S. Ali Tokmen]

Hi Lucas

I've done some more improvements, in particular https://codehaus-cargo.atlassian.net/browse/CARGO-1578 which should allow the Gradle plugin to also work beautifully.

Would you mind having a look again? The CI took loooooong to compile and deploy this time.

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/8d2f4f91-0702-4b77-9432-13872030ac29n%40googlegroups.com.

[Lucas Skywalker]

Hi Ali,

good job! It's working again :) thank you very much!

Regards,

Lucas

[S. Ali Tokmen]

Hi Lucas

Excellent news!

Do you need Codehaus Cargo a 1.9.10 release, or do you prefer to wait until you're sure everything you need is there?

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/7e6cec4e-a58a-4622-afad-792ee84e1813n%40googlegroups.com.

[Lucas Skywalker]

Hi Ali,

you can release it. It's working as I expected :)

Thanks!

[S. Ali Tokmen]

Hi Lucas

Excellent - I released it just now!

Regards

S. Ali Tokmen
https://ali.tokmen.com/
https://contact.ali.tokmen.com/

To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/79df83af-287c-442a-b229-3705434b10c5n%40googlegroups.com.