Maven 2.x Ear Plugin

Generate id for modules in application.xml

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.5
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    3

Description

When the ear plugin generates application.xml, it should generate an "id" with each module. This "id" is according to application.xml schema.

This would help eclipse plugin to generate correct eclipse metedata.

Attachments

  1. Text File
    ear-module-id.patch
    09/Mar/08 11:30 AM
    4 kB
    Matt Jensen
  2. Text File
    MEAR-35-maven-ear-plugin.patch
    14/Dec/06 3:56 AM
    0.8 kB
    Mike Henry
  3. Text File
    MEAR-35-maven-ear-plugin-2.patch
    19/Jun/07 8:19 AM
    1 kB
    Jeroen Leenarts

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stephane Nicoll added a comment -

applicable to which J2EE spec? I don't see this as mandatory so please provide more details / reference / sample.

Show
Stephane Nicoll added a comment - applicable to which J2EE spec? I don't see this as mandatory so please provide more details / reference / sample.
Hide
Permalink
Manikandan Balasubramanian added a comment -

The id is not mandatory, but it would enable eclipse deployment to be much more simpler. And since id is part of http://java.sun.com/xml/ns/j2ee/application_1_4.xsd
it would be a good thing if you generated it.

Show
Manikandan Balasubramanian added a comment - The id is not mandatory, but it would enable eclipse deployment to be much more simpler. And since id is part of http://java.sun.com/xml/ns/j2ee/application_1_4.xsd it would be a good thing if you generated it.
Hide
Permalink
Mike Henry added a comment -

This patch adds the "id" attribute to the "module" element used by some tools (eclipse/wtp).
The id is constructed using the "groupid", "." (a dot), and "artifactid", that easily can be generated in other plugins (such as the eclipse plugin )

Show
Mike Henry added a comment - This patch adds the "id" attribute to the "module" element used by some tools (eclipse/wtp). The id is constructed using the "groupid", "." (a dot), and "artifactid", that easily can be generated in other plugins (such as the eclipse plugin )
Hide
Permalink
Olexandr Zakordonskyy added a comment -

Its requirement for websphere specific deployment descriptors like ibm-ejb-jar-ext.xmi.

Show
Olexandr Zakordonskyy added a comment - Its requirement for websphere specific deployment descriptors like ibm-ejb-jar-ext.xmi.
Hide
Permalink
Peter Triller added a comment - - edited

I am not sure this patch is enough since theoretically I could deploy the same app more than once. with different deployment plans.
so the classifier should be also included in the ID if it is present ..

maybe something like: groupId.artifactId.classifier

Show
Peter Triller added a comment - - edited I am not sure this patch is enough since theoretically I could deploy the same app more than once. with different deployment plans. so the classifier should be also included in the ID if it is present .. maybe something like: groupId.artifactId.classifier
Hide
Permalink
Jeroen Leenarts added a comment -

I've ran into this problem as well.

Here is the use-case I am dealing with.

The module ID's are used by IBM application server 5.1 (and 6.1 for that matter) to wire up all security roles and EJBs. While I won't be doing any security administration myself. I do have to provide unique id's to modules.

Show
Jeroen Leenarts added a comment - I've ran into this problem as well. Here is the use-case I am dealing with. The module ID's are used by IBM application server 5.1 (and 6.1 for that matter) to wire up all security roles and EJBs. While I won't be doing any security administration myself. I do have to provide unique id's to modules.
Hide
Permalink
Jeroen Leenarts added a comment -

The current work-around I am using right now. (we're running an inhouse repository by overriding central)

It's a bit different compared to the earlier patch. With this patch I can use a "moduleId" element within my ejbModule items. I've done this for the ejbModule only because this is just a proof of concept.

Show
Jeroen Leenarts added a comment - The current work-around I am using right now. (we're running an inhouse repository by overriding central) It's a bit different compared to the earlier patch. With this patch I can use a "moduleId" element within my ejbModule items. I've done this for the ejbModule only because this is just a proof of concept.
Hide
Permalink
Matt Jensen added a comment -

The attached patch allows the module ID to be supplied explicitly through a "moduleId" configuration parameter; if none is supplied, "TYPE_groupId.artifactId[-classifier]" is used by default, where TYPE is the artifact type converted to uppercase (such as "WAR") and [-classifier] is included if the artifact has a classifier.

Module ID support has been added to the EJB, JAR, and Web module types only.

Show
Matt Jensen added a comment - The attached patch allows the module ID to be supplied explicitly through a "moduleId" configuration parameter; if none is supplied, "TYPE_groupId.artifactId[-classifier]" is used by default, where TYPE is the artifact type converted to uppercase (such as "WAR") and [-classifier] is included if the artifact has a classifier. Module ID support has been added to the EJB, JAR, and Web module types only.
Hide
Permalink
Barend Garvelink added a comment -

Module ID support has been added to the EJB, JAR, and Web module types only

Thanks for the patch, the configuration parameter is the way to go. I'd like to suggest supporting it on all module types, not just those three. The id attribute is a special case in XML, it's allowed on any element so long as its value is unique in the document. I see no reason to support it on an arbitrary subset of module types. It might come in handy on one of the others.

Show
Barend Garvelink added a comment -
Module ID support has been added to the EJB, JAR, and Web module types only
Thanks for the patch, the configuration parameter is the way to go. I'd like to suggest supporting it on all module types, not just those three. The id attribute is a special case in XML, it's allowed on any element so long as its value is unique in the document. I see no reason to support it on an arbitrary subset of module types. It might come in handy on one of the others.
Hide
Permalink
Julien HENRY added a comment -

I'm new to EAR and WebSphere but it seems I will need an ID on the application tag also. Here is an existing application.xml used by the old Ant build:

<?xml version="1.0" encoding="ISO-8859-15"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application id="Application_ID">
	<display-name>MyApp</display-name>
	<module id="WebModule_1102675755495">
		<web>
			<web-uri>app.war</web-uri>
		<context-root>/app</context-root>
		</web>
	</module>
	<security-role id="SecurityRole_1102689931785">
		<description></description>
		<role-name>appuser</role-name>
	</security-role>
</application>
Show
Julien HENRY added a comment - I'm new to EAR and WebSphere but it seems I will need an ID on the application tag also. Here is an existing application.xml used by the old Ant build: 
<?xml version="1.0" encoding="ISO-8859-15"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application id="Application_ID">
	<display-name>MyApp</display-name>
	<module id="WebModule_1102675755495">
		<web>
			<web-uri>app.war</web-uri>
		<context-root>/app</context-root>
		</web>
	</module>
	<security-role id="SecurityRole_1102689931785">
		<description></description>
		<role-name>appuser</role-name>
	</security-role>
</application>
Hide
Permalink
Stephane Nicoll added a comment -

Well, this took a long time but this request will be available in 2.4.3.

Thanks for the folks who provided a patch. I used the one from Matt Jensen, adding the ability to enable/disable the moduleId generation. I also added documentation and tests.

Show
Stephane Nicoll added a comment - Well, this took a long time but this request will be available in 2.4.3. Thanks for the folks who provided a patch. I used the one from Matt Jensen, adding the ability to enable/disable the moduleId generation. I also added documentation and tests.

People

Vote (10)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.