Hi, I would like to start a discussion on how relocations in the central repo should be handled.
I recently noticed more and more artifacts partially relocated in the repo in case of a new upload. With *partially* relocated I means the case of a new version of an existing artifact uploaded with a new groupId, and with a relocation pom added only for such new version. A recent example has been tracked at http://jira.codehaus.org/browse/MAVENUPLOAD-1419 (freemarker 2.3.9 uploaded with the groupId org.freemarker, while versions < 2.3.9 keep the "freemaker" groupId without a relocation)
From my experience uploading a new version and relocating *that
version only* will substantially break any build where transitive deps use the new different groupId. With this concrete example, when I have freemarker:freemarker:2.3.8 in my build and a transitive deps starts using org.freemarker:freemarker:2.3.9 my build will be broken by a duplicate dependency (both jars will end up in my war) I saw similar problems in the past, for example when ehcache has been relocated to net.sf.ehcache ( http://jira.codehaus.org/browse/MEV-427 )... anybody depending on hibernate could have been easily hit by this. IMHO having an artifacts which is only partially relocated is something that should never be allowed. We have two options: - relocate any existing versions together (but this means that only people which delete their local copy will see the change) - stop relocating at all when a version already exists! Since the relocation concept has always been broken by the fact that maven has no way for check for relocations automatically, probably the second option is better. Due to relocations or duplicate artifacts in different groupIds the repository is recently becoming less consistent than ever :/ Thoughts? fabrizio --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
