Maven 2.x Ear Plugin

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.

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.

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?

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.

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

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.

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?

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.

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.

I was able to fix this issue with the following 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 ) )
         {

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 !?

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)

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.

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 );
                 }

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

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

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.

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