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 Johannes Stamminger <Jo...@astrium.eads.net> on 2007/06/15 17:07:17 UTC
artifacts of evicted module
Hi,
we just try to switch our dependencies management to use ivy (v1.4.1).
Today we were faced with a problem with the default conflict management of
artifacts provided by an evicted module.
The situation as it presents to us seems to be like:
moduleA-1.0 provides artifactA
moduleA-2.0 provides artifactB (important: the artifact's name, not (only)
it's version, changed)
moduleB-1.0 depends on moduleA-1.0
moduleC-1.0 depends on moduleA-2.0
moduleC-1.0 depends on moduleB-1.0
In that case there is a conflict and the default conflict manager resolution
is to evict moduleA-1.0. But still it is tried to download artifactA - but
from moduleA-2.0's directory ... and of course this fails.
Is this expected bahaviour?
Or do you expect some wrong definitions in our ivy configurations to cause
this?
Regards,
Johannes Stamminger
--
Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
------ ----<--{(@ ------------------ EADS ASTRIUM
Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
+49 4242 169582 (Tel + FAX) Huenefeldstr. 1-5, 28199 Bremen
+49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
---------------------------------------------------------
Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller - Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo Salame Fischer
Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen, HRB Nr. 107 647
Re: artifacts of evicted module
Posted by Xavier Hanin <xa...@gmail.com>.
On 6/25/07, Johannes Stamminger <Jo...@astrium.eads.net>
wrote:
>
>
> Hi again a last time for today!
>
>
> Hi just tested the 2.0.0-alpha1 behaviour (with the example provided as
> attachment to IVY-537).
>
> Good: the build no longer fails with not using an all-conflict manager as
> workaround and all evictions were done as expected.
>
> But: graph and html do no longer show any eviction information nor the
> dependencies hirarchy.
>
> Is there something more to do than switching the ivy-jar in the apache
> libs or
> are those known issues or ... ?
No, there's nothing more to do than switching the jar. It's a good news to
know eviction is working as expected, I'm surprised about the reports. Since
we have your example attached with IVY-537, we'll try to find out what's
happening.
Xavier
Regards,
> Johannes Stamminger
>
>
> On Monday 25 June 2007, Johannes Stamminger wrote:
> > Hi!
> >
> > On Monday 25 June 2007, Xavier Hanin wrote:
> > > On 6/25/07, Johannes Stamminger <Jo...@astrium.eads.net>
> > >
> > > wrote:
> > > > Hi again!
> > > >
> > > >
> > > > Our workaround was so far to use the all-conflict manager instead.
> > > >
> > > >
> > > > Today I found the time to extract a sample configuration of our more
> > > > complex
> > > > setup. And it revealed, that the problem is not with modules
> providing
> > > > their
> > > > dependencies themselves by way of delivered ivy files. But with
> > > > external libs
> > > > whose artifacts are referenced from a module's ivy file, there the
> > > > problem appears. With moduleA referencing libX-1.0 with:
> > > >
> > > > <dependency name="libX" rev="1.0" org="COTS" conf="compile,
> > > > development, deployment">
> > > > <artifact name="libX" conf="compile"/>
> > > > <artifact name="LICENSE" type="license" ext="txt"
> > > > conf="deployment"/>
> > > > <artifact name="libX" type="source" ext="src.jar"
> > > > conf="development"/>
> > > > </dependency>
> > > >
> > > >
> > > > and another module referencing same libX but in version 2.0 by way
> of:
> > > >
> > > > <dependency name="libX" rev="2.0" org="COTS" conf="compile,
> > > > development, deployment">
> > > > <artifact name="libX" conf="compile"/>
> > > > <artifact name="libX" type="license" ext="jar.license"
> > > > conf="deployment"/>
> > > > <artifact name="libX" type="source" ext="src.jar"
> > > > conf="development"/>
> > > > </dependency>
> > > >
> > > >
> > > > the eviction of libX-1.0 fails (note the different namings for the
> > > > license artifact).
> > > >
> > > > I have a complete running example available - but as I read from
> > > > previous mails, attachments are stripped. So I cannot provide it
> here
> > > > but will attach
> > > > it tomorrow to a new issue ... unless you believe my way of
> referencing
> > > > libX
> > > > being not correct ... ?
> > >
> > > You can open the issue, your referencing is correct.
> >
> > Thanks for the confirmation! The bug is now filed in
> > https://issues.apache.org/jira/browse/IVY-537
> >
> >
> > Regards,
> > Johannes Stamminger
> > ...
>
>
>
> --
> !!! NEU/NEW !!! vvvvvvv
> Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
> ------ ----<--{(@ ------------------ EADS ASTRIUM
> Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
> +49 4242 169582 (Tel + FAX) Huenefeldstr. 1-5, 28199 Bremen
> +49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
>
> This email (including any attachments) may contain confidential and/or
> privileged information or information otherwise protected from disclosure.
> If you are not the intended recipient, please notify the sender immediately,
> do not copy this message or any attachments and do not use it for any
> purpose or disclose its content to any person, but delete this message and
> any attachments from your system. Astrium disclaims any and all liability if
> this email transmission was virus corrupted, altered or falsified.
> ---------------------------------------------------------
> Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller -
> Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo
> Salame Fischer
> Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen,
> HRB Nr. 107 647
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
Re: artifacts of evicted module
Posted by Johannes Stamminger <Jo...@astrium.eads.net>.
Hi again a last time for today!
Hi just tested the 2.0.0-alpha1 behaviour (with the example provided as
attachment to IVY-537).
Good: the build no longer fails with not using an all-conflict manager as
workaround and all evictions were done as expected.
But: graph and html do no longer show any eviction information nor the
dependencies hirarchy.
Is there something more to do than switching the ivy-jar in the apache libs or
are those known issues or ... ?
Regards,
Johannes Stamminger
On Monday 25 June 2007, Johannes Stamminger wrote:
> Hi!
>
> On Monday 25 June 2007, Xavier Hanin wrote:
> > On 6/25/07, Johannes Stamminger <Jo...@astrium.eads.net>
> >
> > wrote:
> > > Hi again!
> > >
> > >
> > > Our workaround was so far to use the all-conflict manager instead.
> > >
> > >
> > > Today I found the time to extract a sample configuration of our more
> > > complex
> > > setup. And it revealed, that the problem is not with modules providing
> > > their
> > > dependencies themselves by way of delivered ivy files. But with
> > > external libs
> > > whose artifacts are referenced from a module's ivy file, there the
> > > problem appears. With moduleA referencing libX-1.0 with:
> > >
> > > <dependency name="libX" rev="1.0" org="COTS" conf="compile,
> > > development, deployment">
> > > <artifact name="libX" conf="compile"/>
> > > <artifact name="LICENSE" type="license" ext="txt"
> > > conf="deployment"/>
> > > <artifact name="libX" type="source" ext="src.jar"
> > > conf="development"/>
> > > </dependency>
> > >
> > >
> > > and another module referencing same libX but in version 2.0 by way of:
> > >
> > > <dependency name="libX" rev="2.0" org="COTS" conf="compile,
> > > development, deployment">
> > > <artifact name="libX" conf="compile"/>
> > > <artifact name="libX" type="license" ext="jar.license"
> > > conf="deployment"/>
> > > <artifact name="libX" type="source" ext="src.jar"
> > > conf="development"/>
> > > </dependency>
> > >
> > >
> > > the eviction of libX-1.0 fails (note the different namings for the
> > > license artifact).
> > >
> > > I have a complete running example available - but as I read from
> > > previous mails, attachments are stripped. So I cannot provide it here
> > > but will attach
> > > it tomorrow to a new issue ... unless you believe my way of referencing
> > > libX
> > > being not correct ... ?
> >
> > You can open the issue, your referencing is correct.
>
> Thanks for the confirmation! The bug is now filed in
> https://issues.apache.org/jira/browse/IVY-537
>
>
> Regards,
> Johannes Stamminger
> ...
--
!!! NEU/NEW !!! vvvvvvv
Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
------ ----<--{(@ ------------------ EADS ASTRIUM
Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
+49 4242 169582 (Tel + FAX) Huenefeldstr. 1-5, 28199 Bremen
+49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
---------------------------------------------------------
Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller - Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo Salame Fischer
Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen, HRB Nr. 107 647
Re: artifacts of evicted module
Posted by Johannes Stamminger <Jo...@astrium.eads.net>.
Hi!
On Monday 25 June 2007, Xavier Hanin wrote:
> On 6/25/07, Johannes Stamminger <Jo...@astrium.eads.net>
>
> wrote:
> > Hi again!
> >
> >
> > Our workaround was so far to use the all-conflict manager instead.
> >
> >
> > Today I found the time to extract a sample configuration of our more
> > complex
> > setup. And it revealed, that the problem is not with modules providing
> > their
> > dependencies themselves by way of delivered ivy files. But with external
> > libs
> > whose artifacts are referenced from a module's ivy file, there the
> > problem appears. With moduleA referencing libX-1.0 with:
> >
> > <dependency name="libX" rev="1.0" org="COTS" conf="compile,
> > development, deployment">
> > <artifact name="libX" conf="compile"/>
> > <artifact name="LICENSE" type="license" ext="txt"
> > conf="deployment"/>
> > <artifact name="libX" type="source" ext="src.jar"
> > conf="development"/>
> > </dependency>
> >
> >
> > and another module referencing same libX but in version 2.0 by way of:
> >
> > <dependency name="libX" rev="2.0" org="COTS" conf="compile,
> > development, deployment">
> > <artifact name="libX" conf="compile"/>
> > <artifact name="libX" type="license" ext="jar.license"
> > conf="deployment"/>
> > <artifact name="libX" type="source" ext="src.jar"
> > conf="development"/>
> > </dependency>
> >
> >
> > the eviction of libX-1.0 fails (note the different namings for the
> > license artifact).
> >
> > I have a complete running example available - but as I read from previous
> > mails, attachments are stripped. So I cannot provide it here but will
> > attach
> > it tomorrow to a new issue ... unless you believe my way of referencing
> > libX
> > being not correct ... ?
>
> You can open the issue, your referencing is correct.
Thanks for the confirmation! The bug is now filed in
https://issues.apache.org/jira/browse/IVY-537
Regards,
Johannes Stamminger
...
--
!!! NEU/NEW !!! vvvvvvv
Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
------ ----<--{(@ ------------------ EADS ASTRIUM
Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
+49 4242 169582 (Tel + FAX) Huenefeldstr. 1-5, 28199 Bremen
+49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
---------------------------------------------------------
Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller - Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo Salame Fischer
Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen, HRB Nr. 107 647
Re: artifacts of evicted module
Posted by Xavier Hanin <xa...@gmail.com>.
On 6/25/07, Johannes Stamminger <Jo...@astrium.eads.net>
wrote:
>
>
> Hi again!
>
>
> Our workaround was so far to use the all-conflict manager instead.
>
>
> Today I found the time to extract a sample configuration of our more
> complex
> setup. And it revealed, that the problem is not with modules providing
> their
> dependencies themselves by way of delivered ivy files. But with external
> libs
> whose artifacts are referenced from a module's ivy file, there the problem
> appears. With moduleA referencing libX-1.0 with:
>
> <dependency name="libX" rev="1.0" org="COTS" conf="compile,
> development, deployment">
> <artifact name="libX" conf="compile"/>
> <artifact name="LICENSE" type="license" ext="txt"
> conf="deployment"/>
> <artifact name="libX" type="source" ext="src.jar"
> conf="development"/>
> </dependency>
>
>
> and another module referencing same libX but in version 2.0 by way of:
>
> <dependency name="libX" rev="2.0" org="COTS" conf="compile,
> development, deployment">
> <artifact name="libX" conf="compile"/>
> <artifact name="libX" type="license" ext="jar.license"
> conf="deployment"/>
> <artifact name="libX" type="source" ext="src.jar"
> conf="development"/>
> </dependency>
>
>
> the eviction of libX-1.0 fails (note the different namings for the license
> artifact).
>
> I have a complete running example available - but as I read from previous
> mails, attachments are stripped. So I cannot provide it here but will
> attach
> it tomorrow to a new issue ... unless you believe my way of referencing
> libX
> being not correct ... ?
You can open the issue, your referencing is correct.
Xavier
Regards,
> Johannes Stamminger
>
>
>
>
> On Saturday 16 June 2007, Gilles Scokart wrote:
> > A priori, I would say that's a bug. You can raise a jira issue.
> > As a temprary workaround, you can try to put an empty jar in your
> > repository.
> >
> > Gilles
> >
> > 2007/6/15, Johannes Stamminger <Jo...@astrium.eads.net>:
> > > Hi,
> > >
> > >
> > > we just try to switch our dependencies management to use ivy (v1.4.1).
> > >
> > > Today we were faced with a problem with the default conflict
> management
> > > of artifacts provided by an evicted module.
> > >
> > > The situation as it presents to us seems to be like:
> > >
> > > moduleA-1.0 provides artifactA
> > > moduleA-2.0 provides artifactB (important: the artifact's name, not
> > > (only) it's version, changed)
> > >
> > > moduleB-1.0 depends on moduleA-1.0
> > >
> > > moduleC-1.0 depends on moduleA-2.0
> > > moduleC-1.0 depends on moduleB-1.0
> > >
> > > In that case there is a conflict and the default conflict manager
> > > resolution is to evict moduleA-1.0. But still it is tried to download
> > > artifactA - but from moduleA-2.0's directory ... and of course this
> > > fails.
> > >
> > > Is this expected bahaviour?
> > > Or do you expect some wrong definitions in our ivy configurations to
> > > cause this?
> > >
> > >
> > > Regards,
> > > Johannes Stamminger
> > > --
> > > Johannes.Stamminger@Astrium.EADS.net [2FE783D0
> http://wwwkeys.PGP.net]
> > > ------ ----<--{(@ ------------------ EADS
> ASTRIUM
> > > Koenigsberger Str. 17, 28857 Barrien Ground System Eng.
> (TE55)
> > > +49 4242 169582 (Tel + FAX) Huenefeldstr. 1-5, 28199
> Bremen
> > > +49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378
> (FAX)
> > >
> > > This email (including any attachments) may contain confidential and/or
> > > privileged information or information otherwise protected from
> > > disclosure. If you are not the intended recipient, please notify the
> > > sender immediately, do not copy this message or any attachments and do
> > > not use it for any purpose or disclose its content to any person, but
> > > delete this message and any attachments from your system. Astrium
> > > disclaims any and all liability if this email transmission was virus
> > > corrupted, altered or falsified.
> > > ---------------------------------------------------------
> > > Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller -
> > > Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz,
> Pablo
> > > Salame Fischer Sitz der Gesellschaft: Muenchen - Registergericht:
> > > Amtsgericht Muenchen, HRB Nr. 107 647
>
>
>
> --
> !!! NEU/NEW !!! vvvvvvv
> Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
> ------ ----<--{(@ ------------------ EADS ASTRIUM
> Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
> +49 4242 169582 (Tel + FAX) Huenefeldstr. 1-5, 28199 Bremen
> +49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
>
> This email (including any attachments) may contain confidential and/or
> privileged information or information otherwise protected from disclosure.
> If you are not the intended recipient, please notify the sender immediately,
> do not copy this message or any attachments and do not use it for any
> purpose or disclose its content to any person, but delete this message and
> any attachments from your system. Astrium disclaims any and all liability if
> this email transmission was virus corrupted, altered or falsified.
> ---------------------------------------------------------
> Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller -
> Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo
> Salame Fischer
> Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen,
> HRB Nr. 107 647
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
Re: artifacts of evicted module
Posted by Johannes Stamminger <Jo...@astrium.eads.net>.
Hi again!
Our workaround was so far to use the all-conflict manager instead.
Today I found the time to extract a sample configuration of our more complex
setup. And it revealed, that the problem is not with modules providing their
dependencies themselves by way of delivered ivy files. But with external libs
whose artifacts are referenced from a module's ivy file, there the problem
appears. With moduleA referencing libX-1.0 with:
<dependency name="libX" rev="1.0" org="COTS" conf="compile,
development, deployment">
<artifact name="libX" conf="compile"/>
<artifact name="LICENSE" type="license" ext="txt"
conf="deployment"/>
<artifact name="libX" type="source" ext="src.jar"
conf="development"/>
</dependency>
and another module referencing same libX but in version 2.0 by way of:
<dependency name="libX" rev="2.0" org="COTS" conf="compile,
development, deployment">
<artifact name="libX" conf="compile"/>
<artifact name="libX" type="license" ext="jar.license"
conf="deployment"/>
<artifact name="libX" type="source" ext="src.jar"
conf="development"/>
</dependency>
the eviction of libX-1.0 fails (note the different namings for the license
artifact).
I have a complete running example available - but as I read from previous
mails, attachments are stripped. So I cannot provide it here but will attach
it tomorrow to a new issue ... unless you believe my way of referencing libX
being not correct ... ?
Regards,
Johannes Stamminger
On Saturday 16 June 2007, Gilles Scokart wrote:
> A priori, I would say that's a bug. You can raise a jira issue.
> As a temprary workaround, you can try to put an empty jar in your
> repository.
>
> Gilles
>
> 2007/6/15, Johannes Stamminger <Jo...@astrium.eads.net>:
> > Hi,
> >
> >
> > we just try to switch our dependencies management to use ivy (v1.4.1).
> >
> > Today we were faced with a problem with the default conflict management
> > of artifacts provided by an evicted module.
> >
> > The situation as it presents to us seems to be like:
> >
> > moduleA-1.0 provides artifactA
> > moduleA-2.0 provides artifactB (important: the artifact's name, not
> > (only) it's version, changed)
> >
> > moduleB-1.0 depends on moduleA-1.0
> >
> > moduleC-1.0 depends on moduleA-2.0
> > moduleC-1.0 depends on moduleB-1.0
> >
> > In that case there is a conflict and the default conflict manager
> > resolution is to evict moduleA-1.0. But still it is tried to download
> > artifactA - but from moduleA-2.0's directory ... and of course this
> > fails.
> >
> > Is this expected bahaviour?
> > Or do you expect some wrong definitions in our ivy configurations to
> > cause this?
> >
> >
> > Regards,
> > Johannes Stamminger
> > --
> > Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
> > ------ ----<--{(@ ------------------ EADS ASTRIUM
> > Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
> > +49 4242 169582 (Tel + FAX) Huenefeldstr. 1-5, 28199 Bremen
> > +49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
> >
> > This email (including any attachments) may contain confidential and/or
> > privileged information or information otherwise protected from
> > disclosure. If you are not the intended recipient, please notify the
> > sender immediately, do not copy this message or any attachments and do
> > not use it for any purpose or disclose its content to any person, but
> > delete this message and any attachments from your system. Astrium
> > disclaims any and all liability if this email transmission was virus
> > corrupted, altered or falsified.
> > ---------------------------------------------------------
> > Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller -
> > Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo
> > Salame Fischer Sitz der Gesellschaft: Muenchen - Registergericht:
> > Amtsgericht Muenchen, HRB Nr. 107 647
--
!!! NEU/NEW !!! vvvvvvv
Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
------ ----<--{(@ ------------------ EADS ASTRIUM
Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
+49 4242 169582 (Tel + FAX) Huenefeldstr. 1-5, 28199 Bremen
+49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
---------------------------------------------------------
Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller - Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo Salame Fischer
Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen, HRB Nr. 107 647
Re: artifacts of evicted module
Posted by Gilles Scokart <gs...@gmail.com>.
A priori, I would say that's a bug. You can raise a jira issue.
As a temprary workaround, you can try to put an empty jar in your repository.
Gilles
2007/6/15, Johannes Stamminger <Jo...@astrium.eads.net>:
>
> Hi,
>
>
> we just try to switch our dependencies management to use ivy (v1.4.1).
>
> Today we were faced with a problem with the default conflict management of
> artifacts provided by an evicted module.
>
> The situation as it presents to us seems to be like:
>
> moduleA-1.0 provides artifactA
> moduleA-2.0 provides artifactB (important: the artifact's name, not (only)
> it's version, changed)
>
> moduleB-1.0 depends on moduleA-1.0
>
> moduleC-1.0 depends on moduleA-2.0
> moduleC-1.0 depends on moduleB-1.0
>
> In that case there is a conflict and the default conflict manager resolution
> is to evict moduleA-1.0. But still it is tried to download artifactA - but
> from moduleA-2.0's directory ... and of course this fails.
>
> Is this expected bahaviour?
> Or do you expect some wrong definitions in our ivy configurations to cause
> this?
>
>
> Regards,
> Johannes Stamminger
> --
> Johannes.Stamminger@Astrium.EADS.net [2FE783D0 http://wwwkeys.PGP.net]
> ------ ----<--{(@ ------------------ EADS ASTRIUM
> Koenigsberger Str. 17, 28857 Barrien Ground System Eng. (TE55)
> +49 4242 169582 (Tel + FAX) Huenefeldstr. 1-5, 28199 Bremen
> +49 174 7731593 (Mobile) +49 421 539 4152 (Tel) / 4378 (FAX)
>
> This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
> ---------------------------------------------------------
> Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller - Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo Salame Fischer
> Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen, HRB Nr. 107 647
>
--
Gilles SCOKART