Hi,
well, this is indeed a problem..
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?
Option one:
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
users don't necessarily have to clean up their local repository.
I see no harm in updating released poms with the relocation tag; we could
update the warning message to say that a relocation has been detected,
and you should run with -... hey, there's no option for that!
(-U for snapshots, which is <updatePolicy>always, i was looking for something
similar for releases...)
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, but
keeping track
of which version is linked to which g:a when it's time to resolve.
This is probably impossible. It would require major refactoring, since all
artifacts
uniqueness is checked using versionlesskey strings. If it were some sort of
ArtifactId
object it's equals method could say 'yes' for both the new and the old artifact
id's.
Maven 3.0? :)
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, since maven can't guarantee artifact uniqueness anymore. The downside is that this breaks old builds, but they probably all have fixed versions anyway. Adding a parameter/argument/sysprop
to override this would at least let people be aware that there can be unexpected
results.
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]
