On 26 May 07, at 10:36 PM 26 May 07, John Casey wrote:
I just committed a "fix" to the eclipse plugin which makes it very
wary of plugin configs. If the configuration can render itself to
XML in its toString() method (which IIRC DOMs can do, and I know
Xpp3Doms can), then the eclipse plugin can work with it.
IMO, this is a good change to have regardless of the solution we
find here. The essential nature of plugin configurations is
arbitrary (from the outside looking in, anyway), structured data.
So, it's no real stretch to assume it will be represented by
XML...which is how the POM represents it, after all.
We ultimately need access to the flexible DOM structure but it just
can't be in p-u.
The fix I added makes it0074 succeed. We can create an integration-
test mojo to specifically test class-casts in plugin configurations
if we want to include that in the ITs, but IMO it's much more
important that the eclipse plugin continue to function regardless
of the outcome of this discussion.
-john
On May 26, 2007, at 10:32 PM, Carlos Sanchez wrote:
BTW this is tested in testit0074 which currently fails for 2.1
On 5/26/07, John Casey <[EMAIL PROTECTED]> 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 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. 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.
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?
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
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]
