Maven not worth it (yet) for deploying an EAR?

Question

I am transferring several J2EE projects from Ant to Maven2. All of these projects contain 1 EJB and 1 web module and use the recommended skinny EAR packaging method. This means that the JARs that the EJBs and / or web modules depend on are all simply placed at the root of the EAR. Both EJBs and web modules have Class-Path entries in their respective manifests to reference specific JARs, plus the Class-Path web module will also reference the EJB.

I was terrified (is it too strong? :)) to find that Maven doesn't support this very well. I read the official skinny WARs handling page, but that meant I had to duplicate WAR dependencies in the EAR pom and, even worse, also transient dependencies. It seems pointless to accept Maven if you need to manually handle dependencies anywhere!

Then I ran Googling and found a lot of workarounds - obviously, I'm not the first person who (a) wants to make a skinny EAR and (b) doesn't like the Maven approach (which is a workaround in itself).

I tried some of these approaches, but none of them worked for me. I also found some problems similar to Maven errors, for example. WAR plugin directive 'packagingExcludes' excludes direct dependencies only, not transitive ones! Not very confident confidence. I found a JIRA problem for this particular one, but it is still open.

Then I found that my Maven 2.2.1 command line does something different in my built-in mavenlipse Maven (Embedder v. 3.0). Our developers would definitely like to run Maven from Eclipse, so there was no relying on the latest version of the command line.

So my question is: right now and in the foreseeable future, is it worth migrating to Maven if we do everything in Eclipse and work mainly on skinny EAR projects? Is there anything in the future of Maven that would force it to handle EAR in a more robust and integrated way?

Answer 1

So my question is: right now and for the foreseeable future, is it worth migrating to Maven if we are doing all the development in Eclipse and working mainly on skinny EAR projects? Is there anything in the future of Maven that will make it handle EAR in a more robust and integrated way?

Story: No, until M2Eclipse breaks.

Long story:

I would currently recommend against it, at least in Eclipse. When writing the M2Eclipse plugin, there was and always has been a very unpleasant error in which it generates its own version of the application.xml descriptor file, and does not use the one that Maven would otherwise create.

Unfortunately, this specially created application.xml file is completely wrong: it ignores finalNames, has an explicitly hard-coded lib / prefix, and for some reason assigns the EJB JAR extension ".ejb". To make matters worse, you cannot uninstall it to be replaced with a version of Maven, as it continues to be restored using M2Eclipse.

Maven will only generate application.xml if it is not already installed. As the created WTP / M2Eclipse application.xml continues to be restored, Maven application.xml does not get a chance.

However, there is a workaround to solve this problem: you can tell Maven to ignore application.xml during packaging so that it considers that application.xml does not exist, in which case it will still generate its own version. Thus, the incorrectly generated application.xml file does not matter. For future reference:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ear-plugin</artifactId> <version>2.3.2</version> <configuration> <version>5</version> <earSourceExcludes>**/application.xml</earSourceExcludes> <generateApplicationXml>true</generateApplicationXml> </configuration> </plugin> 

One of the main problems is that the Ant script used to deploy to GlassFish in Eclipse generates its own separate EAR for deployment and uses the application.xml created by M2Eclipse for this. This means that the created EARs will always fail if the M2Eclipse plugin remains broken. There are error messages for this in the JIRA code; they cannot get access to them right now.

YMMV for other application servers, but get ready for a tough game with application.xml.

Answer 2

Unfortunately, this specially created application.xml file is completely wrong: it ignores finalNames, has an explicitly hard-coded lib / prefix, and for some reason assigns the EJB JAR extension ".ejb". To make matters worse, you cannot uninstall it to be replaced with a version of Maven, as it continues to be restored using M2Eclipse.

Are you really sure you will? I am using JBoss Tools 3.1, which includes m2eclipse integration and gets exactly the problem you are reporting. However, I see no reason for m2eclipse not to care about the original application.xml at all.

My suspicion is that JBoss Tools embeds information in application.xml. Please prove that I'm wrong, I would stop using m2eclipse forever, and it changed everything that wasn’t / purpose.

// gg

Answer 3

I was terrified (is it too strong? :)) to find that Maven does not support it very well (...)

Indeed, Maven does not support skinny WARs (see also Solving the Skinny Wars problem ), very well, because it was just not planned from the very beginning, and Maven accepts live WARs. So the way to create skinny WARS and skinny EAR is really more workarounds built on top of existing plugins. And, yes, this is a tendency to make mistakes.

(...) Then I found that my Maven 2.2.1 command line does something different with my built-in Maven (Embedder v. 3.0) in m2eclipse.

Note that you can configure m2eclipse to use external Maven instead of the built-in Maven. This is actually what I am doing, I want the exact same version that the CI engine uses.

So my question is: right now and in the foreseeable future, is it worth migrating to Maven if we do everything in Eclipse and work mainly on skinny EAR projects?

My advice is simple: if Maven does not support the way to create software (legal or not, this is not a question), do not use it.