[
http://jira.codehaus.org/browse/MAVENUPLOAD-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
fabrizio giustina reopened MAVENUPLOAD-1419:
--------------------------------------------
This should probably be also tracked on MEV but since this is a concrete
example I am going to discuss it here:
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).
Having a groupId 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 :/
please, never close an upload/relocation request if the relocation has been
applied consistently... at least any version in freemarker:freemarker should
now be relocated to org:freemarker:freemarker
> Upload FreeMarker 2.3.9
> -----------------------
>
> Key: MAVENUPLOAD-1419
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1419
> Project: maven-upload-requests
> Issue Type: Task
> Reporter: Mirko Nasato
> Assigned To: Carlos Sanchez
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
