On 25 August 2010 03:47, Wayne Fay <[email protected]> wrote: >> If a project uses the old groupId to download the release with the new >> groupId then it will find the relocation POM, and Maven can >> potentially correlate the old and new groupIds. However if the project >> uses the new groupId, the relocation POM will not necessarily be read. > > Realistically, people should simply expect that they will need to be a > little bit hands-on with their pom files and dependencies -- even the > transitive ones. Using Maven should not be viewed as entirely "free" > -- you will occasionally need to get your hands dirty and actually > look at the dependency graph for your artifacts. > > You can use dependency exclusions to eliminate unwanted artifacts > under the "old" groupId without much trouble. You can also encourage > your own dependencies (direct and transitive) to update to the new > groupId the next time they push a new release etc.
Unfortunately that is not feasible in general. >> It should also be made very clear that choosing the groupId (etc.) >> needs to be done very carefully, as it is difficult to change later > > Its not so much difficult (for you) to change as it is a pain for your > users (assuming you're a library) since they will need to use > dependency exclusions etc. Exactly - Commons is keen to minimise causing pain for users. Imagine the work that would be required if Commons Logging or Lang changed groupId. In the case of Commons Net there are probably fewer dependencies, but it is still a low-level library. > Wayne > > --------------------------------------------------------------------- > 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]
