On 3/17/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
I don't understand the second option: if you stop relocating (not done by maven, but by the pom deployers, right?) when a version exists, that means you can never relocate. It's no use to relocate unreleased poms since they won't be present in the repository. So this makes no sense to me. What didn't I understand?
Relocation still makes sense when two copy of the same artifacts are already in the repository with two different groupIds. That's the only situation when relocation should be performed IMHO, since it just mitigate a worst situation, but not when uploading a new version for an artifacts that only exists with a stable groupId.
What happened to the deployment management section in the pom? Where it states 'deployed' or 'manually checked' or something like that. Maven does support checking for updates on non-snapshot poms, so
well, it just doesn't/can't do that at all at the moment, no options for that :/ and so far nothing is scheduled for 2.1 too.
We could ofcourse fix maven to be more aware of the relocation; when it finds a relocation for any dependency it should treat the old and the new g:a as equal to avoid duplicates,
this would require knowing which artifacts is a relocation of which other, something that is not available either. If I link freemarker:freemarker:2.3.8 and freemarker:freemarker:2.3.9 maven will see that the second one has been relocated to org:freemarker and could handle it as a duplicate of freemarker:... If I directly link freemarker:freemarker:2.3.8 and org.freemarker:freemarker:2.3.9 there is no trace that the org.freemarker groupId is the "relocation target" of freemarker. If any version of the artifact is relocated to the "right" groupId this would be easy.
So I guess we're probably stuck with making the warning extremely clear. Maven could abort the build when the relocation tag is found, and force users to update their poms,
this would be useless at the moment... what if you are using the right groupId and a dependency uses the old, unrelocated one? You can't say "fix the pom for your transitive dep. BTW relocated dependencies are not fixed "by design" in existing deployed pom, also requests in MEV for that have been closed as a "won't fix" and this makes the problem even harder to solve for users. fabrizio
tough one ;) -- Kenney Fabrizio Giustina wrote: > 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] --------------------------------------------------------------------- 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]
