Which is why I think that the rules need to be defined at the repository, and per groupId
2009/2/10 Brian E. Fox <[email protected]>: > Once multiple resolution strategies start appearing, life will be > infinitely more complicated. If you use a different strategy and I > consume your artifacts, I need to be able to interpret your strategy and > use it when calculating your part of the tree. (and someone else's etc). > That means the strategies need to be implemented and available in the > repository for mercury to use. > > -----Original Message----- > From: Stephen Connolly [mailto:[email protected]] > Sent: Tuesday, February 10, 2009 3:32 AM > To: Maven Developers List > Subject: Version comparison rules > > OK, here's a hairy old chestnut... > > Maven has a set of version comparison rules... they don't work for > everyone... well life sucks > > Mercury has a new set of version comparison rules... they're a lot > better, but probably don't work for everyone... life still sucks... > > I've been thinking, the reality is that version comparison rules are > very much an organisation thing... so they really should be defined by > the organisation... > > In versions-maven-plugin, I've added a third version comparator... it > won't work for everyone... life still sucks... > > What I'm thinking is that if we had some metadata associated with the > groupId, it could specify what the version comparison rule is for that > groupId (and all it's child groupIds)... > > OK, so I can do something similar in versions-maven-plugin to let > people define their rules for their groupIds, but this is something > that should really go into the repository... a > version-comparison-metadata.xml file... > > we can start easy, by just defining the root rule as the current maven > rules... > > The maven-deploy-plugin and nexus/artifactory could then use that rule > to update the latest and release tags in the metadata.xml files... ok, > so Maven 2.0.x could ignore the rules, or a small change could add > support... > > What do people think... > > We could even define the v-c-m.xml file to handle rule change-over, so > that we don't break existing builds... > > e.g. > > <rules> > <rule regex="..." priority="9999">maven</rule> > <rule regex="..." priority="1">mercury</rule> > </rules> > > so that versions matching mercury's regex will have a high priority > and use mercury's rule within, while versions matching maven's regex > will always be older than those matching mercury's regex, but will be > compared with each other using maven's rules > > -Stephen > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
