Maven
  1. Maven
  2. MNG-3012

ClassCastException due to plexus-utils NOT being filtered during plugin loading

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.0-alpha-1
    • Fix Version/s: 3.0-alpha-1
    • Component/s: Plugins and Lifecycle
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      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).

        Activity

        Hide
        John Casey added a comment -

        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.

        Show
        John Casey added a comment - 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.

          People

          • Assignee:
            John Casey
            Reporter:
            John Casey
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: