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]
