[
http://jira.codehaus.org/browse/MNG-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3012.
---------------------------
Resolution: Fixed
added importFrom(..) to new plugin realms, to bring in Xpp3Dom from the version
of plexus-utils used by maven itself. This should prevent ClassCastExceptions
in the plugins when they call plugin.getConfiguration().
I've verified this in the maven-eclipse-plugin by reverting mine and Kenney's
changes to IdeUtils, and re-running.
> 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
> Assignee: 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
