Attached is a plugin.jelly with the changes included in the correct places

It'd be better if this was a patch.

Also,

• documentation for the new properties and how they're used
• updated test case to check the new properties are being processed correctly

would really help

Changes to plugin.jelly as a patch

Charles,

Your patch seems to be fine, but as dIon commented, we need the documentation and test cases too (if you don't provide these, we need to create them by ourselves, which in turns delays fixing this issue).

The documentation is pretty easy: you just need to udpate the xdocs/properties.xml file (you can also change project.xml to add yourself as contributor and xdocs/changes.xml with this issue, if you prefer). The testcase is a little bit trickier, so here is a sample script:

1.Create the directory src/plugin-tests/test06. I will refer to this directory as the testcase directory
2.Add a new project.properties on the new directory contain the common properties for all testcases (in this case, I would say maven.ear.appxml.generate=true)
3.Copy the project.xml from another testcase (for instance, test05) and change the proper settings (testcase description, your info, etc...)
4.Then you need to create the maven.xml with the testcase. In this case, I would suggest 4 testcases, 2 for each new propertie: 1 for the case where the property is set; 1 for the case where it is not. A good example on how to create multiple tests in just one maven.xml is the testcase for the hibernate plugin
5.Regarding the tests themself, they consist of generating the EAR, extracting the application.xml and verifying that the expected elements are there (using XPath).

If you have any more doubts, please let us know (through this issue).

– Felipe

PS: please provide a new patch with everything then

We have solved this differently in our project:

We develop our application in WSAD for deployment on WAS, using J2EE security (hence security roles in application.xml). I think the connection between the standard application.xml and the WAS' vendor specific .xmi files are rather tight, so only generating the security roles might not work (because of numeric id reference between the files, generated in IDE).

Our solution is that we override the standard goal in EAR plugin that generates application.xml and copy security roles from the original application.xml file (if it exist and contains security roles of course).

I'll be glad to submit a patch if you're interessted.

Morten,
I've got the same problem with the binding between the WSAD application.xml extentions and the application.xml generated by Maven.
Could you submit your patch? Maybee I an use it to solve my problem.
I think the securoty roles should be configurable for the ear plugin. Something like:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<security>
<security-role id="SecurityRole_1131964323008">
<description></description>
<role-name>manager</role-name>
</security-role>
<security-role id="SecurityRole_1131964323018">
<description></description>
<role-name>teller</role-name>
</security-role>
</security>
</configuration>
</plugin>

Thanks.

Martijn de Bruijn

Martijn,

This project is for the maven 1 EAR plugin, not maven2. Please file an issue in the MNG project (maven-ear-plugin component).

Thanks.

Patch from Olivier Mallassi (omallassi AT octo DOT com) and André Nedelcoux (anedelcoux AT octo DOT com).
It contains the new feature, with a test and the documentation.

Applied. Thx.