[
http://jira.codehaus.org/browse/MEAR-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94424
]
Elliot Metsger commented on MEAR-63:
------------------------------------
So, I'm totally open to other solutions, but here's my use case - assembly of
JSR-168 portlets.
I don't know how familiar you are with JSR-168, or Apache Pluto, the RI of
JSR-168. (http://portals.apache.org/pluto). Portlets are packaged as war
files. But in order for the Pluto portlet container to recognize JSR-168
portlets, the WEB-INF/web.xml of the portlet WAR needs to be munged prior to
deployment in the application container.
A project I'm working on packages up its artifacts as an ear for deployment.
Among the packaged artifacts are JSR-168 portlets, and so the question is when
do those portlets get assembled:
1) assemble the wars before they are put into the ear (e.g. assemble them
before the ear plugin is called)
2) assemble the wars after they are put into the ear (e.g. assemble them after
the ear plugin has been called)
3) assemble the wars as they are being put into the ear (assemble them as the
ear plugin is creating the ear archive)
I thought that option 3 would be the smoothest, so we created an
AssemblingJarArchiver which extends JarArchiver. AssemblingJarArchiver checks
to see if the file being archived is a war. If it is, assemble it, and then
replace the unassembled archive entry with the assembled entry in the archive.
The downside of this approach, other than the Plexus weirdness, is that we
depend on specific behavior of the JarArchiver. In order to replace the
ArchiveEntry, our subclass requires access to the bare files map, and there is
some dirtyness there (if you want I can open a separate issue on this).
Suffice to say that 3 would be the smoothest, but even if you let me provide my
own custom AssemblingJarArchiver, it has dependencies on how the superclass
implementation behaves.
-----------------
Another option, perhaps, is to update the ear plugin to have a ear:exploded
goal, similar to war:exploded
(http://maven.apache.org/plugins/maven-war-plugin/exploded-mojo.html).
We could call ear:exploded, then call our assembler to operate on the exploded
ear package, then call the ear plugin to package it up. I like this idea as
well - should I open a new Jira issue for this?
> Allow subclasses of EarMojo to provide a JarArchiver
> ----------------------------------------------------
>
> Key: MEAR-63
> URL: http://jira.codehaus.org/browse/MEAR-63
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
> Affects Versions: 2.3
> Environment: Maven 2.x Ear Plugin trunk :
> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-ear-plugin r533087
> Reporter: Elliot Metsger
> Assignee: Stephane Nicoll
> Priority: Minor
> Attachments: EarMojo.diff
>
>
> We would like to have the EAR plugin use a custom JarArchiver.
> In Maven 2.0.x, Plexus component lookups for our custom JarArchiver component
> fail randomly (I'm told by one of the Maven developers in the Maven chatroom
> on irc.codehaus.org that this behavior is fixed in Maven 2.1).
> Could the EAR plugin provide a protected method (for extending classes to
> override) which obtains the JarArchiver?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
