Maven 1.x Ear Plugin

I have included modified plugin.jelly to illustrate my solution. It's up to you if you accept it or not.

Could I suggest an slightly different alternative? Rather than having to specify which deps to bundle AND include in the XML, instead use a single property (ear.module) to indicate that the dependency is a J2EE module - setting this to true would imply ear.bundle=true also. This means one would use ear.bundle=true for simple jar dependencies, and ear.module=true for those J2EE modules that should be bundled AND have a <module> added to the application.xml.

This patch (against HEAD) implements the alternaive suggestion ie. use 'ear.module' property to imply 'ear.bundle' AND include a <module> for jar dependencies. other dependencies are unchanged.

14 has patches, if they apply ok and seem reasonable, I'll include them. I never use EAR though, so may be it'd be best released separately...

Brett, if you like I can apply this patch.

I'm currently adding a test to the ear project to check the ear.bundle.jar works ok, and can do this at the same time.

The patch applies fine.

if you could apply, test, and release the plugin, that'd be fantastic - thanks.

Applied patch, added tests and documentation

Can we please reopen this issue?
The solution is a bad one.
In a typical ear application. You want to bundle all jars that are included in the application.
If someone wants to deviate from this then the behavior should have been to default ear.module to true and allow someone to set ear.module to false on those that he did not want to bundle.
As is.. this requires ALOT of updating to any project that was relying on the old behavior of the ear plugin. Not only that but simply changing ear.bundle to ear.module will break the jboss-app.xml generation

I don't get it.

The patch wasn't about including the jars in the EAR it was allowing jars to be specified as client applications vs utility jars.

Heres the issue I had:
if i had a jar in my ear.. and multiple subprojects rely on it..
commons-xxx or our own commons.jar for example
and it is not reference by the application.xml
i just get class not founds when trying to use anything from them

So it would seem to me that when Richard suggested that:
"use a single property (ear.module) to indicate that the dependency is a J2EE module - setting this to true would imply ear.bundle=true also."

I would have said that to 1) maintain backwards compatibility and 2) to handle the norm case (which i'll get to below) plugin.properties should have set ear.module=true as a default value.

Now maybe this is only from my experience but imagine these 2 cases.
You build a ear with a war and an ejb jar that both require commons-collections-3.0.jar. By default wouldnt you have wanted this and all other commons-xxx or other jars bundled in your ear to be referenced by application.xml?
On the other hand.. imagine that the war in the ear was out of your control and relied on commons-collections-2.1.jar. Now you have 2 commons-collections jars in your ear and therefore can't reference them in your application.xml.. that's fine.. set <ear.module>false</ear.module> on them and you will have solved the issue of this dependency which (at least in my experience) is the exception NOT the norm.

Michael on the original post said:
"Only few of these jars should be described in application.xml. All other jars are bundled just because they are required libraries and that's a convenient way to create a indepenent EAR which contains all resources needed to properly run the application."

Maybe I'm mis-reading this but this is not true.
A jar that is included in an ear by not referenced by the application.xml or any other submodule specific deployment descriptors will NOT be picked up.

This is all pretty confusing, I'll try to understand

"Heres the issue I had: if i had a jar in my ear.. and multiple subprojects rely on it.. commons-xxx or our own commons.jar for example and it is not reference by the application.xml i just get class not founds when trying to use anything from them "

What do you mean 'had a jar in my ear'. How did it get there? ear.bundle or ear.module? Did you have the jar in the manifest classpath?

"I would have said that to 1) maintain backwards compatibility and 2) to handle the norm case (which i'll get to below) plugin.properties should have set ear.module=true as a default value."

Is this for ear.bundle? If so, what's the point of having two properties?
ear.module means to include in the ear and create an entry in application.xml
ear.bundle means to just include it.
I realise it's not backward compatible. But I thought we discussed that at the time of change.

"You build a ear with a war and an ejb jar that both require commons-collections-3.0.jar. By default wouldnt you have wanted this and all other commons-xxx or other jars bundled in your ear to be referenced by application.xml?"
No. Application.xml only references client modules as java modules. You'd only want those jars to be included in the ear (i.e. ear.bundle, not ear.module).

"On the other hand.. imagine that the war in the ear was out of your control and relied on commons-collections-2.1.jar. Now you have 2 commons-collections jars in your ear and therefore can't reference them in your application.xml.. that's fine.. set <ear.module>false</ear.module> on them and you will have solved the issue of this dependency which (at least in my experience) is the exception NOT the norm."

This doesn't make sense. Setting ear.module to false (and not specifying ear.bundle) means the jar wont be included in the .ear, or be specified as a client module.

"Maybe I'm mis-reading this but this is not true. A jar that is included in an ear by not referenced by the application.xml or any other submodule specific deployment descriptors will NOT be picked up."

What does 'picked up' mean? We routinely include jars in ears and then reference them from the war using the Manifest.mf class path. These jars are bundled, but not a module.

I'm new to maven, but I feel a quite different behavour of the ear plug-in would contribute to the "Intelligent Projects" brand of Maven. I would have expected to only specify dependencies to J2EE modules and that Maven would scan the poms of the dependent modules to find out which dependent jars to include in app xml. For this to happen, the ear module would have to walk the dependents of its own dependents and collect those that are tagged to be included in a manifest classpath. For this to happen, the WAR plug-in would also need to have a dependency-property to tag dpendencies for inclusion in manifest class-path entry. So my wish-solution (for intelligent projects) is bundle of two issues: make ear bundle intelligent and add support for class-path entries in the war plug-in.

So, what's the status of this issue? Should we re-close it (as nobody complained about dion's arguments)?

As there were no comments since my last inquire, I'm marking this bug as closed...