[ http://issues.apache.org/jira/browse/COCOON-1961?page=comments#action_12455239 ] Reinhard Poetz commented on COCOON-1961: ----------------------------------------
We have to discuss on [EMAIL PROTECTED] what use cases the deployer plugin has to cover at all. Since the latest refactorings we don't need to extract blocks anymore and we don't need to copy any spring/avalon descriptors around. So what's left? - Patching web.xml (could go into the official plugin) - Integrating the reloading classloader (has already been added as a patch to the war-plugin JIRA project by Carsten) Anything else? (Although I'm the original author of the plugin I would love to see to get rid of it ;-) ). > Cocoon deployer plugin given null pointer cause of maven limitations on > subclassing > ----------------------------------------------------------------------------------- > > Key: COCOON-1961 > URL: http://issues.apache.org/jira/browse/COCOON-1961 > Project: Cocoon > Issue Type: Bug > Components: - Build System: Maven > Affects Versions: 2.2-dev (Current SVN) > Reporter: Simone Gianni > Priority: Blocker > > Currently, trying to build (mvn package for example) a dist, throws a null > pointer exception. Stack trace follows. > The problem is that the property archiverManager of AbstractWarMojo is null. > The problem is simply summarized here : > http://www.mail-archive.com/[email protected]/msg60770.html , a mojo > should not subclass another mojo cause the super one will not be inited by > maven. > In that mail is written "You'll need to redefine that parameter if you want > to use it in the xdoclet [subclass] plugin". Don't know exactly what this > means, cause redefining a private field will not fill the super one and AFAIK > there is no way to define a maven @parameter not associated to a declared > field. > I've opened an issue on maven jira about subdividing the WAR plugin in > separate goals, so that it will be possible to write plugins that operates on > the WAR directory structure, and stack them in the package lifecycle phase in > an order like "war:prepare, cocoon:deploy, what:else, war:package". This is > http://jira.codehaus.org/browse/MWAR-86 . > I will try to modify the war plugin this way, and test it with a mock plugin. > In case someone manages to have it working, then we could rewrite the cocoon > deployer in a way that does not subclass the war mojo, but only operates on > the war directory structure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
