Beware.... the changing of the pom schema is a thorny subject... at present we are still stuck trying to decide how to evolve to the next schema (whatever that is) without breaking *everything*
On 22 August 2013 16:54, Phillip Hellewell <ssh...@gmail.com> wrote: > On Wed, Aug 21, 2013 at 8:21 PM, Mark Derricutt <m...@talios.com> wrote: > > On 22/08/2013, at 4:37 AM, Phillip Hellewell <ssh...@gmail.com> wrote: > > > >> My idea to solve this was to add support for a > >> <forcever>true</forcever> in the <dependency> declaration. Thoughts? > > > > I didn't think we could change the POM schema? Not without some epic > major reasoning ( and if we were to change it, there's plenty of things > change… ) > > I have some good news. There is no need for a > <forcever>true</forcever>, so I take back the whole suggestion. > > Why? For starters, if we add a "newest_unless_direct" strategy, many > people can use that and will get the behavior of when the version is > specified inside your own pom, that will be used even if it's not the > newest. > > Secondly, for those using the "newest" strategy I am proposing, they > can still force an old version when absolutely necessary by adding a > dependencyMediationManagement inside their pom to override the > strategy in the parent pom says, e.g.,: > > <dependencyMediationManagement> > <mediation> > <strategy>nearest</strategy> > <condition> > <groupRegex>^mygroup$</groupRegex> > <artifactRegex>^compA$</artifactRegex> > </condition> > </mediation> > </dependencyMediationManagement> > > If I put that in my pom and specify a version for compA, it will use > that version. > > The need to forcefully use an older version of compA than what any > dependency is using is very rare, and should be temporary, hence the > burden and ugliness of adding this whole block to the top of the pom > to achieve it does not bother me. > > Phillip > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
