jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2.x Ear Plugin
  • MEAR-122

Setting of <contextRoot> in pom.xml is ignored. ArtifactId of a WebModule is set as context-root in the application.xml instead.

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Not A Bug
  • Affects Version/s: None
  • Fix Version/s: 2.4.1
  • Labels:
    None
  • Environment:
    Maven 2.0.10
    Windows XP SP3

Description

I set in my POM the desired context root of a web module which is to be bundled in a EAR file.
The <contextRoot> setting is simply ignored when building the EAR file. Instead the artifactId of the web module is used.

This is the webModule with the ignored contextRoot:
<webModule>
<groupId>ch.hrms.ecase</groupId>
<artifactId>ecase-web</artifactId>
<contextRoot>/ecase</contextRoot>
</webModule>

Following is a larger snippet of the POM:
<profile>
<id>casex-ext</id>
<dependencies>
<dependency>
<groupId>ch.hrms.ecase</groupId>
<artifactId>ecase-ws</artifactId>
<version>${applicationVersion}</version>
<type>wsr</type>
</dependency>
<dependency>
<groupId>ch.hrms.ecase</groupId>
<artifactId>ecase-sunet-ws</artifactId>
<version>${applicationVersion}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>ch.hrms.ecase</groupId>
<artifactId>ecase-pdf</artifactId>
<version>${applicationVersion}</version>
<type>sar</type>
</dependency>
<dependency>
<groupId>ch.hrms.ecase</groupId>
<artifactId>ecase-web</artifactId>
<version>${applicationVersion}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>ch.hrms.ecase</groupId>
<artifactId>rootCtx</artifactId>
<version>${applicationVersion}</version>
<type>war</type>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<displayName>eCaseSwica - external</displayName>
<finalName>ecase-swica-ext</finalName>
<description>
eCase for Swica - deployment for external JBoss server
</description>
<modules>
<wsrModule>
<groupId>ch.hrms.ecase</groupId>
<artifactId>ecase-ws</artifactId>
</wsrModule>
<webModule>
<groupId>ch.hrms.ecase</groupId>
<artifactId>ecase-sunet-ws</artifactId>
<contextRoot>/sunet/ws/casedata</contextRoot>
</webModule>
<sarModule>
<groupId>ch.hrms.ecase</groupId>
<artifactId>ecase-pdf</artifactId>
</sarModule>
<webModule>
<groupId>ch.hrms.ecase</groupId>
<artifactId>ecase-web</artifactId>
<contextRoot>/ecase</contextRoot>
</webModule>
<webModule>
<groupId>ch.hrms.ecase</groupId>
<artifactId>rootCtx</artifactId>
</webModule>
</modules>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jboss-maven-plugin</artifactId>
<version>1.4</version>
<configuration>
<port>8180</port>
<jbossHome>${JBoss_Ext_Home}</jbossHome>
<fileName>ecase-ear/target/ecase-swica-ext.ear</fileName>
</configuration>
</plugin>
</plugins>
</build>
</profile>

  • Options
    • Sort By Name
    • Sort By Date
    • Ascending
    • Descending
    • Download All

Attachments

  1. Hide
    Zip Archive
    ecase.zip
    22/Jan/10 9:39 AM
    41 kB
    Armin Wrobel
    1. XML File
      ecase\ecase-ear\pom.xml 4 kB
    2. XML File
      ecase\ecase-ear\target\application.xml 0.6 kB
    3. File
      ecase\ecase-ear\target\ecase-ear\ecase-sunet-ws.war 3 kB
    4. File
      ecase\ecase-ear\target\ecase-ear\ecase-web.war 5 kB
    5. XML File
      ecase\ecase-ear\target\ecase-ear\META-INF\application.xml 0.6 kB
    6. XML File
      ecase\ecase-ear\target\ecase-ear\META-INF\jboss-app.xml 0.2 kB
    7. File
      ecase\ecase-ear\target\ecase-swica-ext.ear 9 kB
    8. XML File
      ecase\ecase-ear\target\jboss-app.xml 0.2 kB
    9. XML File
      ecase\ecase-sunet-ws\pom.xml 2 kB
    10. File
      ecase\ecase-sunet-ws\src\main\webapp\META-INF\MANIFEST.MF 0.0 kB
    11. XML File
      ecase\ecase-sunet-ws\src\main\webapp\WEB-INF\jboss-web.xml 0.1 kB
    12. XML File
      ecase\ecase-sunet-ws\src\main\webapp\WEB-INF\web.xml 0.9 kB
    13. File
      ecase\ecase-sunet-ws\target\ecase-sunet-ws\META-INF\MANIFEST.MF 0.0 kB
    14. XML File
      ecase\ecase-sunet-ws\target\ecase-sunet-ws\WEB-INF\jboss-web.xml 0.1 kB
    15. XML File
      ecase\ecase-sunet-ws\target\ecase-sunet-ws\WEB-INF\web.xml 0.9 kB
    16. File
      ecase\ecase-sunet-ws\target\ecase-sunet-ws.war 3 kB
    17. XML File
      ecase\ecase-web\pom.xml 2 kB
    18. File
      ecase\ecase-web\src\main\webapp\META-INF\MANIFEST.MF 0.0 kB
    19. XML File
      ecase\ecase-web\src\main\webapp\WEB-INF\jboss-web.xml 0.0 kB
    20. XML File
      ecase\ecase-web\src\main\webapp\WEB-INF\maverick.xml 7 kB
    21. XML File
      ecase\ecase-web\src\main\webapp\WEB-INF\web.xml 5 kB
    22. File
      ecase\ecase-web\target\ecase-web\META-INF\MANIFEST.MF 0.0 kB
    23. XML File
      ecase\ecase-web\target\ecase-web\WEB-INF\jboss-web.xml 0.0 kB
    24. XML File
      ecase\ecase-web\target\ecase-web\WEB-INF\maverick.xml 7 kB
    25. XML File
      ecase\ecase-web\target\ecase-web\WEB-INF\web.xml 5 kB
    26. File
      ecase\ecase-web\target\ecase-web.war 5 kB
    27. XML File
      ecase\pom.xml 7 kB
    Download Zip
    Show
    Zip Archive
    ecase.zip
    22/Jan/10 9:39 AM
    41 kB
    Armin Wrobel
  2. Text File
    output.log
    22/Jan/10 9:39 AM
    112 kB
    Armin Wrobel
  3. XML File
    pom.xml
    22/Jan/10 8:29 AM
    18 kB
    Armin Wrobel
  4. XML File
    pom.xml
    22/Jan/10 8:28 AM
    15 kB
    Armin Wrobel

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Stéphane Nicoll added a comment - 22/Jan/10 1:41 AM

well, you have two of them in your pom and you don't seem to complain about it, right? There are tests that validate this scenario. Can you post a sample project that reproduces the issue? What version of the ear plugin are you using?

Show
Stéphane Nicoll added a comment - 22/Jan/10 1:41 AM well, you have two of them in your pom and you don't seem to complain about it, right? There are tests that validate this scenario. Can you post a sample project that reproduces the issue? What version of the ear plugin are you using?
Hide
Permalink
Armin Wrobel added a comment - 22/Jan/10 8:28 AM

Parent POM

Show
Armin Wrobel added a comment - 22/Jan/10 8:28 AM Parent POM
Hide
Permalink
Armin Wrobel added a comment - 22/Jan/10 8:29 AM

POM of EAR module where I try to set the contextRoot of several web modules.

Show
Armin Wrobel added a comment - 22/Jan/10 8:29 AM POM of EAR module where I try to set the contextRoot of several web modules.
Hide
Permalink
Stéphane Nicoll added a comment - 22/Jan/10 8:31 AM

This is not a sample project. I won't be able to execute it over here

Show
Stéphane Nicoll added a comment - 22/Jan/10 8:31 AM This is not a sample project. I won't be able to execute it over here
Hide
Permalink
Armin Wrobel added a comment - 22/Jan/10 8:33 AM

Stephane, thanks for looking at this issue! Your help is highly appreciated!

I'm using version 2.4 of the maven-ear-plugin.

True, I complained only about the incorrect context of one of the web modules. Unfortunately, the context is set wrongly for all of them. I remember working with this property in earlier (single module) projects, and there it worked correctly. Somehow in a multi module project there can be a certain situation where the contextRoot doesn't work anymore.

Do you have any fix or workaround for this?

Show
Armin Wrobel added a comment - 22/Jan/10 8:33 AM Stephane, thanks for looking at this issue! Your help is highly appreciated! I'm using version 2.4 of the maven-ear-plugin. True, I complained only about the incorrect context of one of the web modules. Unfortunately, the context is set wrongly for all of them. I remember working with this property in earlier (single module) projects, and there it worked correctly. Somehow in a multi module project there can be a certain situation where the contextRoot doesn't work anymore. Do you have any fix or workaround for this?
Hide
Permalink
Stéphane Nicoll added a comment - 22/Jan/10 8:44 AM

can you do mvn clean package -X > output.log on the project and attach the log please?

Show
Stéphane Nicoll added a comment - 22/Jan/10 8:44 AM can you do mvn clean package -X > output.log on the project and attach the log please?
Hide
Permalink
Armin Wrobel added a comment - 22/Jan/10 9:39 AM

The requested debug info trace file and the sample project.

I created a sample project for you, and this output.log has been created using the sample project.

In the sample project I removed everything, but two modules besides the ear module. One is a webservice module and the other the ecase-web module.

As soon as I comment the dependency and module definition of 'ecase-sunet-ws' in the ear pom out, the contextRoot of the 'ecase-web' artifact is set correctly in the application.xml as '/ecase'. Otherwise it's set as '/ecase-web' which is the artifactId.

As I can see in the debug info, only the ecase-sunet-ws contextRoot setting is considered in the case where both modules are configured.

The maven build has to be started like this: mvn clean package -Pcommon-profile,casex-ext

Again, thanks a lot for your help! You're doing a great job!

Armin

Show
Armin Wrobel added a comment - 22/Jan/10 9:39 AM The requested debug info trace file and the sample project. I created a sample project for you, and this output.log has been created using the sample project. In the sample project I removed everything, but two modules besides the ear module. One is a webservice module and the other the ecase-web module. As soon as I comment the dependency and module definition of 'ecase-sunet-ws' in the ear pom out, the contextRoot of the 'ecase-web' artifact is set correctly in the application.xml as '/ecase'. Otherwise it's set as '/ecase-web' which is the artifactId. As I can see in the debug info, only the ecase-sunet-ws contextRoot setting is considered in the case where both modules are configured. The maven build has to be started like this: mvn clean package -Pcommon-profile,casex-ext Again, thanks a lot for your help! You're doing a great job! Armin
Hide
Permalink
Stéphane Nicoll added a comment - 23/Jan/10 5:08 AM

You can't do that! You are overriding the modules section in both profile and since common-profile is first, it takes precendence. There is no merging of attributes in a plugin. Consider the list of modules the same as the description or display name for instance. If you set this value in both profile, you're not expecting a combination of the two values right?

You should pay attention with the way you use profile, I don't think it is very safe and leads to reproductible build. Maybe you need the rethink the way you design your build.

That being said, removing the empty modules in the default profile (?!) does what you expect.

Show
Stéphane Nicoll added a comment - 23/Jan/10 5:08 AM You can't do that! You are overriding the modules section in both profile and since common-profile is first, it takes precendence. There is no merging of attributes in a plugin. Consider the list of modules the same as the description or display name for instance. If you set this value in both profile, you're not expecting a combination of the two values right? You should pay attention with the way you use profile, I don't think it is very safe and leads to reproductible build. Maybe you need the rethink the way you design your build. That being said, removing the empty modules in the default profile (?!) does what you expect.
Hide
Permalink
Tiago Torres added a comment - 15/Jul/10 5:52 PM

Stephane, I have a question. If I understood correctly, I can't declare a maven-ear-plugin section inside a custom profile if I already have this section in the default profile. Does that mean I can never have a web module dependency in a custom profile in case I already have a maven-ear-plugin declared in my default profile? Is there a workaround for this problem?

Thanks,
Tiago

Show
Tiago Torres added a comment - 15/Jul/10 5:52 PM Stephane, I have a question. If I understood correctly, I can't declare a maven-ear-plugin section inside a custom profile if I already have this section in the default profile. Does that mean I can never have a web module dependency in a custom profile in case I already have a maven-ear-plugin declared in my default profile? Is there a workaround for this problem? Thanks, Tiago

People

  • Assignee:
    Stéphane Nicoll
    Reporter:
    Armin Wrobel
Vote (0)
Watch (2)

Dates

  • Created:
    21/Jan/10 10:40 AM
    Updated:
    15/Jul/10 5:52 PM
    Resolved:
    23/Jan/10 5:08 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.