Problem with transitive dependencies

[Oystein Aadland <iv...@lookoutpoint.org>]

Hi

I'm trying to upgrade to version 1.4.1 og ivy from version 1.1. Yes the
upgrade is way overdue. Anyway I have this problem with transitive
dependeincies.

I have a module A that uses module B.
Module B uses a build konfiguration of module C
Module A uses a build konfiguration og module C and a runtime configuration
of module B

Module B downloads explisit jars from C depending on configuration.

When I resolve A in build configuration I only get the explisit defined
runtime jars that B defines for module C.

Here are snippets of the ivy files.

Module A:
...
<dependencies>
  <dependency org="myorg" name="B" rev="1.6" conf="build->runtime" />
  <dependency org="myorg" name="C" rev="1.10" conf="build,runtime->default"
/>
</dependencies>
...

Module B
...
<configurations>
    <conf name="build" visibility="private"/>
    <conf name="runtime"/>
</configurations>
<dependencies>
  <dependency org="myorg" name="C" rev="1.10" conf="build,runtime->default">
      <artifact name="art1" type="jar" conf="runtime"/>
      <artifact name="art2" type="jar" conf="runtime"/>
      <artifact name="art3" type="jar" conf="runtime"/>
  </dependency>
</dependencies>
...

Module C
...
<publications>
        <artifact name="art1" type="jar" conf="default"/>
        <artifact name="art2" type="jar" conf="default"/>
        <artifact name="art3" type="jar" conf="default"/>
        <artifact name="art4" type="jar" conf="default"/>
</publications>
...


So when I resolve Module B I get art1.jar, art2.jar and art3.jar from module
C but not art4.jar

Can anyone please tell med what I'm doing wrong? This worked fine in 1.1.

Please apologize if I have overlooked that this issue has been discussed
before, I have searched, but found nothing.

Thank you
Oystein

Re: Problem with transitive dependencies

[Oystein Aadland <iv...@lookoutpoint.org>]

Open JIRA issue IVY-541 (
https://issues.apache.org/jira/browse/IVY-541?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel)
and included a possible fix. At least the fix worked in my case.

Oystein

On 6/25/07, Xavier Hanin <xa...@gmail.com> wrote:
>
> On 6/22/07, Oystein Aadland <iv...@lookoutpoint.org> wrote:
> >
> >
> > Well. I've been browsing the source code and it looks like this works if
> I
> > put explicit includes for the missing Module C artifacts in Module A.
> >
> > I thought that putting a dependency for a spesific configuration by
> > default
> > means all artifacts for that dependency. It certainly works that way if
> > there's no other "conflicting" modules in the dependency list.
> >
> > This smells like a bug to me. In the code (IvyNode.loadData) a
> dependency
> > is
> > only loaded if it hasn't been loaded before (first if). At the end of
> this
> > method explisit includes are added. If my assumption about what should
> > default be included is right then all artifacts for the given
> > configuration
> > should have been added if the include list is empty.
> >
> > Anyone out there that nows if my reasoning is correct?
>
>
> Indeed, your reasonning seems correct. Since A depends on C with no
> artifact
> restriction you should get all C artifacts when resolving A dependencies.
> Could you please open an issue in JIRA?
>
> Xavier
>
> Oystein
> > --
> > View this message in context:
> >
> http://www.nabble.com/Problem-with-transitive-dependencies-tf3957355.html#a11248224
> > Sent from the ivy-user mailing list archive at Nabble.com.
> >
> >
>
>
> --
> Xavier Hanin - Independent Java Consultant
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/
>

Re: Problem with transitive dependencies

[Xavier Hanin <xa...@gmail.com>]

On 6/22/07, Oystein Aadland <iv...@lookoutpoint.org> wrote:
>
>
> Well. I've been browsing the source code and it looks like this works if I
> put explicit includes for the missing Module C artifacts in Module A.
>
> I thought that putting a dependency for a spesific configuration by
> default
> means all artifacts for that dependency. It certainly works that way if
> there's no other "conflicting" modules in the dependency list.
>
> This smells like a bug to me. In the code (IvyNode.loadData) a dependency
> is
> only loaded if it hasn't been loaded before (first if). At the end of this
> method explisit includes are added. If my assumption about what should
> default be included is right then all artifacts for the given
> configuration
> should have been added if the include list is empty.
>
> Anyone out there that nows if my reasoning is correct?


Indeed, your reasonning seems correct. Since A depends on C with no artifact
restriction you should get all C artifacts when resolving A dependencies.
Could you please open an issue in JIRA?

Xavier

Oystein
> --
> View this message in context:
> http://www.nabble.com/Problem-with-transitive-dependencies-tf3957355.html#a11248224
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: Problem with transitive dependencies

[Oystein Aadland <iv...@lookoutpoint.org>]

Well. I've been browsing the source code and it looks like this works if I
put explicit includes for the missing Module C artifacts in Module A.

I thought that putting a dependency for a spesific configuration by default
means all artifacts for that dependency. It certainly works that way if
there's no other "conflicting" modules in the dependency list.

This smells like a bug to me. In the code (IvyNode.loadData) a dependency is
only loaded if it hasn't been loaded before (first if). At the end of this
method explisit includes are added. If my assumption about what should
default be included is right then all artifacts for the given configuration
should have been added if the include list is empty.

Anyone out there that nows if my reasoning is correct?

Oystein
-- 
View this message in context: http://www.nabble.com/Problem-with-transitive-dependencies-tf3957355.html#a11248224
Sent from the ivy-user mailing list archive at Nabble.com.