You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Simone Gianni (JIRA)" <ji...@apache.org> on 2006/12/04 03:06:20 UTC
[jira] Created: (COCOON-1961) Cocoon deployer plugin given null
pointer cause of maven limitations on subclassing
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/dev@maven.apache.org/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
Re: [jira] Commented: (COCOON-1961) Cocoon deployer plugin given
null pointer cause of maven limitations on subclassing
Posted by Reinhard Poetz <re...@apache.org>.
Simone Gianni wrote:
> Reinhard Poetz (JIRA) wrote:
>> We have to discuss on dev@c.a.o what use cases the deployer plugin has to cover at all.
> Hi Reinhard,
> so, what are the use cases for this plugin?
>
> IMO the issue is still valid, because no matter what it will work on the
> unpacked WAR somehow, if it is still needed.
>
> Right now it extracts some folders from block jars, what should it do
> with the latest refactorings? Is there still a need for this plugin?
If you don't want to use the shielding classloader and .xweb files there is no
need for the plugin.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: [jira] Commented: (COCOON-1961) Cocoon deployer plugin given
null pointer cause of maven limitations on subclassing
Posted by Simone Gianni <si...@apache.org>.
Reinhard Poetz (JIRA) wrote:
> We have to discuss on dev@c.a.o what use cases the deployer plugin has to cover at all.
Hi Reinhard,
so, what are the use cases for this plugin?
IMO the issue is still valid, because no matter what it will work on the
unpacked WAR somehow, if it is still needed.
Right now it extracts some folders from block jars, what should it do
with the latest refactorings? Is there still a need for this plugin?
Simone
[jira] Commented: (COCOON-1961) Cocoon deployer plugin given null
pointer cause of maven limitations on subclassing
Posted by "Reinhard Poetz (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/COCOON-1961?page=comments#action_12455239 ]
Reinhard Poetz commented on COCOON-1961:
----------------------------------------
We have to discuss on dev@c.a.o 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/dev@maven.apache.org/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
[jira] Updated: (COCOON-1961) Cocoon deployer plugin given null
pointer cause of maven limitations on subclassing
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler updated COCOON-1961:
-------------------------------------
Priority: Critical (was: Blocker)
> Cocoon deployer plugin given null pointer cause of maven limitations on subclassing
> -----------------------------------------------------------------------------------
>
> Key: COCOON-1961
> URL: https://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: Critical
>
> 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/dev@maven.apache.org/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: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1961) Cocoon deployer plugin given null
pointer cause of maven limitations on subclassing
Posted by "Simone Gianni (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/COCOON-1961?page=comments#action_12455233 ]
Simone Gianni commented on COCOON-1961:
---------------------------------------
Uops, forgot the NPE stacktrace :
java.lang.NullPointerException
at org.apache.maven.plugin.war.AbstractWarMojo.unpack(AbstractWarMojo.java:704)
at org.apache.maven.plugin.war.AbstractWarMojo.unpackWarToTempDirectory(AbstractWarMojo.java:680)
at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:600)
at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:379)
at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCocoonAppAsWebapp(AbstractDeployMojo.java:182)
at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute(DeployExplodedMojo.java:64)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> 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/dev@maven.apache.org/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
[jira] Commented: (COCOON-1961) Cocoon deployer plugin given null
pointer cause of maven limitations on subclassing
Posted by "Simone Gianni (JIRA)" <ji...@apache.org>.
[ 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/dev@maven.apache.org/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