[jira] [Resolved] (IVY-1587) Wrong POM translation for dependencies appearing more than once
[
https://issues.apache.org/jira/browse/IVY-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cédric Damioli resolved IVY-1587.
-
Fix Version/s: master
Resolution: Duplicate
> Wrong POM translation for dependencies appearing more than once
> ---
>
> Key: IVY-1587
> URL: https://issues.apache.org/jira/browse/IVY-1587
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc1
>Reporter: Cédric Damioli
>Priority: Major
> Fix For: master
>
>
> Using
>
> {code:java}
> java -jar ivy.jar -dependency "org.slf4j" "slf4j-log4j12" "1.7.25" -confs
> default -types jar
> {code}
> With Ivy 2.4.0, I get two artifacts : slf4j-api.jar and slf4j-log4j12.jar
> With Ivy 2.5.0RC1, I only get {color:#33}slf4j-log4j12.jar with no means
> to get the -api artifact {color}
>
> This seems to be related to the resolution of IVY-1576
>
> In the POM, the slf4j-api dependency is present twice, once for compile, once
> for tests.
> Before IVY-1576, it resulted in two different dependencies.
> With IVY-1576, there's only one dependency, offering only the test artifact.
>
> The fix was good for "merging" dependencies with classifiers, but in this
> case, the merge should not have occured
>
> I don't set this ticket as critical as there are workarounds, but it is at
> least very annoying
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1587) Wrong POM translation for dependencies appearing more than once
[
https://issues.apache.org/jira/browse/IVY-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936072#comment-16936072
]
Cédric Damioli commented on IVY-1587:
-
Fixed ! Sorry for the duplicate, I haven't seen IVY-1580
> Wrong POM translation for dependencies appearing more than once
> ---
>
> Key: IVY-1587
> URL: https://issues.apache.org/jira/browse/IVY-1587
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc1
>Reporter: Cédric Damioli
>Priority: Major
>
> Using
>
> {code:java}
> java -jar ivy.jar -dependency "org.slf4j" "slf4j-log4j12" "1.7.25" -confs
> default -types jar
> {code}
> With Ivy 2.4.0, I get two artifacts : slf4j-api.jar and slf4j-log4j12.jar
> With Ivy 2.5.0RC1, I only get {color:#33}slf4j-log4j12.jar with no means
> to get the -api artifact {color}
>
> This seems to be related to the resolution of IVY-1576
>
> In the POM, the slf4j-api dependency is present twice, once for compile, once
> for tests.
> Before IVY-1576, it resulted in two different dependencies.
> With IVY-1576, there's only one dependency, offering only the test artifact.
>
> The fix was good for "merging" dependencies with classifiers, but in this
> case, the merge should not have occured
>
> I don't set this ticket as critical as there are workarounds, but it is at
> least very annoying
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IVY-1587) Wrong POM translation for dependencies appearing more than once
[
https://issues.apache.org/jira/browse/IVY-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936043#comment-16936043
]
jaikiran pai edited comment on IVY-1587 at 9/23/19 5:10 PM:
Can you try this with our latest nightly build
[https://builds.apache.org/view/All/job/Ivy/lastSuccessfulBuild/artifact/build/.|https://builds.apache.org/view/All/job/Ivy/lastSuccessfulBuild/artifact/build/]
We fixed this recently as part of IVY-1580
When you try, do make sure to use a clean/fresh Ivy cache directory.
was (Author: jaikiran):
Can you try this with our latest nightly build
[https://builds.apache.org/view/All/job/Ivy/lastSuccessfulBuild/artifact/build/.|https://builds.apache.org/view/All/job/Ivy/lastSuccessfulBuild/artifact/build/]
We fixed this recently as part of IVY-1580
> Wrong POM translation for dependencies appearing more than once
> ---
>
> Key: IVY-1587
> URL: https://issues.apache.org/jira/browse/IVY-1587
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc1
>Reporter: Cédric Damioli
>Priority: Major
>
> Using
>
> {code:java}
> java -jar ivy.jar -dependency "org.slf4j" "slf4j-log4j12" "1.7.25" -confs
> default -types jar
> {code}
> With Ivy 2.4.0, I get two artifacts : slf4j-api.jar and slf4j-log4j12.jar
> With Ivy 2.5.0RC1, I only get {color:#33}slf4j-log4j12.jar with no means
> to get the -api artifact {color}
>
> This seems to be related to the resolution of IVY-1576
>
> In the POM, the slf4j-api dependency is present twice, once for compile, once
> for tests.
> Before IVY-1576, it resulted in two different dependencies.
> With IVY-1576, there's only one dependency, offering only the test artifact.
>
> The fix was good for "merging" dependencies with classifiers, but in this
> case, the merge should not have occured
>
> I don't set this ticket as critical as there are workarounds, but it is at
> least very annoying
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1587) Wrong POM translation for dependencies appearing more than once
[
https://issues.apache.org/jira/browse/IVY-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936043#comment-16936043
]
jaikiran pai commented on IVY-1587:
---
Can you try this with our latest nightly build
[https://builds.apache.org/view/All/job/Ivy/lastSuccessfulBuild/artifact/build/.|https://builds.apache.org/view/All/job/Ivy/lastSuccessfulBuild/artifact/build/]
We fixed this recently as part of IVY-1580
> Wrong POM translation for dependencies appearing more than once
> ---
>
> Key: IVY-1587
> URL: https://issues.apache.org/jira/browse/IVY-1587
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc1
>Reporter: Cédric Damioli
>Priority: Major
>
> Using
>
> {code:java}
> java -jar ivy.jar -dependency "org.slf4j" "slf4j-log4j12" "1.7.25" -confs
> default -types jar
> {code}
> With Ivy 2.4.0, I get two artifacts : slf4j-api.jar and slf4j-log4j12.jar
> With Ivy 2.5.0RC1, I only get {color:#33}slf4j-log4j12.jar with no means
> to get the -api artifact {color}
>
> This seems to be related to the resolution of IVY-1576
>
> In the POM, the slf4j-api dependency is present twice, once for compile, once
> for tests.
> Before IVY-1576, it resulted in two different dependencies.
> With IVY-1576, there's only one dependency, offering only the test artifact.
>
> The fix was good for "merging" dependencies with classifiers, but in this
> case, the merge should not have occured
>
> I don't set this ticket as critical as there are workarounds, but it is at
> least very annoying
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1587) Wrong POM translation for dependencies appearing more than once
[
https://issues.apache.org/jira/browse/IVY-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936039#comment-16936039
]
Cédric Damioli commented on IVY-1587:
-
Actually very interesting ...
The first time you play the command, you indeed retrieve the two jars. But if
after that, without emptying the cache, you immediately execute the same
command again, you only get one artifact!
> Wrong POM translation for dependencies appearing more than once
> ---
>
> Key: IVY-1587
> URL: https://issues.apache.org/jira/browse/IVY-1587
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc1
>Reporter: Cédric Damioli
>Priority: Major
>
> Using
>
> {code:java}
> java -jar ivy.jar -dependency "org.slf4j" "slf4j-log4j12" "1.7.25" -confs
> default -types jar
> {code}
> With Ivy 2.4.0, I get two artifacts : slf4j-api.jar and slf4j-log4j12.jar
> With Ivy 2.5.0RC1, I only get {color:#33}slf4j-log4j12.jar with no means
> to get the -api artifact {color}
>
> This seems to be related to the resolution of IVY-1576
>
> In the POM, the slf4j-api dependency is present twice, once for compile, once
> for tests.
> Before IVY-1576, it resulted in two different dependencies.
> With IVY-1576, there's only one dependency, offering only the test artifact.
>
> The fix was good for "merging" dependencies with classifiers, but in this
> case, the merge should not have occured
>
> I don't set this ticket as critical as there are workarounds, but it is at
> least very annoying
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IVY-1608) Ivy fails incorrectly with evicted modules with different confs
[ https://issues.apache.org/jira/browse/IVY-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cédric Damioli updated IVY-1608: Attachment: ivy-2.4.x.patch > Ivy fails incorrectly with evicted modules with different confs > --- > > Key: IVY-1608 > URL: https://issues.apache.org/jira/browse/IVY-1608 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.4.0, 2.5.0-rc1 >Reporter: Cédric Damioli >Priority: Major > Attachments: ivy-2.4.x.patch > > > When a module's revision with two confs A and B is evicted by another > revision with only conf A, the resolve engine fails complaining that conf B > is missing. > > Note that this description is strictly the same than the 11-years old > IVY-681, which has been promptly fixed but somehow broken in the meantime > (maybe while fixing IVY-861). > There is a test case supposed to handle this case > (ResolveTestCase#testEvictWithConf3), but for an unknown reason it always > succeed whereas it should not ! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IVY-1608) Ivy fails incorrectly with evicted modules with different confs
[ https://issues.apache.org/jira/browse/IVY-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936005#comment-16936005 ] Cédric Damioli commented on IVY-1608: - Attached in a test case to reproduce the issue. > Ivy fails incorrectly with evicted modules with different confs > --- > > Key: IVY-1608 > URL: https://issues.apache.org/jira/browse/IVY-1608 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.4.0, 2.5.0-rc1 >Reporter: Cédric Damioli >Priority: Major > Attachments: ivy-2.4.x.patch > > > When a module's revision with two confs A and B is evicted by another > revision with only conf A, the resolve engine fails complaining that conf B > is missing. > > Note that this description is strictly the same than the 11-years old > IVY-681, which has been promptly fixed but somehow broken in the meantime > (maybe while fixing IVY-861). > There is a test case supposed to handle this case > (ResolveTestCase#testEvictWithConf3), but for an unknown reason it always > succeed whereas it should not ! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IVY-1608) Ivy fails incorrectly with evicted modules with different confs
[ https://issues.apache.org/jira/browse/IVY-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cédric Damioli updated IVY-1608: Flags: Patch > Ivy fails incorrectly with evicted modules with different confs > --- > > Key: IVY-1608 > URL: https://issues.apache.org/jira/browse/IVY-1608 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.4.0, 2.5.0-rc1 >Reporter: Cédric Damioli >Priority: Major > Attachments: ivy-2.4.x.patch > > > When a module's revision with two confs A and B is evicted by another > revision with only conf A, the resolve engine fails complaining that conf B > is missing. > > Note that this description is strictly the same than the 11-years old > IVY-681, which has been promptly fixed but somehow broken in the meantime > (maybe while fixing IVY-861). > There is a test case supposed to handle this case > (ResolveTestCase#testEvictWithConf3), but for an unknown reason it always > succeed whereas it should not ! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IVY-1608) Ivy fails incorrectly with evicted modules with different confs
Cédric Damioli created IVY-1608: --- Summary: Ivy fails incorrectly with evicted modules with different confs Key: IVY-1608 URL: https://issues.apache.org/jira/browse/IVY-1608 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.5.0-rc1, 2.4.0 Reporter: Cédric Damioli When a module's revision with two confs A and B is evicted by another revision with only conf A, the resolve engine fails complaining that conf B is missing. Note that this description is strictly the same than the 11-years old IVY-681, which has been promptly fixed but somehow broken in the meantime (maybe while fixing IVY-861). There is a test case supposed to handle this case (ResolveTestCase#testEvictWithConf3), but for an unknown reason it always succeed whereas it should not ! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IVY-1586) Retrieves test-library instead of binary-library
[
https://issues.apache.org/jira/browse/IVY-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Götz updated IVY-1586:
Comment: was deleted
(was: Jaikiran, I still have trouble with this issue. I just grabbed the
nightly build and made a short test in our productive build environment. The
retrieve still fails with the following error:
{code:java}
...
[ivy:configure] :: Apache Ivy 2.5.0-rc2-local-20190921121652 - 20190921121652
:: https://ant.apache.org/ivy/ ::
...
BUILD FAILED
D:\jenkins\jobs\isac3-web (any 11)\workspace\build-common.xml:284: impossible
to ivy retrieve: java.lang.RuntimeException: problem during retrieve of
eu.inform#isac3-web: java.lang.RuntimeException: Multiple artifacts of the
module org.opensaml#opensaml-saml-api;3.1.1 are retrieved to the same file!
Update the retrieve pattern to fix this error.
at
org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:238)
at org.apache.ivy.Ivy.retrieve(Ivy.java:561)
at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:113)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:259)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:448)
at org.apache.tools.ant.Target.performTasks(Target.java:469)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1370)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
at org.apache.tools.ant.Main.runBuild(Main.java:849)
at org.apache.tools.ant.Main.startAnt(Main.java:228)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:283)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)
Caused by: java.lang.RuntimeException: Multiple artifacts of the module
org.opensaml#opensaml-saml-api;3.1.1 are retrieved to the same file! Update the
retrieve pattern to fix this error.
at
org.apache.ivy.core.retrieve.RetrieveEngine.determineArtifactsToCopy(RetrieveEngine.java:413)
at
org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:122)
... 19 more
{code}
How must I change the retrieve pattern to achive a correct dependency
resolution?
)
> Retrieves test-library instead of binary-library
>
>
> Key: IVY-1586
> URL: https://issues.apache.org/jira/browse/IVY-1586
> Project: Ivy
> Issue Type: Bug
> Components: Ant
>Affects Versions: 2.5.0-rc1
> Environment: Eclipse Photon 4.8.0 64bit
> Ant 1.10.3.v20180417-1627
> Apache IvyDE 2.2.0.final-201311091524-RELEASE
> Apache Ivy 2.5.0.cr1_20180412005306
>Reporter: Arni Schulze
>Assignee: jaikiran pai
>Priority: Blocker
> Fix For: master
>
> Attachments: Ant_1st_output.txt, Ant_2nd_output.txt, build.xml,
> ivy.xml
>
>
> If I delete the local Ivy cache and run my Ant script to retrieve
> "ch.quos.logback logback-classic 1.2.3" I get the correct library and its
> dependencies (see Ant_1st_output).
> But if I run the Ant script again (now having a local Ivy cache) it retrieves
> the test-library and the test-library of the dependencies instead of the
> correct ones (see Ant_2nd_output).
> I added minimalistic ivy.xml and Ant script. Because of the different
> behavior of the first and every other run, I think this is a bug in Ivy.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1586) Retrieves test-library instead of binary-library
[
https://issues.apache.org/jira/browse/IVY-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935824#comment-16935824
]
Sebastian Götz commented on IVY-1586:
-
Jaikiran, I still have trouble with this issue. I just grabbed the nightly
build and made a short test in our productive build environment. The retrieve
still fails with the following error:
{code:java}
...
[ivy:configure] :: Apache Ivy 2.5.0-rc2-local-20190921121652 - 20190921121652
:: https://ant.apache.org/ivy/ ::
...
BUILD FAILED
D:\jenkins\jobs\isac3-web (any 11)\workspace\build-common.xml:284: impossible
to ivy retrieve: java.lang.RuntimeException: problem during retrieve of
eu.inform#isac3-web: java.lang.RuntimeException: Multiple artifacts of the
module org.opensaml#opensaml-saml-api;3.1.1 are retrieved to the same file!
Update the retrieve pattern to fix this error.
at
org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:238)
at org.apache.ivy.Ivy.retrieve(Ivy.java:561)
at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:113)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:259)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:350)
at org.apache.tools.ant.Target.execute(Target.java:448)
at org.apache.tools.ant.Target.performTasks(Target.java:469)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1370)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
at org.apache.tools.ant.Main.runBuild(Main.java:849)
at org.apache.tools.ant.Main.startAnt(Main.java:228)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:283)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)
Caused by: java.lang.RuntimeException: Multiple artifacts of the module
org.opensaml#opensaml-saml-api;3.1.1 are retrieved to the same file! Update the
retrieve pattern to fix this error.
at
org.apache.ivy.core.retrieve.RetrieveEngine.determineArtifactsToCopy(RetrieveEngine.java:413)
at
org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:122)
... 19 more
{code}
How must I change the retrieve pattern to achive a correct dependency
resolution?
> Retrieves test-library instead of binary-library
>
>
> Key: IVY-1586
> URL: https://issues.apache.org/jira/browse/IVY-1586
> Project: Ivy
> Issue Type: Bug
> Components: Ant
>Affects Versions: 2.5.0-rc1
> Environment: Eclipse Photon 4.8.0 64bit
> Ant 1.10.3.v20180417-1627
> Apache IvyDE 2.2.0.final-201311091524-RELEASE
> Apache Ivy 2.5.0.cr1_20180412005306
>Reporter: Arni Schulze
>Assignee: jaikiran pai
>Priority: Blocker
> Fix For: master
>
> Attachments: Ant_1st_output.txt, Ant_2nd_output.txt, build.xml,
> ivy.xml
>
>
> If I delete the local Ivy cache and run my Ant script to retrieve
> "ch.quos.logback logback-classic 1.2.3" I get the correct library and its
> dependencies (see Ant_1st_output).
> But if I run the Ant script again (now having a local Ivy cache) it retrieves
> the test-library and the test-library of the dependencies instead of the
> correct ones (see Ant_2nd_output).
> I added minimalistic ivy.xml and Ant script. Because of the different
> behavior of the first and every other run, I think this is a bug in Ivy.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
