Maven 2.x Ear Plugin

different build results from single module build and from reactor build

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.4
  • Fix Version/s: 2.5
  • Component/s: None
  • Labels:
    None
  • Environment:
    maven 2.2.0
  • Number of attachments :
    2

Description

attached is a sample application as generated by netbeans 6.8 (using archetypes from org.codehaus.mojo.archetypes)
a simple ear+ejb+war multiproject.

when building everything together from the root pom, I get this output:
[ear:ear]
Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] to[samplejavaee6-ejb.jar]
Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] to[samplejavaee6-web.war]

and the war and ejb artifacts are included with names not including version.

However if I later do a mvn clean install on the ear project, I get this output:

[ear:ear]
Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] to[samplejavaee6-ejb-1.0-SNAPSHOT.jar]
Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] to[samplejavaee6-web-1.0-SNAPSHOT.war]

and the war/ejb artifacts get a version in the name.

This sounds like it has to do with the finalname being resolved differently in single module build and in reactor build.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stephane Nicoll added a comment -

Nothing is attached Milos...

Show
Stephane Nicoll added a comment - Nothing is attached Milos...
Hide
Permalink
Milos Kleint added a comment -

here are the projects.

Show
Milos Kleint added a comment - here are the projects.
Hide
Permalink
Milos Kleint added a comment -

I'm not entirely sure this is a ear plugin problem only, could be a general feat that just backfires here. The question is how to protect from it.

Show
Milos Kleint added a comment - I'm not entirely sure this is a ear plugin problem only, could be a general feat that just backfires here. The question is how to protect from it.
Hide
Permalink
Stephane Nicoll added a comment -

That's also what I think. It might be a misuse of core API in the EarMojo itself.

Thanks for the project.

Show
Stephane Nicoll added a comment - That's also what I think. It might be a misuse of core API in the EarMojo itself. Thanks for the project.
Hide
Permalink
Milos Kleint added a comment -

the project is basically what we generate in netbeans when someone wants an ear maven project. It's backed by archetypes at mojo.codehaus.org.

Show
Milos Kleint added a comment - the project is basically what we generate in netbeans when someone wants an ear maven project. It's backed by archetypes at mojo.codehaus.org.
Hide
Permalink
Benjamin Bentmann added a comment -

Quote from javadoc of StandardFileNameMapping:

It returns the name of the file in the local repository.

This does not always hold when calling Artifact.getFile().getName().

During a reactor build, the artifact is resolved from the project's output directory and the filename here is controlled by the finalName of the build section or the config of the packaging plugin. In contrast, the filename in the local/remote repo is entirely controlled by the repo layout (which doesn't consider finalName). Milos' example is using non-default finalName's, thereby making the conceptual difference visible.

The attached patch demos a potential solution by calculating the filename in the plugin itself, based on the artifact coordinates. The code basically mimics the calculation from DefaultRepositoryLayout with the difference of using getBaseVersion() instead of getVersion().

The patch is incomplete. Apart from tests, it doesn't update the other affected FullFileNameMapping.

Show
Benjamin Bentmann added a comment - Quote from javadoc of StandardFileNameMapping:
It returns the name of the file in the local repository.
This does not always hold when calling Artifact.getFile().getName(). During a reactor build, the artifact is resolved from the project's output directory and the filename here is controlled by the finalName of the build section or the config of the packaging plugin. In contrast, the filename in the local/remote repo is entirely controlled by the repo layout (which doesn't consider finalName). Milos' example is using non-default finalName's, thereby making the conceptual difference visible. The attached patch demos a potential solution by calculating the filename in the plugin itself, based on the artifact coordinates. The code basically mimics the calculation from DefaultRepositoryLayout with the difference of using getBaseVersion() instead of getVersion(). The patch is incomplete. Apart from tests, it doesn't update the other affected FullFileNameMapping.
Hide
Permalink
Fred Bricon added a comment -

Hi,

Benjamin's patch is exactly what we need for m2eclipse-wtp (I was about to propose the same kind of stuff).
Currently, due to m2eclipse project resolution behavior (explained here : http://jira.codehaus.org/browse/MWAR-192?focusedCommentId=175406&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_175406), artifact.getFile() returns <workspace_project_path>/target/classes.
That doesn't look good when trying to run mvn package from within eclipse.

As you may know, or not, application.xml in eclipse WTP is currently generated using WTP's API. Since it's a source of countless issues, I've tried delegating to ear:generate-application-xml instead (more or less), but hit the <workspace_project_path>/target/classes bug.

Quick resolution of this issue would help m2eclipse-wtp (at least) to move forward. Let me know if I can do anything to help.

regards,

Fred Bricon

Show
Fred Bricon added a comment - Hi, Benjamin's patch is exactly what we need for m2eclipse-wtp (I was about to propose the same kind of stuff). Currently, due to m2eclipse project resolution behavior (explained here : http://jira.codehaus.org/browse/MWAR-192?focusedCommentId=175406&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_175406), artifact.getFile() returns <workspace_project_path>/target/classes. That doesn't look good when trying to run mvn package from within eclipse. As you may know, or not, application.xml in eclipse WTP is currently generated using WTP's API. Since it's a source of countless issues, I've tried delegating to ear:generate-application-xml instead (more or less), but hit the <workspace_project_path>/target/classes bug. Quick resolution of this issue would help m2eclipse-wtp (at least) to move forward. Let me know if I can do anything to help. regards, Fred Bricon
Hide
Permalink
Stephane Nicoll added a comment -

Fixed. I just deployed a snapshot of 2.4.3 for you to try. Your sample project works fine now.

Show
Stephane Nicoll added a comment - Fixed. I just deployed a snapshot of 2.4.3 for you to try. Your sample project works fine now.

People

Vote (2)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.