On 26 May 07, at 10:17 PM 26 May 07, John Casey wrote:
Hi,
I wanted to bring this up before we go too far down the rabbit hole
WRT "shading" plexus-utils in the new releases of maven (2.1.x).
Right now, there are some mojos (eclipse:eclipse being one of them)
that extract information from
project.build.plugins.plugin.configuration. When these mojos try to
cast that configuration object as an Xpp3Dom (admittedly, this is a
*bad* thing to make them do, but otherwise they're left with a
useless java.lang.Object instance), they come up with a
ClassCastException. The reason is that the Xpp3Dom they're using
isn't loaded from the same place as the one used by maven when the
POM is read.
The Xpp3Dom is used in the core and in plugins, so it is the one
class that should be part of the plugin API but is in p-u which is bad.
The way I see it, we have only a very few options here. We need to
hide the version of plexus-utils used in Maven, so plugins can make
use of new features in subsequent p-u releases.
We can hide everything except Xpp3Dom because it is in our public
API. There is a problem with Xpp3Dom itself because if references
other p-u classes which it shouldn't as a data model. The Xpp3Dom
class in trunk I have removed this need and made a small util class
that operates on Xpp3Dom.
However, without reverting to a javax.xml DOM, we're going to have
a CCE problem when we do this and plugins try to access raw
configuration info. Even if we did go to a DOM implementation for
the configuration, it will still leave plenty of plugins in the lurch.
We have to separate out the DOM element as part of the public API, if
we go back then all plugins are completely bound to the p-u used in
the core which is also not good.
I'm not happy with continuing to filter plexus-utils out of plugin
dependency sets (as 2.0.x does). So, what else can we do to solve
this issue?
Most of p-u is filtered out in 2.0.6 and 2.1.x to allow everything
else to upgrade to newer versions. The problem is not the filtering
per se, it is the Xpp3Dom being in the public plugin API.
The second problem are things relying on the merging methods in
Xpp3Dom. Xpp33Dom requires StringUtils
Plexus utils still needs to be hidden, but they need to be broken up
and put in different packages so that smaller pieces can be used we
need to separate out the Xpp3Dom. We either hide p-u and let people
get the benefits of fixed versions of p-u which benefits far more
people then the few plugins that use Xpp3Dom directly in their
plugins. It's a tradeoff but I think we can work through the Xpp3Dom
problem.
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
