Re: Why is Maven allowing cycles?
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. 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is Maven allowing cycles?
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 ssh...@gmail.com 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. 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is Maven allowing cycles?
On Sat, Jan 29, 2011 at 2:46 AM, Stephen Connolly stephen.alan.conno...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is Maven allowing cycles?
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
Re: Why is Maven allowing cycles?
On Sat, Jan 29, 2011 at 10:19 AM, Ron Wheeler rwhee...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is Maven allowing cycles?
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 ssh...@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\compamvn 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Why is Maven allowing cycles?
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 Hellewellssh...@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\compamvn 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-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
