I didnt quite understand this. depMngmt in plugins you use is ignored, so how could you override a plugin dependency using this bug?
other than that what's the overall consensus on fixing this for 2.0.9 ? I vote for fixing it On Tue, Feb 19, 2008 at 1:27 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > The only problem is if someone figured out a workaround by specifying in > depMgt specifically to override the plugin rev. We should fix this + the > ability to override a plugin's dependency version in the same release so > people at least have an option. > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos > Sanchez > Sent: Tuesday, February 19, 2008 3:57 PM > To: Maven Developers List > Subject: Re: [MNG-3410] Plugin managed versions are ignored > > I dont think is related, this bug only affects plugins that use > dependencyManagement. It does nothing with the plugin dependencies. > > This wold change plugin classpath for all those plugins that have > dependency management, but it will change them to what the plugin was > successfully built with, so I don't think it should be a huge problem > to put it for 2.0.x > > On Feb 19, 2008 9:56 AM, Niall Pemberton <[EMAIL PROTECTED]> > wrote: > > On Feb 19, 2008 5:46 PM, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > > > On Feb 19, 2008 9:40 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > > > > > On 19-Feb-08, at 9:36 AM, Carlos Sanchez wrote: > > > > > > > > > I think you misunderstood. The dependencyManagement is used for > > > > > project dependencies, fine with that. > > > > > When you use a plugin no dependencyManagement is applied. The > current > > > > > project depMan shouldn't be applied because it's only for > projects, so > > > > > that's ok. > > > > > > > > > > The problem comes when a plugin is built using > dependencyManagement to > > > > > force some dependencies. When that plugin is used, the > > > > > dependencyManagement of the plugin is ignored, so you run it > with > > > > > different dependencies than the ones you build it with. > > > > > > > > > > > > > So there is no Map used during the plugin's artifact resolution at > > > > runtime is what you're saying, yes? > > > > > > right, and I think it should use the plugin Map that was used during > > > the plugin build > > > > Perhaps related, but I tried specifying a later version of a plugin's > > dependency and it was ignored: > > > > See http://maven.markmail.org/message/km5mlcfsgqlo7le2 > > > > Niall > > > > > > > > > > > > > > On Feb 19, 2008 9:24 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > >> > > > > >> On 19-Feb-08, at 9:07 AM, Carlos Sanchez wrote: > > > > >> > > > > >>> On Feb 19, 2008 7:46 AM, Jason van Zyl <[EMAIL PROTECTED]> > wrote: > > > > >>>> > > > > >>>> On 18-Feb-08, at 11:54 PM, Carlos Sanchez wrote: > > > > >>>> > > > > >>>>> I'd like to get some feedback in MNG-3410, particularly from > > > > >>>>> John as > > > > >>>>> he has been working on this. > > > > >>>>> > > > > >>>>> If you build and install a plugin with managed versions that > > > > >>>>> affect > > > > >>>>> plugin transitive dependencies, when it's used the > dependency > > > > >>>>> management is ignored > > > > >>>>> > > > > >>>>> If the dependency management affects the plugin direct > dependecies > > > > >>>>> it > > > > >>>>> works properly because the information is merged. > > > > >>>>> > > > > >>>> > > > > >>>> Dependency management should not affect anything to do with > > > > >>>> plugins. > > > > >>>> If that is happening that is completely wrong. > > > > >>>> > > > > >>>> Dependencies and what plugins use should be completely > separate. A > > > > >>>> project's classpath should never affect what is used in a > plugin's > > > > >>>> execution. > > > > >>>> > > > > >>> > > > > >>> it is, the problem is dependencyManagement in the plugin pom > > > > >>> > > > > >> > > > > >> Then somewhere the Map that is used for managed dependencies is > > > > >> getting fed into both the project's resolution and the plugin's > > > > >> resolution and that definitely needs to be separated. Even if > we > > > > >> decide there are certain cases where they should be shared (and > I > > > > >> can't actually think of any real cases except for maybe Antlr > vX > > > > >> generated code needing Antlr vX runtime code which needs to be > > > > >> aligned) they should be separate so we knowingly combine them > if > > > > >> necessary. > > > > >> > > > > >> Problem is if you find that shared Map what are we going to > break if > > > > >> you separate them now? Just thinking aloud. > > > > >> > > > > >> > > > > >>>> > > > > >>>> > > > > >>>>> eg. > > > > >>>>> Plugin A depends on jar B that depends on jar C[1.0] > > > > >>>>> A dependencyManagement explicitly forces C[2.0], you build > and > > > > >>>>> install > > > > >>>>> using C[2.0] in the classpath > > > > >>>> > > > > >>>> dependencyManagement in your POM or in the plugin's POM? > > > > >>> > > > > >>> dependencyManagement in plugin's pom (A) > > > > >>> > > > > >>>> > > > > >>>>> > > > > >>>>> If you use plugin A in your pom it will be used with C > version 1.0 > > > > >>>>> > > > > >>>>> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > 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] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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]
