cool,thanks

On 5/26/07, John Casey <[EMAIL PROTECTED]> wrote:
See MNG-3012.

-j


On May 26, 2007, at 10:40 PM, Carlos Sanchez wrote:

> 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]
>

---
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]

Reply via email to