Maven
  1. Maven
  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
    • Fix Version/s: None
    • 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 -

        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: