could you add this to jira / release notes before we forget for the
other 3rd party plugins out there?
On 5/26/07, John Casey <[EMAIL PROTECTED]> 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.
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
--
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]
