You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Shawn Castrianni <Sh...@halliburton.com> on 2008/08/24 10:09:57 UTC
problem with artifact constraint on dependency
I am trying to use the artifact restriction on a dependency:
<dependency name="B" rev="latest.development" transitive="false" conf="*->@">
<artifact name="jarfile" type="jar" ext="jar" ext:path="" ext:home="" ext:homeType=""/>
</dependency>
However, this seems to be messing up other dependencies higher up in the chain. For example, if A is dependent on B with the artifact restriction shown and C is dependent on A, then C does not get the rest of the artifacts of B. I suppose this makes sense so I added a direct dependency of C to B in addition to its direct dependency on A. That means C is dependent on A and B so that it can bypass the artifact restriction that A causes and go directly to B. This worked, by I should add that the order of A and B in the dependencies section of C's ivy.xml file was important (which I think is a bug, the listing order of dependencies in an ivy.xml should be irrelevant).
So I was able to recover from this artifact restriction by making a direct dependency to B. But now the problem is if D is dependent on C. I cannot get D to get the complete B dependency. Somehow the artifact restriction from A is messing up everybody higher up in the chain.
I am using rev 675585 of ivy source. Has this been fixed since that revision? Is this a bug?
---
Shawn Castrianni
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
RE: problem with artifact constraint on dependency
Posted by Shawn Castrianni <Sh...@halliburton.com>.
Stupid me. You are right, I meant to use the "include" subelement instead of "artifact". I will try that and see if it suffers from the propagation to D.
---
Shawn Castrianni
-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Monday, August 25, 2008 11:57 AM
To: ivy-user@ant.apache.org
Subject: Re: problem with artifact constraint on dependency
On Sun, Aug 24, 2008 at 10:09 AM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> I am trying to use the artifact restriction on a dependency:
>
> <dependency name="B"
> rev="latest.development" transitive="false" conf="*->@">
> <artifact name="jarfile"
> type="jar" ext="jar" ext:path="" ext:home="" ext:homeType=""/>
> </dependency>
>
> However, this seems to be messing up other dependencies higher up in the
> chain. For example, if A is dependent on B with the artifact restriction
> shown and C is dependent on A, then C does not get the rest of the artifacts
> of B. I suppose this makes sense so I added a direct dependency of C to B
> in addition to its direct dependency on A. That means C is dependent on A
> and B so that it can bypass the artifact restriction that A causes and go
> directly to B. This worked, by I should add that the order of A and B in
> the dependencies section of C's ivy.xml file was important (which I think is
> a bug, the listing order of dependencies in an ivy.xml should be
> irrelevant).
>
> So I was able to recover from this artifact restriction by making a direct
> dependency to B. But now the problem is if D is dependent on C. I cannot
> get D to get the complete B dependency. Somehow the artifact restriction
> from A is messing up everybody higher up in the chain.
>
> I am using rev 675585 of ivy source. Has this been fixed since that
> revision? Is this a bug?
I think this is is a bug which hasn't been fixed yet. Let me be clear, the
fact that you have to add a direct dependency from C to A is normal, what is
not normal is that the order of dependencies is relevant, and that it
doesn't propagate to D. Please open a jira about that.
That being said, I'd like to give more insight on what the "artifact"
subelement of dependency is made for: it is intended to declare an artifact
which is not declared in the original module descriptor, and should be used
only when you don't have control over the dependency module descriptor. This
is slightly different from artifact restriction, which is supported with the
include sub element. Until 1.4 there was no such distinction between the two
(artifact and include), but now the two have different meanings. So if all
you want is filter the list of artifacts out of a list of artifacts already
declared in the module descriptor of the dependency, you should use include,
which shouldn't suffer from the same defect (we have fixed several similar
bugs for artifact include in 2.0).
HTH,
Xavier
>
>
> ---
> Shawn Castrianni
>
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: problem with artifact constraint on dependency
Posted by Xavier Hanin <xa...@gmail.com>.
On Sun, Aug 24, 2008 at 10:09 AM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:
> I am trying to use the artifact restriction on a dependency:
>
> <dependency name="B"
> rev="latest.development" transitive="false" conf="*->@">
> <artifact name="jarfile"
> type="jar" ext="jar" ext:path="" ext:home="" ext:homeType=""/>
> </dependency>
>
> However, this seems to be messing up other dependencies higher up in the
> chain. For example, if A is dependent on B with the artifact restriction
> shown and C is dependent on A, then C does not get the rest of the artifacts
> of B. I suppose this makes sense so I added a direct dependency of C to B
> in addition to its direct dependency on A. That means C is dependent on A
> and B so that it can bypass the artifact restriction that A causes and go
> directly to B. This worked, by I should add that the order of A and B in
> the dependencies section of C's ivy.xml file was important (which I think is
> a bug, the listing order of dependencies in an ivy.xml should be
> irrelevant).
>
> So I was able to recover from this artifact restriction by making a direct
> dependency to B. But now the problem is if D is dependent on C. I cannot
> get D to get the complete B dependency. Somehow the artifact restriction
> from A is messing up everybody higher up in the chain.
>
> I am using rev 675585 of ivy source. Has this been fixed since that
> revision? Is this a bug?
I think this is is a bug which hasn't been fixed yet. Let me be clear, the
fact that you have to add a direct dependency from C to A is normal, what is
not normal is that the order of dependencies is relevant, and that it
doesn't propagate to D. Please open a jira about that.
That being said, I'd like to give more insight on what the "artifact"
subelement of dependency is made for: it is intended to declare an artifact
which is not declared in the original module descriptor, and should be used
only when you don't have control over the dependency module descriptor. This
is slightly different from artifact restriction, which is supported with the
include sub element. Until 1.4 there was no such distinction between the two
(artifact and include), but now the two have different meanings. So if all
you want is filter the list of artifacts out of a list of artifacts already
declared in the module descriptor of the dependency, you should use include,
which shouldn't suffer from the same defect (we have fixed several similar
bugs for artifact include in 2.0).
HTH,
Xavier
>
>
> ---
> Shawn Castrianni
>
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/