this question was raised in commons when they thought about changing
their groupIds ot org.apache.commons
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg90223.html
Let's clarify one thing, when you say your build broke due to a
relocation, you mean your build broke when you upgraded a dependency,
because if you don't touch your pom (unless you use snapshots)
everything would be fine.
Upgrading a dependency can have this kind of consequences, bringing
dependencies to your build that you don't want. Maybe it'd be good
idea to hold relocations until major releases, like 1.x instead of
1.0.x
changing old poms doesn't seem to be the solution so far, right now is
impossible without breaking builds
Maybe the solution in the long term is MNG-2316 where org.freemarker-x
could say I provide freemarker-x
On 3/18/07, Fabrizio Giustina <[EMAIL PROTECTED]> wrote:
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]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
