Maven Ear Plugin
  1. Maven Ear Plugin
  2. MEAR-85

ejb-client dependencies should be placed in defaultLibBundleDir

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.1
    • Fix Version/s: 2.4.1
    • Labels:
      None

      Description

      ejb-client jars should be placed in the defaultLibBundleDir when specified. They're just standard jar dependencies not J2EE artifacts so should be treated the same as other jars. They're currently being placed in the root directory.

      A workaround is to add an ejbClientModule entry to override the bundleDir:

      <modules>
      <ejbClientModule>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <bundleDir>lib</bundleDir>
      </ejbClientModule>
      </modules>

      1. MEAR-85-ashipilev-TESTS.patch
        17 kB
        Aleksey Shipilev
      2. MEAR-85-ashipilev-v1.patch
        2 kB
        Aleksey Shipilev

        Activity

        Hide
        James Olsen added a comment -

        Another workaround that can help is to declare the dependency with:

        <classifier>client</classifier>

        instead of:

        <type>ejb-client</type>

        Then the ejbClientModule workaround isn't needed.

        Show
        James Olsen added a comment - Another workaround that can help is to declare the dependency with: <classifier>client</classifier> instead of: <type>ejb-client</type> Then the ejbClientModule workaround isn't needed.
        Hide
        Bryan Loofbourrow added a comment - - edited

        The situation I have, simplified, looks like this:

        ear-project DEPENDS ON
        jar-project DEPENDS ON
        ejb-project-1-client DEPENDS ON
        ejb-project-2-client

        In the ear project, jars are supposed to go into APP-INF/lib. I use <defaultLibBundleDir>, and it works for most things, but not ejb-client dependencues. Apparently, the maven-ear-plugin takes any dependency specified with a classifier of ejb-client, and puts it into the root ot the ear, unless you tell it to do otherwise, for a specific artifact. This behavior contrasts with the usual jar-packaging behavior, in that defaultLibBundleDir permits specifying a default location for jars in general.

        As James Olsen says, specifying the jar-project's dependency as client instead of ejb-client evades the maven-ear-plugin's classification of the dependency as an ejb client, and therefore permits it to be packaged where defaultLibBundleDir says it should. That's all very fine for the jar-project DEPENDS ON ejb-project-1 case above. But what about the transitive dependency in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may or may not control that dependency, and to the extent that I do not, what are my options?

        If the only option at that point is to explicitly list all of the ejb-client artifacts on which I transitively depend, in the pom of every ear I build from jars that depend on clients with such transitive dependencies, then I suggest that this issue may be of greater import than its present classification of "Minor/Improvement." Forcing projects to violate the hiding of transitive Maven dependencies seems reasonably serious.

        Also, I've had a look in the maven-ear-plugin code, and it seems very easy to fix, at least if you agree with me about the right way to address it. Given that there's a defaultLibBundleDir for specifying the default location of jar files, and given that someone seems to have found a reason for putting ejb client jars somewhere else regardless of this setting, why not add a defaultEjbClientBundleDir parameter? It looks to me as though the code change would be nearly trivial. There's even already a parameter for passing on a default packaging location, in constructing the object representing the ejb-client. It's just that it's always set to null at present.

        Show
        Bryan Loofbourrow added a comment - - edited The situation I have, simplified, looks like this: ear-project DEPENDS ON jar-project DEPENDS ON ejb-project-1-client DEPENDS ON ejb-project-2-client In the ear project, jars are supposed to go into APP-INF/lib. I use <defaultLibBundleDir>, and it works for most things, but not ejb-client dependencues. Apparently, the maven-ear-plugin takes any dependency specified with a classifier of ejb-client, and puts it into the root ot the ear, unless you tell it to do otherwise, for a specific artifact. This behavior contrasts with the usual jar-packaging behavior, in that defaultLibBundleDir permits specifying a default location for jars in general. As James Olsen says, specifying the jar-project's dependency as client instead of ejb-client evades the maven-ear-plugin's classification of the dependency as an ejb client, and therefore permits it to be packaged where defaultLibBundleDir says it should. That's all very fine for the jar-project DEPENDS ON ejb-project-1 case above. But what about the transitive dependency in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may or may not control that dependency, and to the extent that I do not, what are my options? If the only option at that point is to explicitly list all of the ejb-client artifacts on which I transitively depend, in the pom of every ear I build from jars that depend on clients with such transitive dependencies, then I suggest that this issue may be of greater import than its present classification of "Minor/Improvement." Forcing projects to violate the hiding of transitive Maven dependencies seems reasonably serious. Also, I've had a look in the maven-ear-plugin code, and it seems very easy to fix, at least if you agree with me about the right way to address it. Given that there's a defaultLibBundleDir for specifying the default location of jar files, and given that someone seems to have found a reason for putting ejb client jars somewhere else regardless of this setting, why not add a defaultEjbClientBundleDir parameter? It looks to me as though the code change would be nearly trivial. There's even already a parameter for passing on a default packaging location, in constructing the object representing the ejb-client. It's just that it's always set to null at present.
        Hide
        Stephane Nicoll added a comment -

        ejb-client jars should be placed in the defaultLibBundleDir when specified. They're just standard jar dependencies not J2EE artifacts so should be treated the same as other jars. They're currently being placed in the root directory.

        This is a valid statement for JaveEE5 only. J2EE 1.3 and J2EE 1.4 defines those as special modules that must be declared in the application.xml. I could add a flag to copy ejbClient artifacts in the defaultLibBundleDir.

        Would that help?

        Show
        Stephane Nicoll added a comment - ejb-client jars should be placed in the defaultLibBundleDir when specified. They're just standard jar dependencies not J2EE artifacts so should be treated the same as other jars. They're currently being placed in the root directory. This is a valid statement for JaveEE5 only. J2EE 1.3 and J2EE 1.4 defines those as special modules that must be declared in the application.xml. I could add a flag to copy ejbClient artifacts in the defaultLibBundleDir. Would that help?
        Hide
        Bryan Loofbourrow added a comment -
        I could add a flag to copy ejbClient artifacts in the defaultLibBundleDir.

        I'll take the liberty of replying with respect to my use case, described in my earlier comment, even though your question was addressed to James Olsen.

        As long as the flag applied to all ejbClient artifacts to be packaged in the ear, including the ones pulled in by transitive dependencies, it sounds as though it would fully address the use case that I have. Your proposal of a flag is probably better than mine of a second Dir parameter, given that there is probably no need to ever specify a distinct destination directory for ejbClient artifacts. There's merely a need to piggyback on the destination directory already specified.

        Show
        Bryan Loofbourrow added a comment - I could add a flag to copy ejbClient artifacts in the defaultLibBundleDir. I'll take the liberty of replying with respect to my use case, described in my earlier comment, even though your question was addressed to James Olsen. As long as the flag applied to all ejbClient artifacts to be packaged in the ear, including the ones pulled in by transitive dependencies, it sounds as though it would fully address the use case that I have. Your proposal of a flag is probably better than mine of a second Dir parameter, given that there is probably no need to ever specify a distinct destination directory for ejbClient artifacts. There's merely a need to piggyback on the destination directory already specified.
        Hide
        Stephane Nicoll added a comment -

        Yes it will copy every single ejb-client artifacts there. Any proposal for the name?

        Show
        Stephane Nicoll added a comment - Yes it will copy every single ejb-client artifacts there. Any proposal for the name?
        Hide
        Bryan Loofbourrow added a comment -

        Yeah, it's a little awkward to name, isn't it? I'll put a word in for the "don't fear verbosity if it's the simplest thing you can think of " approach. In other words, I'd just call it "ejbClientsToDefaultLibBundleDir" or similar.

        Show
        Bryan Loofbourrow added a comment - Yeah, it's a little awkward to name, isn't it? I'll put a word in for the "don't fear verbosity if it's the simplest thing you can think of " approach. In other words, I'd just call it "ejbClientsToDefaultLibBundleDir" or similar.
        Hide
        Stephane Nicoll added a comment -

        Another suggestion would be to do this by default if JavaEE5 is configured. I think it's smarter and more transparent for users.

        Watchers, what do you think?

        Show
        Stephane Nicoll added a comment - Another suggestion would be to do this by default if JavaEE5 is configured. I think it's smarter and more transparent for users. Watchers, what do you think?
        Hide
        Corridor Software Developer added a comment -

        How about defaultEjbClientLibDir? Or even add the Bundle as well (a bit of a wasted word, but for consistency).

        In my case the classifier is working fine. But it would be nice if ejb-client was handled without issue. We're up to eleven modules on the same project that require this btw.

        Show
        Corridor Software Developer added a comment - How about defaultEjbClientLibDir? Or even add the Bundle as well (a bit of a wasted word, but for consistency). In my case the classifier is working fine. But it would be nice if ejb-client was handled without issue. We're up to eleven modules on the same project that require this btw.
        Hide
        Bryan Loofbourrow added a comment -

        Stephane, that sounds fine, assuming that the ear plugin has a nice unambiguous way to know that the build is targeting JEE5. The main point for me is that I'm even more eager to see a solution for this now than I was last May. Thanks for taking this up.

        Show
        Bryan Loofbourrow added a comment - Stephane, that sounds fine, assuming that the ear plugin has a nice unambiguous way to know that the build is targeting JEE5. The main point for me is that I'm even more eager to see a solution for this now than I was last May. Thanks for taking this up.
        Hide
        Jeff McClure added a comment - - edited

        I was able to fix this issue with the following patch:

        patch
         
        diff -rupN maven-ear-plugin-2.3.2/src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java maven-ear-plugin-2.3.3-SNAPSHOT/src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java
        --- maven-ear-plugin-2.3.2/src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java	2009-02-22 08:21:05.000000000 -0800
        +++ maven-ear-plugin-2.3.3-SNAPSHOT/src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java	2009-08-16 12:39:46.000000000 -0700
        @@ -85,7 +85,7 @@ public final class EarModuleFactory
                 }
                 else if ( "ejb-client".equals( artifactType ) )
                 {
        -            return new EjbClientModule( artifact, null );
        +            return new EjbClientModule( artifact, defaultLibBundleDir );
                 }
                 else if ( "rar".equals( artifactType ) )
                 {
        
        Show
        Jeff McClure added a comment - - edited I was able to fix this issue with the following patch: patch diff -rupN maven-ear-plugin-2.3.2/src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java maven-ear-plugin-2.3.3-SNAPSHOT/src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java --- maven-ear-plugin-2.3.2/src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java 2009-02-22 08:21:05.000000000 -0800 +++ maven-ear-plugin-2.3.3-SNAPSHOT/src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java 2009-08-16 12:39:46.000000000 -0700 @@ -85,7 +85,7 @@ public final class EarModuleFactory } else if ( "ejb-client" .equals( artifactType ) ) { - return new EjbClientModule( artifact, null ); + return new EjbClientModule( artifact, defaultLibBundleDir ); } else if ( "rar" .equals( artifactType ) ) {
        Hide
        Martin Porter added a comment -

        Is there an estimated date for the release of 2.5 of this plugin ?. It seems rather hard to believe that the app-inf\lib issue has been open for nearly a year and a half without a version of the plugin being released which fixes it !?

        Show
        Martin Porter added a comment - Is there an estimated date for the release of 2.5 of this plugin ?. It seems rather hard to believe that the app-inf\lib issue has been open for nearly a year and a half without a version of the plugin being released which fixes it !?
        Hide
        Stephane Nicoll added a comment -

        Open source, so contributions and good will of contributors is the main factor.

        The patch above is not valid for the reason mentioned in the discussion (J2EE 1.3 and 1.4 behavior vs. Java EE 5/6)

        Show
        Stephane Nicoll added a comment - Open source, so contributions and good will of contributors is the main factor. The patch above is not valid for the reason mentioned in the discussion (J2EE 1.3 and 1.4 behavior vs. Java EE 5/6)
        Hide
        Jeff McClure added a comment -

        I've found the patch to work for Weblogic 9.2 (J2EE 1.3, 1.4) and Weblogic 10.3 (JEE5); I can't speak to other application servers or compliance to the JEE Spec.

        Show
        Jeff McClure added a comment - I've found the patch to work for Weblogic 9.2 (J2EE 1.3, 1.4) and Weblogic 10.3 (JEE5); I can't speak to other application servers or compliance to the JEE Spec.
        Hide
        Aleksey Shipilev added a comment - - edited

        Is this better? I assume this does not break 1.3/1.4 behaviour but fixes 5/6:

        Index: src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java
        ===================================================================
        --- src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java	(revision 896892)
        +++ src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java	(working copy)
        @@ -60,7 +60,7 @@
              * @return an ear module for this artifact
              * @throws UnknownArtifactTypeException if the artifact is not handled
              */
        -    public static EarModule newEarModule( Artifact artifact, String defaultLibBundleDir,
        +    public static EarModule newEarModule( Artifact artifact, String version, String defaultLibBundleDir,
                                                   Boolean includeInApplicationXml )
                 throws UnknownArtifactTypeException
             {
        @@ -85,7 +85,12 @@
                 }
                 else if ( "ejb-client".equals( artifactType ) )
                 {
        -            return new EjbClientModule( artifact, null );
        +            // Somewhat weird way to tackle the problem described in MEAR-85
        +            if (AbstractEarMojo.VERSION_1_3.equals(version) || AbstractEarMojo.VERSION_1_4.equals(version)) {
        +                return new EjbClientModule( artifact, null ); 	
        +            } else {
        +                return new EjbClientModule( artifact, defaultLibBundleDir );
        +            }
                 }
                 else if ( "rar".equals( artifactType ) )
                 {
        Index: src/main/java/org/apache/maven/plugin/ear/AbstractEarMojo.java
        ===================================================================
        --- src/main/java/org/apache/maven/plugin/ear/AbstractEarMojo.java	(revision 896892)
        +++ src/main/java/org/apache/maven/plugin/ear/AbstractEarMojo.java	(working copy)
        @@ -223,7 +223,7 @@
                         if ( !isArtifactRegistered( artifact, allModules ) && !artifact.isOptional() &&
                             filter.include( artifact ) )
                         {
        -                    EarModule module = EarModuleFactory.newEarModule( artifact, defaultLibBundleDir,
        +                    EarModule module = EarModuleFactory.newEarModule( artifact, version, defaultLibBundleDir,
                                                                               includeLibInApplicationXml );
                             allModules.add( module );
                         }
        
        Show
        Aleksey Shipilev added a comment - - edited Is this better? I assume this does not break 1.3/1.4 behaviour but fixes 5/6: Index: src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java =================================================================== --- src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java (revision 896892) +++ src/main/java/org/apache/maven/plugin/ear/EarModuleFactory.java (working copy) @@ -60,7 +60,7 @@ * @ return an ear module for this artifact * @ throws UnknownArtifactTypeException if the artifact is not handled */ - public static EarModule newEarModule( Artifact artifact, String defaultLibBundleDir, + public static EarModule newEarModule( Artifact artifact, String version, String defaultLibBundleDir, Boolean includeInApplicationXml ) throws UnknownArtifactTypeException { @@ -85,7 +85,12 @@ } else if ( "ejb-client" .equals( artifactType ) ) { - return new EjbClientModule( artifact, null ); + // Somewhat weird way to tackle the problem described in MEAR-85 + if (AbstractEarMojo.VERSION_1_3.equals(version) || AbstractEarMojo.VERSION_1_4.equals(version)) { + return new EjbClientModule( artifact, null ); + } else { + return new EjbClientModule( artifact, defaultLibBundleDir ); + } } else if ( "rar" .equals( artifactType ) ) { Index: src/main/java/org/apache/maven/plugin/ear/AbstractEarMojo.java =================================================================== --- src/main/java/org/apache/maven/plugin/ear/AbstractEarMojo.java (revision 896892) +++ src/main/java/org/apache/maven/plugin/ear/AbstractEarMojo.java (working copy) @@ -223,7 +223,7 @@ if ( !isArtifactRegistered( artifact, allModules ) && !artifact.isOptional() && filter.include( artifact ) ) { - EarModule module = EarModuleFactory.newEarModule( artifact, defaultLibBundleDir, + EarModule module = EarModuleFactory.newEarModule( artifact, version, defaultLibBundleDir, includeLibInApplicationXml ); allModules.add( module ); }
        Hide
        Aleksey Shipilev added a comment -

        MEAR-85-ashipilev-TESTS.patch
        Integration tests for this issue.
        Breaks without the patch.

        Show
        Aleksey Shipilev added a comment - MEAR-85 -ashipilev-TESTS.patch Integration tests for this issue. Breaks without the patch.
        Hide
        Aleksey Shipilev added a comment -

        MEAR-85-ashipilev-v1.patch
        Proposed solution, fixes new integration tests.

        Show
        Aleksey Shipilev added a comment - MEAR-85 -ashipilev-v1.patch Proposed solution, fixes new integration tests.
        Hide
        Stephane Nicoll added a comment - - edited

        okay, due to the number of votes and since we seems to have a working solution that fit, I'll review and apply the patches in the upcoming version.

        Show
        Stephane Nicoll added a comment - - edited okay, due to the number of votes and since we seems to have a working solution that fit, I'll review and apply the patches in the upcoming version.
        Hide
        Stephane Nicoll added a comment -

        Patch applied, thanks. A new snapshot of the upcoming 2.4.1 is also available.

        Show
        Stephane Nicoll added a comment - Patch applied, thanks. A new snapshot of the upcoming 2.4.1 is also available.

          People

          • Assignee:
            Stephane Nicoll
            Reporter:
            James Olsen
          • Votes:
            9 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development