Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

I agree that a global relocations.xml would not scale. You can't change the old (5.1.0) pom, so the most obvious place is simply adding this meta-data in the new pom (5.2.0): groupIdorg.drools.guvnor/groupId artifactIdguvnor-repository/artifactId version5.2.0/version legacy-identifications

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Hi Geoffry, Geoffrey De Smet wrote: I agree that a global relocations.xml would not scale. You can't change the old (5.1.0) pom, so the most obvious place is simply adding this meta-data in the new pom (5.2.0): groupIdorg.drools.guvnor/groupId artifactIdguvnor-repository/artifactId

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

On 19/01/2011 4:14 AM, Geoffrey De Smet wrote: I agree that a global relocations.xml would not scale. You can't change the old (5.1.0) pom, so the most obvious place is simply adding this meta-data in the new pom (5.2.0): groupIdorg.drools.guvnor/groupId artifactIdguvnor-repository/artifactId

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

The closest you will get is to deploy a relocation pom at the old GA with the new V., e.g. at groupIdorg.drools/groupId artifactIddrools-repository/artifactId version5.2.0/version it's not perfect (i.e. it will only notify people using ranges and only fools use ranges!) and it does not do

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

All this emphasizes how important it is to get the GA right in the beginning. As long as no one depends on your artifacts it's not a big deal, but when you have lots of users you will cause issues. If you absolutely do need to change GA, you must broadcast this to your users very clearly! The

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

There should be some support for changing the GA. Getting it right immediately, forever in the beginning is not realistic. Projects names change (hudson - jenkins, drools-solver - drools-planner), and subprojects graduate away from their parent project (turbine-maven - maven). There are plenty

Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

There should be some support for changing the GA. Getting it right immediately, forever in the beginning is not realistic. But how would you implement this? The only way I can think off the top of my head is a global relocations.xml that is stored in Central and is somehow used to manage these

Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection

Hi, We have a pom.xml for the drools guvnor repository jar, with this identification: groupIdorg.drools/groupId artifactIddrools-repository/artifactId version5.1.0/version Now, for the next version of that jar, we need to change the identification to: groupIdorg.drools.guvnor/groupId