Maven 2 & 3
  1. Maven 2 & 3
  2. MNG-3269

Different builds for ejb-client optional with parent

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 2.0.7
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      4

      Description

      When trying to package a j2ee project's ejb-client artifact in the ear /lib directory the war plugin's optional attribute is ignored if building from the parent app project. If you build from the parent project you get the ejb-client packaged in the web-inf/lib directory. If you build the ejb, war, and ear independently you get the ejb-client packaged in the ear /lib directory. It seems when run from the parent project the dependency/artifact doesn't have the optional attribute set.

      Perhaps this is b/c the artifact is a project artifact that was attached from the ejb plugin it is not resolved as optional when the dependency is resolved from the war project.

      Attaching Geronimo's mytime sample with modifications to reproduce the behavior.

      1. MWAR114-maven-war-plugin-2.0.2.patch
        4 kB
        Tim Reilly
      2. MWAR114-maven-war-plugin-2.0.2.patch
        4 kB
        Tim Reilly
      3. MWAR114-maven-war-plugin-2.1-alpha-1.patch
        15 kB
        Tim Reilly

        Activity

        Hide
        Tim Reilly added a comment -

        I think the underlying issue is a possible false assumption.
        The WAR plugin assumes that all of it's dependencies will be resolved to artifacts from it's pom. But in a multimodule build, some artifact's such as an attached an attached ejb-client artifact are not resolved from the war's dependency list. It's already attached to the project. Due to this declaring the ejb-client as optional has no effect.

        I will attach the patch we are using as a candidate patch. The patch iterates the dependency list to develop an optional artifacts sub-list. It then iterates the optional artifacts list and ensures the resolved artifacts reflect the optional attribute.

        Show
        Tim Reilly added a comment - I think the underlying issue is a possible false assumption. The WAR plugin assumes that all of it's dependencies will be resolved to artifacts from it's pom. But in a multimodule build, some artifact's such as an attached an attached ejb-client artifact are not resolved from the war's dependency list. It's already attached to the project. Due to this declaring the ejb-client as optional has no effect. I will attach the patch we are using as a candidate patch. The patch iterates the dependency list to develop an optional artifacts sub-list. It then iterates the optional artifacts list and ensures the resolved artifacts reflect the optional attribute.
        Hide
        Tim Reilly added a comment -

        Patch provides solution for version 2.0.2 of plugin.

        Show
        Tim Reilly added a comment - Patch provides solution for version 2.0.2 of plugin.
        Hide
        Tim Reilly added a comment -

        Fixed the the relative path in the previous patch file

        • Index: maven-war-plugin-2.0.2/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
          + Index: src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
        Show
        Tim Reilly added a comment - Fixed the the relative path in the previous patch file Index: maven-war-plugin-2.0.2/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java + Index: src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
        Hide
        Tim Reilly added a comment -

        Candidate patch for 2.1-alpha-1

        Show
        Tim Reilly added a comment - Candidate patch for 2.1-alpha-1
        Hide
        Tim Reilly added a comment -

        Test Steps:

        1) Extract mytime.zip

        2) set JAVA_HOME to jdk 1.5 or higher (the test project uses ejb annotations)

        3) cd into mytime-ejb directory and execute mvn clean install. Build should be successful. mytime-ejb-2.0-SNAPSHOT.jar and mytime-ejb-2.0-SNAPSHOT-client.jar are installed to local repo.

        4) Next, cd to the mytime-war project and run mvn clean install. Build should be successful. mytime-war-2.0-SNAPSHOT.war is installed to local repo.

        5) Next, cd to mytime-ear project and run mvn clean install. Build should be successful and mytime-ear-2.0-SNAPSHOT.ear is installed to local repo.

        6) Validate the following regarding the generated artifacts. Validation point: mytime-war does not contain a WEB-INF/lib directory and does not contain the mytime-ejb-client. This is the correct behavior. Validation point PASSES

        7) Next, cd to the mytime project (the parent and aggregator of the other projects) Run mvn clean install. Note successful builds from each project.

        8) Validate the following regarding the generated artifacts. Validation point: mytime-war does not contain a WEB-INF/lib directory and does not contain the mytime-ejb-client. This is the correct behavior. Validation point FAILS

        Show
        Tim Reilly added a comment - Test Steps: 1) Extract mytime.zip 2) set JAVA_HOME to jdk 1.5 or higher (the test project uses ejb annotations) 3) cd into mytime-ejb directory and execute mvn clean install. Build should be successful. mytime-ejb-2.0-SNAPSHOT.jar and mytime-ejb-2.0-SNAPSHOT-client.jar are installed to local repo. 4) Next, cd to the mytime-war project and run mvn clean install. Build should be successful. mytime-war-2.0-SNAPSHOT.war is installed to local repo. 5) Next, cd to mytime-ear project and run mvn clean install. Build should be successful and mytime-ear-2.0-SNAPSHOT.ear is installed to local repo. 6) Validate the following regarding the generated artifacts. Validation point: mytime-war does not contain a WEB-INF/lib directory and does not contain the mytime-ejb-client. This is the correct behavior. Validation point PASSES 7) Next, cd to the mytime project (the parent and aggregator of the other projects) Run mvn clean install. Note successful builds from each project. 8) Validate the following regarding the generated artifacts. Validation point: mytime-war does not contain a WEB-INF/lib directory and does not contain the mytime-ejb-client. This is the correct behavior. Validation point FAILS
        Hide
        Stéphane Nicoll added a comment -

        Hi Tim,

        Thanks for the extensive info. I'm flagging this one as to be fixed for the next alpha. I think that your patch is a bit weird so I'll investigate how it can be improved.

        Show
        Stéphane Nicoll added a comment - Hi Tim, Thanks for the extensive info. I'm flagging this one as to be fixed for the next alpha. I think that your patch is a bit weird so I'll investigate how it can be improved.
        Hide
        Stéphane Nicoll added a comment -

        Note sure it's a WAR issue. The optional flag is not passed to the war plugin, period. You will have the same kind of issue with the EAR if you put the ejb-client optional

        This is a Maven core issue.

        Show
        Stéphane Nicoll added a comment - Note sure it's a WAR issue. The optional flag is not passed to the war plugin, period. You will have the same kind of issue with the EAR if you put the ejb-client optional This is a Maven core issue.
        Hide
        Stéphane Nicoll added a comment -

        I guess you need this for the manifest? Otherwise can't you put it provided?

        Show
        Stéphane Nicoll added a comment - I guess you need this for the manifest? Otherwise can't you put it provided?
        Hide
        Tim Reilly added a comment -

        Hi Stephane, I agree the real problem is beyond the war plugin (I was hoping for a tactical solution with these patches.)

        I'd like to propose the real issue is that Artifact should not have Dependency attributes as part of the object model. After all, a Dependency is not an Artifact but rather states the need (or not) for an Artifact.
        IMO, an Artifact should not have a scope. An Artifact should not have a versionRange (although available versions is fine), and an Artifact can not be "optional" - it simply is. Dependencies are optional, have version ranges and scope. As you point out, in a mutli-module build which ever project resolves an "in common" dependency first will be the one to say if the artifact is optional, etc.

        I wonder if Jason, Brett, John, et al would agree or not. Even if they did agree it would take many releases to change this.
        I am hoping for now at least the war plugin could look at the project's Dependency list for the Dependency->optional attribute and not "trust" the Artifact->optional attribute.

        SN> You will have the same kind of issue with the EAR if you put the ejb-client optional
        Yes, I think the same issue would exist. But it's not an issue for our scenario, I guess i'd label this as "skinny war with attached ejb-client".

        SN> I guess you need this for the manifest? Otherwise can't you put it provided?
        Yup, pretty much following this advice: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html
        I'll add we really don't want to build our manifests manually. I'd rather continue with forking the war plugin I think.

        Show
        Tim Reilly added a comment - Hi Stephane, I agree the real problem is beyond the war plugin (I was hoping for a tactical solution with these patches.) I'd like to propose the real issue is that Artifact should not have Dependency attributes as part of the object model. After all, a Dependency is not an Artifact but rather states the need (or not) for an Artifact. IMO, an Artifact should not have a scope. An Artifact should not have a versionRange (although available versions is fine), and an Artifact can not be "optional" - it simply is. Dependencies are optional, have version ranges and scope. As you point out, in a mutli-module build which ever project resolves an "in common" dependency first will be the one to say if the artifact is optional, etc. I wonder if Jason, Brett, John, et al would agree or not. Even if they did agree it would take many releases to change this. I am hoping for now at least the war plugin could look at the project's Dependency list for the Dependency->optional attribute and not "trust" the Artifact->optional attribute. SN> You will have the same kind of issue with the EAR if you put the ejb-client optional Yes, I think the same issue would exist. But it's not an issue for our scenario, I guess i'd label this as "skinny war with attached ejb-client". SN> I guess you need this for the manifest? Otherwise can't you put it provided? Yup, pretty much following this advice: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html I'll add we really don't want to build our manifests manually. I'd rather continue with forking the war plugin I think.
        Hide
        Stéphane Nicoll added a comment -

        Are you happy if I provide a way to build the manifest in a more elegant way?

        Declaring the dependency as provided+optional is such as mess ... I was more thinking of a declarative way of doing this in the war plugin itself, a la ArtifactItem of the dependency plugin.

        WDYT?

        Show
        Stéphane Nicoll added a comment - Are you happy if I provide a way to build the manifest in a more elegant way? Declaring the dependency as provided+optional is such as mess ... I was more thinking of a declarative way of doing this in the war plugin itself, a la ArtifactItem of the dependency plugin. WDYT?
        Hide
        Tim Reilly added a comment -

        I wanted to check with the team I work with about this. They basically said they are not against this, but they would like to know more about how this change would be implemented before 'giving a thumbs up' at least for our team here.

        On a different but potentially related noete: I can say that we ran into a seemly unresolvable issue a few months ago. We build (or at least tried to build) a properties file into the ear's "resource" directory. In the Ant world this worked fine for them, but when we moved to Maven we could not figure out how to get the property file in the ear referenced in the war's manifest class-path (and still use the add classpath feature of the mwar plugin.)

        Let us know what the change might look like and I'll run it by the various team members here to see what they think.

        Thank you

        Show
        Tim Reilly added a comment - I wanted to check with the team I work with about this. They basically said they are not against this, but they would like to know more about how this change would be implemented before 'giving a thumbs up' at least for our team here. On a different but potentially related noete: I can say that we ran into a seemly unresolvable issue a few months ago. We build (or at least tried to build) a properties file into the ear's "resource" directory. In the Ant world this worked fine for them, but when we moved to Maven we could not figure out how to get the property file in the ear referenced in the war's manifest class-path (and still use the add classpath feature of the mwar plugin.) Let us know what the change might look like and I'll run it by the various team members here to see what they think. Thank you
        Show
        Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
        Hide
        Jason van Zyl added a comment -

        Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

        Show
        Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          People

          • Assignee:
            Unassigned
            Reporter:
            Tim Reilly
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: