Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.5
-
Fix Version/s: 1.6
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
I faced a situation where my ear had a war and a jar inside, and the war had a classpath reference to the jar, but using a pre-defined name (instead of the full versioned name used by maven).
In order to achieve this setup, I would have to either hack the ear using a postGoal script or add a new property to the dependency and then change the plugin. I think the former is more elegant, and it works as this:
1.The new optional property is called ear.bundle.name
2.If the property is not set (in a dependency), the plugin assumes the default behaviour (i.e., includes the dependency as is from the local repo)
3.If the property is set, the depenency is copied to maven.ear.src, using the supplied name.
So, for instance, let say I have dependencies company-root-1.2.3.war and myproject-setup-2.0.1.jar, but the war has the following classpath entry:
Class-path: project-setup.jar
(which makes sense, as the same war is used in many ears and the version for the setup jar would be different in each one)
Then the project.xml for my ear would be:
<dependency>
<groupId>myProject</groupId>
<artifactId>myproject-setup</artifactId>
<version>2.0.1</version>
<type>jar</type>
<properties>
<ear.bundle>true</ear.bundle>
<ear.bundle.name>project-setup.jar</ear.bundle.name>
</properties>
</dependency>
<dependency>
<groupId>myCompany</groupId>
<artifactId>companyroot</artifactId>
<version>1.2.3</version>
<properties>
<ear.bundle>true</ear.bundle>
<ear.appxml.war.context-root>/</ear.appxml.war.context-root>
</properties>
<type>war</type>
</dependency>
If there are no objections (I think this situation is generic enough, it's not a particular need for my projects), I will implement such change.
Fixed on CVS.