maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Casey (JIRA)" <j...@codehaus.org>
Subject [jira] Closed: (MNG-3012) ClassCastException due to plexus-utils NOT being filtered during plugin loading
Date Thu, 31 May 2007 17:31:58 GMT

     [ 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

        

Mime
View raw message