[ http://issues.apache.org/jira/browse/COCOON-1961?page=comments#action_12455232 ] Simone Gianni commented on COCOON-1961: ---------------------------------------
I submitted a patch for http://jira.codehaus.org/browse/MWAR-86 and tested it locally with a plugin that, as the cocoon-deployer, needs to work on an exploded war before it gets compressed. Please vote for http://jira.codehaus.org/browse/MWAR-86, IMO it's vital to have a cocoon-deployer not directly depending on the WarMojo, so more pluggable and without the NPE. > 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
