ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: problem with artifact constraint on dependency
Date Mon, 25 Aug 2008 16:57:15 GMT
On Sun, Aug 24, 2008 at 10:09 AM, Shawn Castrianni <> 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).



> ---
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message