On 29/01/2011 3:59 AM, Phillip Hellewell wrote:
On Thu, Jan 27, 2011 at 1:11 PM, Ron Wheeler
<rwhee...@artifact-software.com> wrote:
Does this matter?
Yes. A cycle is a serious dependency problem that gone unnoticed may
be harder to fix later.
Is more than 1 copy of mygroup:compa:zip:vc-all:1.0.0 being included.
Yes, in the sense that compa exists where it is checked out, and then
another (older) copy of the binaries of compa gets unpacked below
target\dependency.
It seems silly to make something dependent on itself and I can't imagine how
Well obviously no one does it on purpose.
your would build it in the first place withyout getting an error.
It can happen without getting an error. Just follow these steps and you'll see:
1. Make B that doesn't depend on anything. Deploy a snapshot of B.
2. Make A that depends on the snapshot of B . Deploy a snapshot of A.
3. Change B to depend on the snapshot of A. Now deploy a new snapshot
of B (same version as in step 1).
Now A depends on itself through B, but Maven gives no errors when building A.
Since Releases are immutable, this is a different case.
You were talking about releases in your initial example.
I suppose you could make B depend on an older version of B but your
example had only a single version of B involved.
Now a tight cycle like this would not likely happen in real life
because it's too obvious. But with a bigger dependency tree it can
and actually DID happen to me just last week (well, not me personally;
of course it was someone else at my workplace).
With releases?
I can see how your example with SNAPSHOTS can happen and it would make a
rather tough and puzzling problem to debug during development.
But for mygroup:compa:pom:1.0.0, it will get 1
mygroup:compa:zip:vc-all:1.0.0 and that is what it needs.
No, it was never intended for compa to depend on itself and of course
it doesn't need to depend on itself. That's ridiculous and ought to
result in an error.
BTW, the type and classifier is kind of a red herring here. It shows
"pom" because the packaging type is pom and "zip:vc-all" because the
artifact is packaged as a zip with classifier vc-all, but that doesn't
change the fact that it is compa depending on itself. Also, this can
happen with "jar" packaging too, and then it would say "jar" in both
places (I did that test too).
I am missing the harm that this does since it will get detected earlier in
the process.
Wrong. See steps above.
I guess I shouldn't be surprised that Maven doesn't detect a cycle as
an error. It's just funny because before we even made the decision to
go with Maven at my workplace, we had talked specifically about how a
dependency management system would automatically prevent issues like
cycles and version clashes. And we chose Maven, but Maven doesn't
detect either of these.
In the release case, it would show the version conflict in the
dependency hierarchy view but that is probably not the first place that
one would look when trying to debug the type of problem that this error
would cause.
I have never tested to see if a SNAPSHOT conflict would show up in the
dependency hierarchy.
It would not be detectable from the POM files' dependencies but only by
actually looking at the deployed versions of the SNAPSHOTs in the repo.
The good news is Maven is flexible with plugins. We wrote a plugin to
detect version clashes, and it won't be hard to add cycle detection.
We execute this in our parent pom during the validate phase, so it
will fail when we want.
I just can't believe no one else has run into this.
It is a particular sub-case of a version conflict which is not uncommon
when using third party libraries and we do check the dependency
hierarchy for this but we are not usually looking for conflicts within
SNAPSHOT versions.
Self-inflicted wounds are just as painful as the shots one takes from
third parties.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
