You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "John Casey (JIRA)" <ji...@codehaus.org> on 2007/05/31 17:43:58 UTC
[jira] Updated: (MNG-3012) ClassCastException due to plexus-utils
NOT being filtered during plugin loading
[ http://jira.codehaus.org/browse/MNG-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Casey updated MNG-3012:
----------------------------
Description:
The eclipse:eclipse mojo was a perfect example of this. It needs to read the plugin configurations from the POM to look for things like maven-compiler-plugin's source/target values, so it can setup the .classpath appropriately.
When the IdeUtils (line 345) calls execution.getConfiguration(), it assumes the result will be an Xpp3Dom instance, and tries to cast it accordingly. Because Maven now has its own "shaded" or internal copy of plexus-utils that it doesn't share, the eclipse plugin loads the Xpp3Dom class from a different classloader, and the result is a ClassCastException. Admittedly, exposing plugin.getConfiguration() as a java.lang.Object doesn't help plugin developers very much, and that they need to "just know" that it's of type Xpp3Dom (and cast accordingly) has gotten us into some trouble here.
It's important to note that all plugins that deal directly with plugin.getConfiguration() or execution.getConfiguration() will have a problem here, meaning older versions of the eclipse plugin (including all released versions) and many others will immediately suffer if we leave this as-is.
Ideally, plugin.getConfiguration() should just return some object (okay, maybe it's a java.lang.Object, but that's *not* an elegant solution) that contains structured arbitrary data...so, perhaps a good solution would be to make the assumption that the object's toString() method will render it into XML. Working from an assumption like that, one could do the following:
String str = String.valueOf( plugin.getConfiguration() );
Xpp3DomBuilder.build( new StringReader( str ) );
and proceed as if the plugin.getConfiguration() method had returned a type Xpp3Dom, even if we later change it to return something from javax.xml (thinking DOM). This is a more resilient approach than simply casting to Xpp3Dom, and it's the one I've implemented for the eclipse plugin in revId 541953. This is a problem in the current trunk, and any solution will likely take some design time to fix, so I don't want this plugin to become non-functional for developers working with trunk in the meantime (like anyone using m2eclipse).
was:
The eclipse:eclipse mojo was a perfect example of this. It needs to read the plugin configurations from the POM to look for things like maven-compiler-plugin's source/target values, so it can setup the .classpath appropriately.
When the IdeUtils (line 345) calls execution.getConfiguration(), it assumes the result will be an Xpp3Dom instance, and tries to cast it accordingly. Because Maven now has its own "shaded" or internal copy of plexus-utils that it doesn't share, the eclipse plugin loads the Xpp3Dom class from a different classloader, and the result is a ClassCastException. Admittedly, exposing plugin.getConfiguration() as a java.lang.Object doesn't help plugin developers very much, and that they need to "just know" that it's of type Xpp3Dom (and cast accordingly) has gotten us into some trouble here.
It's important to note that all plugins that deal directly with plugin.getConfiguration() or execution.getConfiguration() will have a problem here, meaning older versions of the eclipse plugin (including all released versions) and many others will immediately suffer if we leave this as-is.
Ideally, plugin.getConfiguration() should just return some object (okay, maybe it's a java.lang.Object, but that's *not* an elegant solution) that contains structured arbitrary data...so, perhaps a good solution would be to make the assumption that the object's toString() method will render it into XML. Working from an assumption like that, one could do the following:
String str = String.valueOf( plugin.getConfiguration() );
Xpp3DomBuilder.build( new StringReader( str ) );
and proceed as if the plugin.getConfiguration() method had returned a type Xpp3Dom, even if we later change it to return something from javax.xml (thinking DOM). This is a more resilient approach than simply casting to Xpp3Dom, and it's the one I've implemented for the eclipse plugin in revId 541953. This is a problem in the current trunk, and any solution will likely take some design time to fix, so I don't want this plugin to become non-functional for developers working with trunk in the meantime (like anyone using m2eclipse).
> ClassCastException due to plexus-utils NOT being filtered during plugin loading
> -------------------------------------------------------------------------------
>
> Key: MNG-3012
> URL: http://jira.codehaus.org/browse/MNG-3012
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Affects Versions: 2.1-alpha-1
> Reporter: John Casey
> Priority: Blocker
>
> The eclipse:eclipse mojo was a perfect example of this. It needs to read the plugin configurations from the POM to look for things like maven-compiler-plugin's source/target values, so it can setup the .classpath appropriately.
> When the IdeUtils (line 345) calls execution.getConfiguration(), it assumes the result will be an Xpp3Dom instance, and tries to cast it accordingly. Because Maven now has its own "shaded" or internal copy of plexus-utils that it doesn't share, the eclipse plugin loads the Xpp3Dom class from a different classloader, and the result is a ClassCastException. Admittedly, exposing plugin.getConfiguration() as a java.lang.Object doesn't help plugin developers very much, and that they need to "just know" that it's of type Xpp3Dom (and cast accordingly) has gotten us into some trouble here.
> It's important to note that all plugins that deal directly with plugin.getConfiguration() or execution.getConfiguration() will have a problem here, meaning older versions of the eclipse plugin (including all released versions) and many others will immediately suffer if we leave this as-is.
> Ideally, plugin.getConfiguration() should just return some object (okay, maybe it's a java.lang.Object, but that's *not* an elegant solution) that contains structured arbitrary data...so, perhaps a good solution would be to make the assumption that the object's toString() method will render it into XML. Working from an assumption like that, one could do the following:
> String str = String.valueOf( plugin.getConfiguration() );
> Xpp3DomBuilder.build( new StringReader( str ) );
> and proceed as if the plugin.getConfiguration() method had returned a type Xpp3Dom, even if we later change it to return something from javax.xml (thinking DOM). This is a more resilient approach than simply casting to Xpp3Dom, and it's the one I've implemented for the eclipse plugin in revId 541953. This is a problem in the current trunk, and any solution will likely take some design time to fix, so I don't want this plugin to become non-functional for developers working with trunk in the meantime (like anyone using m2eclipse).
--
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