40 Jahre DZBW

Herzlichen Dank unseren Kunden und Partnern. Wir freuen uns auf die gemeinsame Fortsetzung der konstruktiven, vertrauensvollen Zusammenarbeit.

Ihre Datenzentrale Baden-W

Hi,

Hi all,

 

i’m trying to merge 2 wars with cargo-maven2-plugin 1.2.0.

Merging context-params works as expected, but for filter-mappings, mime-mappings, servlet-mappings and security-constraints there are duplicate entries in the resulting web.xml.

 

Each of the source web.xml contains an entry

 

  <mime-mapping>

    <extension>js</extension>

    <mime-type>application/x-javascript</mime-type>

  </mime-mapping>

 

And

 

  <filter-mapping>

    <filter-name>Trinidad Filter</filter-name>

    <url-pattern>*.jsf</url-pattern>

  </filter-mapping>

 

In the resulting web.xml there are 2 entries for mime-mapping and filter-mapping.

 

For servlet and filter elements this is not the case.

 

Can anybody give me a hint?

 

Thanks a lot.

 

Markus

40 Jahre DZBW

Herzlichen Dank unseren Kunden und Partnern. Wir freuen uns auf die gemeinsame Fortsetzung der konstruktiven, vertrauensvollen Zusammenarbeit.

Ihre Datenzentrale Baden-Württemberg
_______________________________________________________________________________

Abonnieren Sie unseren Infobrief und erfahren Sie regelmäßig die neuesten Nachrichten über unsere Lösungen, aktuellen Projekte und Entwicklungen. Melden Sie sich an mit diesem Link http://www.datenzentrale.de/Info-Brief

_______________________________________________________________________________

Datenzentrale Baden-Württemberg, Anstalt des öffentlichen Rechts
Krailenshaldenstr. 44, 70469 Stuttgart
Telefon (0711) 8108-20, Telefax (0711) 8108-21350
E-Mail info-ug82gAI2klU@public.gmane.org, Internet www.datenzentrale.de
Vorstand: Karl Tramer (Vors.) und Joachim Kischlat, Vorsitzender des Verwaltungsrats: Gunter Czisch
USt-Id-Nr. DE147794223
_______________________________________________________________________________

• When the CARGO Maven2/Maven3 plugin sees a containerId, say jetty7x, it takes out the end which matches \d+x; i.e. jetty7x becomes jetty. Let's name that part containerArtifact.
  
• It then tries to resolve org.codehaus.cargo:cargo-core-container-<containerArtifact> that matches the plugin's version
• If the resolving is successful, it creates a new ClassLoader with it.
• If resolving fails, it prints out a message: Cannot resolve container artifact xxx for container yyy; but doesn't fail.
  

Hi,

great news!

Could you elaborate CARGO-975? 

What does that mean for external container implementation?

Thanks,

Julien

2012/1/24 S. Ali Tokmen <nospam-E60e9lgXWaDl4B4owWWCMA@public.gmane.org>

Dear CARGO enthusiasts

First of all, happy New Year!

Since the last release of CARGO a bit more than one month and a half ago, we have had the opportunity of fixing some bugs and adding the functionalities:

• CARGO Maven2/Maven3 plugin fixes and improvements:
• ContainerStopMojo now can resolve dependencies with scope <test>, the same way ContainerRunMojo and ContainerStartMojo can (CARGO-1069 and CARGO-527).
• The functional-tests artifact of the Separate Functional Test Module Archetype now uses packaging=jar and is compatible with m2e (CARGO-1065).
• The CARGO plugin now resolves the required container JARs automatically (CARGO-975), meaning that if you're for example only using CARGO with the Jetty container than the other containers' JARs will not be downloaded.
• Fixed a bug where the JSR-88 deployers' (used by the GlassFish remote deployer) undeploy method ignored the EAR's name ( CARGO-1076).
• All CARGO JBoss containers, from the 10-year-old JBoss 3.x to the brand-new JBoss 7.1.x, now support datasources (CARGO-426). You can therefore now use CARGO to deploy datasources to any JBoss container; the bigger advantage being that the datasource definitions don't need to change between JBoss versions nor between all containers that CARGO can deploy datasources to.
• The JOnAS remote deployer now works with Windows for XML deployment plans (CARGO-1067).
• The Resin container has been improved:
• The Resin management port can be configured (CARGO-318)
• Resin 3.1.x support has been added (CARGO-759 and CARGO-494)
• Last but not least, the new XML replacement API introduced in CARGO 1.1.4, which avoids having CARGO-specific container configuration files in the distribution, is now used more extensively; as the Jetty (CARGO-1060), Resin (CARGO-1075) and Tomcat (CARGO-1061) container also make use of it.
• This way, not only we won't have to maintain these CARGO-specific files manually anymore, but also new versions will be supported "out of the box" and CARGO will also work with different flavours of containers.

CARGO 1.2.0 is therefore now ready. Please note that on the API side, this new minor version comes with some behavioural changes and the removal of some elements (which have been deprecated for over 6 months now):

• To achieve automatic resolution of container JARs in the Maven2/Maven3 container, a small change has been done in the ResourceUtils: it now loads resources using a class loader (as opposed to a class, which was the case in the past), hence AbstractLocalConfiguration.RESOURCE_PATH has been changed from "/org/codehaus/cargo/container/internal/resources/" to "org/codehaus/cargo/container/internal/resources/" (without the slash at the beginning). If your code uses the same constant, make sure you update it properly.
• The Deployable.isExpanded* and AbstractCopyingInstalledLocalDeployer.setShouldDeployExpanded*s methods have been removed (CARGO-905 and CARGO-940). As a replacement:
• The Deployable type has a generic isExpanded method.
• AbstractCopyingInstalledLocalDeployer has a generic method setShouldDeployExpanded with two arguments.
• File handling methods that manipulate texts now need to specify the encoding (CARGO-909).
• In the Maven2/Maven3 plugin, the <zipUrlInstaller> and <artifactInstaller> don't have the <installDir> attribute anymore, replaced by <downloadDir> and <extractDir> attributes (CARGO-916).
• TomcatPropertySet.MANAGER_URL (i.e. cargo.tomcat.manager.url) has been removed (CARGO-965), please use the generic RemotePropertySet.URI (i.e. cargo.remote.uri) instead.

You can access the full release notes by visiting https://jira.codehaus.org/secure/ReleaseNote.jspa?version=17088&styleName=Html&projectId=10730

To use this new version:

• Users of the Java API and/or ANT tasks can download the CARGO uberjar and ANT tasks from the download page: http://cargo.codehaus.org/Downloads
• Maven2/Maven3 users simply need to change the plugin's <version> to 1.2.0, and Maven2/Maven3 will download the new version automatically.

Please share your good (and bad) findings on the user-z8XaHfFCYGOxIXFVlbCvtR2eb7JE58TQ@public.gmane.org mailing list.

Enjoy!

-- S. Ali Tokmen http://ali.tokmen.com/ GSM (ch): +41 79 207 29 22 [Swisscom] GSM (fr): +33 7 70 10 33 79 [Virgin Mobile] GSM (tr): +90 555 266 52 73 [Avea] My AIM, ICQ, MSN Messenger and Yahoo IM contact details are on http://contact.ali.tokmen.com

Le mercredi 1 février 2012 à 15:38, S. Ali Tokmen a écrit :

Hi Julien

Here is how it now works:

• When the CARGO Maven2/Maven3 plugin sees a containerId, say jetty7x, it takes out the end which matches \d+x; i.e. jetty7x becomes jetty. Let's name that part containerArtifact.
  
• It then tries to resolve org.codehaus.cargo:cargo-core-container-<containerArtifact> that matches the plugin's version
• If the resolving is successful, it creates a new ClassLoader with it.
• If resolving fails, it prints out a message: Cannot resolve container artifact xxx for container yyy; but doesn't fail.
  

In your case, since the container's JAR is added as a plugin dependency, CARGO's mechanisms will simply not resolve anything and leave things as they are.

Let us know if it works correctly for you as well :)

Thank you

S. Ali Tokmen http://ali.tokmen.com/ GSM (ch): +41 79 207 29 22 [Swisscom] GSM (fr): +33 7 70 10 33 79 [Virgin Mobile] GSM (tr): +90 555 266 52 73 [Avea] My AIM, ICQ, MSN Messenger and Yahoo IM contact details are on http://contact.ali.tokmen.com
On 2012/02/01 16:10, Julien Eluard wrote:

Hi,

great news!

Could you elaborate CARGO-975? 

What does that mean for external container implementation?

Thanks,

Julien

2012/1/24 S. Ali Tokmen <nospam <at> alishomepage.com>

Dear CARGO enthusiasts

First of all, happy New Year!

Since the last release of CARGO a bit more than one month and a half ago, we have had the opportunity of fixing some bugs and adding the functionalities:

• CARGO Maven2/Maven3 plugin fixes and improvements:
• ContainerStopMojo now can resolve dependencies with scope <test>, the same way ContainerRunMojo and ContainerStartMojo can (CARGO-1069 and CARGO-527).
• The functional-tests artifact of the Separate Functional Test Module Archetype now uses packaging=jar and is compatible with m2e (CARGO-1065).
• The CARGO plugin now resolves the required container JARs automatically (CARGO-975), meaning that if you're for example only using CARGO with the Jetty container than the other containers' JARs will not be downloaded.
• Fixed a bug where the JSR-88 deployers' (used by the GlassFish remote deployer) undeploy method ignored the EAR's name ( CARGO-1076).
• All CARGO JBoss containers, from the 10-year-old JBoss 3.x to the brand-new JBoss 7.1.x, now support datasources (CARGO-426). You can therefore now use CARGO to deploy datasources to any JBoss container; the bigger advantage being that the datasource definitions don't need to change between JBoss versions nor between all containers that CARGO can deploy datasources to.
• The JOnAS remote deployer now works with Windows for XML deployment plans (CARGO-1067).
• The Resin container has been improved:
• The Resin management port can be configured (CARGO-318)
• Resin 3.1.x support has been added (CARGO-759 and CARGO-494)
• Last but not least, the new XML replacement API introduced in CARGO 1.1.4, which avoids having CARGO-specific container configuration files in the distribution, is now used more extensively; as the Jetty (CARGO-1060), Resin (CARGO-1075) and Tomcat (CARGO-1061) container also make use of it.
• This way, not only we won't have to maintain these CARGO-specific files manually anymore, but also new versions will be supported "out of the box" and CARGO will also work with different flavours of containers.

CARGO 1.2.0 is therefore now ready. Please note that on the API side, this new minor version comes with some behavioural changes and the removal of some elements (which have been deprecated for over 6 months now):

• To achieve automatic resolution of container JARs in the Maven2/Maven3 container, a small change has been done in the ResourceUtils: it now loads resources using a class loader (as opposed to a class, which was the case in the past), hence AbstractLocalConfiguration.RESOURCE_PATH has been changed from "/org/codehaus/cargo/container/internal/resources/" to "org/codehaus/cargo/container/internal/resources/" (without the slash at the beginning). If your code uses the same constant, make sure you update it properly.
• The Deployable.isExpanded* and AbstractCopyingInstalledLocalDeployer.setShouldDeployExpanded*s methods have been removed (CARGO-905 and CARGO-940). As a replacement:
• The Deployable type has a generic isExpanded method.
• AbstractCopyingInstalledLocalDeployer has a generic method setShouldDeployExpanded with two arguments.
• File handling methods that manipulate texts now need to specify the encoding (CARGO-909).
• In the Maven2/Maven3 plugin, the <zipUrlInstaller> and <artifactInstaller> don't have the <installDir> attribute anymore, replaced by <downloadDir> and <extractDir> attributes (CARGO-916).
• TomcatPropertySet.MANAGER_URL (i.e. cargo.tomcat.manager.url) has been removed (CARGO-965), please use the generic RemotePropertySet.URI (i.e. cargo.remote.uri) instead.

You can access the full release notes by visiting https://jira.codehaus.org/secure/ReleaseNote.jspa?version=17088&styleName=Html&projectId=10730

To use this new version:

• Users of the Java API and/or ANT tasks can download the CARGO uberjar and ANT tasks from the download page: http://cargo.codehaus.org/Downloads
• Maven2/Maven3 users simply need to change the plugin's <version> to 1.2.0, and Maven2/Maven3 will download the new version automatically.

Please share your good (and bad) findings on the user <at> cargo.codehaus.org mailing list.

Enjoy!

-- S. Ali Tokmen http://ali.tokmen.com/ GSM (ch): +41 79 207 29 22 [Swisscom] GSM (fr): +33 7 70 10 33 79 [Virgin Mobile] GSM (tr): +90 555 266 52 73 [Avea] My AIM, ICQ, MSN Messenger and Yahoo IM contact details are on http://contact.ali.tokmen.com

Seems like a neat idea.

Just tested with 1.2.0 and our plugin does work fine.

I do get a weird warning though during execution which seems harmless. I guess this is what you referred to.

Just for the record:

"""

[INFO] --- cargo-maven2-plugin:1.2.0:start (start-container) <at> embedded ---

Downloading: http://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-container-mule/1.2.0/cargo-core-container-mule-1.2.0.jar

[WARNING] [2.ContainerStartMojo] Cannot resolve container artifact org.codehaus.cargo:cargo-core-container-mule:jar:1.2.0 for container mule3x: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Could not find artifact org.codehaus.cargo:cargo-core-container-mule:jar:1.2.0 in central (http://repo1.maven.org/maven2)

Try downloading the file manually from the project website.

Then, install it using the command: 

    mvn install:install-file -DgroupId=org.codehaus.cargo -DartifactId=cargo-core-container-mule -Dversion=1.2.0 -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there: 

    mvn deploy:deploy-file -DgroupId=org.codehaus.cargo -DartifactId=cargo-core-container-mule -Dversion=1.2.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  org.codehaus.cargo:cargo-core-container-mule:jar:1.2.0

from the specified remote repositories:

  central (http://repo1.maven.org/maven2, releases=true, snapshots=false)

"""

Thanks for the good job (as usual)!

Julien

Le mercredi 1 février 2012 à 15:38, S. Ali Tokmen a écrit :

Hi Julien

Here is how it now works:

• When the CARGO Maven2/Maven3 plugin sees a containerId, say jetty7x, it takes out the end which matches \d+x; i.e. jetty7x becomes jetty. Let's name that part containerArtifact.
  
• It then tries to resolve org.codehaus.cargo:cargo-core-container-<containerArtifact> that matches the plugin's version
• If the resolving is successful, it creates a new ClassLoader with it.
• If resolving fails, it prints out a message: Cannot resolve container artifact xxx for container yyy; but doesn't fail.
  

In your case, since the container's JAR is added as a plugin dependency, CARGO's mechanisms will simply not resolve anything and leave things as they are.

Let us know if it works correctly for you as well :)

Thank you

S. Ali Tokmen http://ali.tokmen.com/ GSM (ch): +41 79 207 29 22 [Swisscom] GSM (fr): +33 7 70 10 33 79 [Virgin Mobile] GSM (tr): +90 555 266 52 73 [Avea] My AIM, ICQ, MSN Messenger and Yahoo IM contact details are on http://contact.ali.tokmen.com
On 2012/02/01 16:10, Julien Eluard wrote:

Hi,

great news!

Could you elaborate CARGO-975? 

What does that mean for external container implementation?

Thanks,

Julien

2012/1/24 S. Ali Tokmen <nospam-E60e9lgXWaDl4B4owWWCMA@public.gmane.org>

Dear CARGO enthusiasts

First of all, happy New Year!

Since the last release of CARGO a bit more than one month and a half ago, we have had the opportunity of fixing some bugs and adding the functionalities:

• CARGO Maven2/Maven3 plugin fixes and improvements:
• ContainerStopMojo now can resolve dependencies with scope <test>, the same way ContainerRunMojo and ContainerStartMojo can (CARGO-1069 and CARGO-527).
• The functional-tests artifact of the Separate Functional Test Module Archetype now uses packaging=jar and is compatible with m2e (CARGO-1065).
• The CARGO plugin now resolves the required container JARs automatically (CARGO-975), meaning that if you're for example only using CARGO with the Jetty container than the other containers' JARs will not be downloaded.
• Fixed a bug where the JSR-88 deployers' (used by the GlassFish remote deployer) undeploy method ignored the EAR's name ( CARGO-1076).
• All CARGO JBoss containers, from the 10-year-old JBoss 3.x to the brand-new JBoss 7.1.x, now support datasources (CARGO-426). You can therefore now use CARGO to deploy datasources to any JBoss container; the bigger advantage being that the datasource definitions don't need to change between JBoss versions nor between all containers that CARGO can deploy datasources to.
• The JOnAS remote deployer now works with Windows for XML deployment plans (CARGO-1067).
• The Resin container has been improved:
• The Resin management port can be configured (CARGO-318)
• Resin 3.1.x support has been added (CARGO-759 and CARGO-494)
• Last but not least, the new XML replacement API introduced in CARGO 1.1.4, which avoids having CARGO-specific container configuration files in the distribution, is now used more extensively; as the Jetty (CARGO-1060), Resin (CARGO-1075) and Tomcat (CARGO-1061) container also make use of it.
• This way, not only we won't have to maintain these CARGO-specific files manually anymore, but also new versions will be supported "out of the box" and CARGO will also work with different flavours of containers.

CARGO 1.2.0 is therefore now ready. Please note that on the API side, this new minor version comes with some behavioural changes and the removal of some elements (which have been deprecated for over 6 months now):

• To achieve automatic resolution of container JARs in the Maven2/Maven3 container, a small change has been done in the ResourceUtils: it now loads resources using a class loader (as opposed to a class, which was the case in the past), hence AbstractLocalConfiguration.RESOURCE_PATH has been changed from "/org/codehaus/cargo/container/internal/resources/" to "org/codehaus/cargo/container/internal/resources/" (without the slash at the beginning). If your code uses the same constant, make sure you update it properly.
• The Deployable.isExpanded* and AbstractCopyingInstalledLocalDeployer.setShouldDeployExpanded*s methods have been removed (CARGO-905 and CARGO-940). As a replacement:
• The Deployable type has a generic isExpanded method.
• AbstractCopyingInstalledLocalDeployer has a generic method setShouldDeployExpanded with two arguments.
• File handling methods that manipulate texts now need to specify the encoding (CARGO-909).
• In the Maven2/Maven3 plugin, the <zipUrlInstaller> and <artifactInstaller> don't have the <installDir> attribute anymore, replaced by <downloadDir> and <extractDir> attributes (CARGO-916).
• TomcatPropertySet.MANAGER_URL (i.e. cargo.tomcat.manager.url) has been removed (CARGO-965), please use the generic RemotePropertySet.URI (i.e. cargo.remote.uri) instead.

You can access the full release notes by visiting https://jira.codehaus.org/secure/ReleaseNote.jspa?version=17088&styleName=Html&projectId=10730

To use this new version:

• Users of the Java API and/or ANT tasks can download the CARGO uberjar and ANT tasks from the download page: http://cargo.codehaus.org/Downloads
• Maven2/Maven3 users simply need to change the plugin's <version> to 1.2.0, and Maven2/Maven3 will download the new version automatically.

Please share your good (and bad) findings on the user-z8XaHfFCYGOxIXFVlbCvtR2eb7JE58TQ@public.gmane.org mailing list.

Enjoy!

-- S. Ali Tokmen http://ali.tokmen.com/ GSM (ch): +41 79 207 29 22 [Swisscom] GSM (fr): +33 7 70 10 33 79 [Virgin Mobile] GSM (tr): +90 555 266 52 73 [Avea] My AIM, ICQ, MSN Messenger and Yahoo IM contact details are on http://contact.ali.tokmen.com