You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Phillip Hellewell <ss...@gmail.com> on 2011/01/24 23:56:38 UTC
Why is Maven allowing cycles?
I don't know if I've lost my mind or what, but Maven is not giving me
an error when I have cyclic dependencies.
I just tried a simple two projects A and B that depend on each other,
and Maven gives me no errors when resolving dependencies.
You can clearly see the cycle when running mvn dependency:tree.
C:\mycomps2\compa>mvn dependency:tree
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building compa
[INFO] task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
[INFO] mygroup:compa:pom:1.0.0
[INFO] \- mygroup:compb:zip:vc-all:1.0.0:compile
[INFO] \- mygroup:compa:zip:vc-all:1.0.0:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Mon Jan 24 15:00:16 MST 2011
[INFO] Final Memory: 19M/483M
[INFO] ------------------------------------------------------------------------
Am I losing my mind? What's going on? Does it have something to do
with the fact that I am using the assembly plugin with "zip"
classifer?
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is Maven allowing cycles?
Posted by Phillip Hellewell <ss...@gmail.com>.
On Sat, Jan 29, 2011 at 2:46 AM, Stephen Connolly
<st...@gmail.com> wrote:
> maven won't allow cycles in the same reactor build
I don't know what a reactor build is yet or how to do one, but that is
good to know.
> if you are not bulging in one reactor then there may be an issue... you
> should raise a jira
Ok, I created this: http://jira.codehaus.org/browse/MNG-4999
Thanks,
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is Maven allowing cycles?
Posted by Stephen Connolly <st...@gmail.com>.
maven won't allow cycles in the same reactor build
if you are not bulging in one reactor then there may be an issue... you
should raise a jira
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 29 Jan 2011 09:00, "Phillip Hellewell" <ss...@gmail.com> wrote:
> On Thu, Jan 27, 2011 at 1:11 PM, Ron Wheeler
> <rw...@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.
>
> 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).
>
>> 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.
>
> 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.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Why is Maven allowing cycles?
Posted by Phillip Hellewell <ss...@gmail.com>.
On Sat, Jan 29, 2011 at 10:19 AM, Ron Wheeler
<rw...@artifact-software.com> wrote:
> Since Releases are immutable, this is a different case.
> You were talking about releases in your initial example.
Sorry about the confusion, but yeah I've never actually ran into this
problem with releases, only snapshots. The example I sent in my first
email may not have been valid since I wasn't deploying the releases
properly.
> I can see how your example with SNAPSHOTS can happen and it would make a
> rather tough and puzzling problem to debug during development.
Yep.
> Self-inflicted wounds are just as painful as the shots one takes from third
> parties.
It's sad but we managed to inflict this upon ourselves with our own
components, not third parties' :(
I'm thinking that if bug MNG-4999 gets rejected as "Won't Fix", I
could suggest that the cycle and version clash detection be added as
goals to the dependency plugin. That seems like a logical place to
keep that functionality. And if the owners of that plugin don't want
that in there, I'll just maintain our own little plugin.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is Maven allowing cycles?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 29/01/2011 3:59 AM, Phillip Hellewell wrote:
> On Thu, Jan 27, 2011 at 1:11 PM, Ron Wheeler
> <rw...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is Maven allowing cycles?
Posted by Phillip Hellewell <ss...@gmail.com>.
On Thu, Jan 27, 2011 at 1:11 PM, Ron Wheeler
<rw...@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.
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).
> 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.
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.
Phillip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is Maven allowing cycles?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 27/01/2011 10:11 AM, Phillip Hellewell wrote:
> Doesn't anyone know if Maven is supposed to give you an error when
> there is a cycle?
>
> If the answer is yes, then I need to figure out what I'm missing.
>
> If the answer is no, then I'll write a plugin to detect cycles and
> give an error. I've already got a plugin that detects a version clash
> (same artifact in the tree twice with different versions), so I could
> just add cycle detection to that one. It will probably be as simple
> as checking for myself in the tree of dependencies.
>
> Phillip
>
> On Mon, Jan 24, 2011 at 3:56 PM, Phillip Hellewell<ss...@gmail.com> wrote:
>> I don't know if I've lost my mind or what, but Maven is not giving me
>> an error when I have cyclic dependencies.
>>
>> I just tried a simple two projects A and B that depend on each other,
>> and Maven gives me no errors when resolving dependencies.
>>
>> You can clearly see the cycle when running mvn dependency:tree.
>>
>> C:\mycomps2\compa>mvn dependency:tree
>> [INFO] Scanning for projects...
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Building compa
>> [INFO] task-segment: [dependency:tree]
>> [INFO] ------------------------------------------------------------------------
>> [INFO] [dependency:tree {execution: default-cli}]
>> [INFO] mygroup:compa:pom:1.0.0
>> [INFO] \- mygroup:compb:zip:vc-all:1.0.0:compile
>> [INFO] \- mygroup:compa:zip:vc-all:1.0.0:compile
>> [INFO] ------------------------------------------------------------------------
>> [INFO] BUILD SUCCESSFUL
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Total time: 1 second
>> [INFO] Finished at: Mon Jan 24 15:00:16 MST 2011
>> [INFO] Final Memory: 19M/483M
>> [INFO] ------------------------------------------------------------------------
>>
>> Am I losing my mind? What's going on? Does it have something to do
>> with the fact that I am using the assembly plugin with "zip"
>> classifer?
>>
>> Phillip
>>
Does this matter?
Is more than 1 copy of mygroup:compa:zip:vc-all:1.0.0 being included.
It seems silly to make something dependent on itself and I can't imagine how your would build it in the first place withyout getting an error.
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.
I am missing the harm that this does since it will get detected earlier in the process.
Ron
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is Maven allowing cycles?
Posted by Phillip Hellewell <ss...@gmail.com>.
Doesn't anyone know if Maven is supposed to give you an error when
there is a cycle?
If the answer is yes, then I need to figure out what I'm missing.
If the answer is no, then I'll write a plugin to detect cycles and
give an error. I've already got a plugin that detects a version clash
(same artifact in the tree twice with different versions), so I could
just add cycle detection to that one. It will probably be as simple
as checking for myself in the tree of dependencies.
Phillip
On Mon, Jan 24, 2011 at 3:56 PM, Phillip Hellewell <ss...@gmail.com> wrote:
> I don't know if I've lost my mind or what, but Maven is not giving me
> an error when I have cyclic dependencies.
>
> I just tried a simple two projects A and B that depend on each other,
> and Maven gives me no errors when resolving dependencies.
>
> You can clearly see the cycle when running mvn dependency:tree.
>
> C:\mycomps2\compa>mvn dependency:tree
> [INFO] Scanning for projects...
> [INFO] ------------------------------------------------------------------------
> [INFO] Building compa
> [INFO] task-segment: [dependency:tree]
> [INFO] ------------------------------------------------------------------------
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] mygroup:compa:pom:1.0.0
> [INFO] \- mygroup:compb:zip:vc-all:1.0.0:compile
> [INFO] \- mygroup:compa:zip:vc-all:1.0.0:compile
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1 second
> [INFO] Finished at: Mon Jan 24 15:00:16 MST 2011
> [INFO] Final Memory: 19M/483M
> [INFO] ------------------------------------------------------------------------
>
> Am I losing my mind? What's going on? Does it have something to do
> with the fact that I am using the assembly plugin with "zip"
> classifer?
>
> Phillip
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org