[jira] [Commented] (IVY-1605) Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"
[
https://issues.apache.org/jira/browse/IVY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980242#comment-16980242
]
Eric Milles commented on IVY-1605:
--
Circular dependency is not the issue we are seeing. We get cache in some kind
of bad state followed by failure to resolve dependencies. Removing cache
directories for the failed artifacts has been the only resolution.
> Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"
>
>
> Key: IVY-1605
> URL: https://issues.apache.org/jira/browse/IVY-1605
> Project: Ivy
> Issue Type: Bug
> Components: Core, Maven Compatibility
>Affects Versions: 2.5.0-rc1
> Environment: OS: Windows 10
> Java : Java 1.8
> Apache Ant(TM) version 1.9.14 compiled on March 12 2019
> Apache Ivy 2.5.0-rc1 - 20180412005306
>Reporter: Janusz Dalecki
>Priority: Major
>
> Hi,
> I am reprting this as a bug as I have published the problem on ivy forum and
> I was asked to submit it as a possible problem in ivy.
> It is reproducible as I desribe it below:
>
> I have an ivy.xml file that includes just one dependency like this:
> {code:java}
> rev="2.28"/>
> {code}
> My ivysettings.xml looks like this:
> {code:java}
>
>
>
>
>
>
> pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
>
>
>
>
>
>
> {code}
> After I run the build.xml (below is my resolve statement extract from
> build.xml that looks like this):
> {code:java}
>
>
>
> pattern="${ivy.lib.dir}/[conf]/[artifact]-[type]-[revision].[ext]"/>
>
> {code}
> ... I get this error:
> {code:java}
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve] WARNINGS
> [ivy:retrieve] ::
> [ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:retrieve] ::
> [ivy:retrieve] :: org.glassfish.jersey.media#jersey-media-multipart;2.28:
> org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5
> [ivy:retrieve] ::
> [ivy:retrieve]
> [ivy:retrieve]
> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> {code}
> I have checked that in the central repository there is a pom.xml in
> https://repo1.maven.org/maven2/org/eclipse/ee4j/project/1.0.5/ repository
> called project-1.0.5.pom .
> Kind Regards,
> Janusz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1616) useOrigin="true" fails with file-based ibiblio
[
https://issues.apache.org/jira/browse/IVY-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980241#comment-16980241
]
Eric Milles commented on IVY-1616:
--
Yes, I've cleared both Ivy and Maven caches and started fresh.
> useOrigin="true" fails with file-based ibiblio
> --
>
> Key: IVY-1616
> URL: https://issues.apache.org/jira/browse/IVY-1616
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Eric Milles
>Assignee: Jaikiran Pai
>Priority: Major
>
> We are trying to use Maven's artifacts if they have already been downloaded.
> To that end, we have a file-based {{ibiblio}} resolver that points to the
> local .m2 repository directory. If maven is used to download an artifact so
> that it is in .m2 and not in Ivy's cache, we are getting errors from the
> origin check in {{DefaultRepositoryCacheManager}}.
> {code}
> java.lang.IllegalArgumentException:
> org.apache.maven.shared#maven-shared-utils;3.2.1!maven-shared-utils.jar
> origin location must be absolute:
> file:/C:/Users/Name/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.2.1/maven-shared-utils-3.2.1.jar
> at org.apache.ivy.util.Checks.checkAbsolute(Checks.java:57)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getArchiveFileInCache(DefaultRepositoryCacheManager.java:410)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.download(DefaultRepositoryCacheManager.java:996)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.download(BasicResolver.java:836)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.download(RepositoryResolver.java:305)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.download(IBiblioResolver.java:563)
> at
> org.apache.ivy.core.resolve.ResolveEngine.downloadArtifacts(ResolveEngine.java:405)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:351)
> at org.apache.ivy.Ivy.resolve(Ivy.java:522)
> {code}
> {code:xml}
>
>
>
>
>checkmodified="true" changingPattern=".*" changingMatcher="regexp"
> m2compatible="true"/>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1605) Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"
[
https://issues.apache.org/jira/browse/IVY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16979615#comment-16979615
]
Eric Milles commented on IVY-1605:
--
[~rejkid] Can you say what is in your Ivy cache for
{{org.eclipse.ee4j#project}}? It should be at
~/.ivy2/cache/org.eclipse.ee4j/project/
We have been chasing a cache corruption problem that results in unresolved
dependency issues. I'm wondering if your cache has the same issue.
> Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"
>
>
> Key: IVY-1605
> URL: https://issues.apache.org/jira/browse/IVY-1605
> Project: Ivy
> Issue Type: Bug
> Components: Core, Maven Compatibility
>Affects Versions: 2.5.0-rc1
> Environment: OS: Windows 10
> Java : Java 1.8
> Apache Ant(TM) version 1.9.14 compiled on March 12 2019
> Apache Ivy 2.5.0-rc1 - 20180412005306
>Reporter: Janusz Dalecki
>Priority: Major
>
> Hi,
> I am reprting this as a bug as I have published the problem on ivy forum and
> I was asked to submit it as a possible problem in ivy.
> It is reproducible as I desribe it below:
>
> I have an ivy.xml file that includes just one dependency like this:
> {code:java}
> rev="2.28"/>
> {code}
> My ivysettings.xml looks like this:
> {code:java}
>
>
>
>
>
>
> pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
>
>
>
>
>
>
> {code}
> After I run the build.xml (below is my resolve statement extract from
> build.xml that looks like this):
> {code:java}
>
>
>
> pattern="${ivy.lib.dir}/[conf]/[artifact]-[type]-[revision].[ext]"/>
>
> {code}
> ... I get this error:
> {code:java}
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve] WARNINGS
> [ivy:retrieve] ::
> [ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:retrieve] ::
> [ivy:retrieve] :: org.glassfish.jersey.media#jersey-media-multipart;2.28:
> org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5
> [ivy:retrieve] ::
> [ivy:retrieve]
> [ivy:retrieve]
> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> {code}
> I have checked that in the central repository there is a pom.xml in
> https://repo1.maven.org/maven2/org/eclipse/ee4j/project/1.0.5/ repository
> called project-1.0.5.pom .
> Kind Regards,
> Janusz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IVY-1616) useOrigin="true" fails with file-based ibiblio
[
https://issues.apache.org/jira/browse/IVY-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated IVY-1616:
-
Description:
We are trying to use Maven's artifacts if they have already been downloaded.
To that end, we have a file-based {{ibiblio}} resolver that points to the local
.m2 repository directory. If maven is used to download an artifact so that it
is in .m2 and not in Ivy's cache, we are getting errors from the origin check
in {{DefaultRepositoryCacheManager}}.
{code}
java.lang.IllegalArgumentException:
org.apache.maven.shared#maven-shared-utils;3.2.1!maven-shared-utils.jar origin
location must be absolute:
file:/C:/Users/Name/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.2.1/maven-shared-utils-3.2.1.jar
at org.apache.ivy.util.Checks.checkAbsolute(Checks.java:57)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getArchiveFileInCache(DefaultRepositoryCacheManager.java:410)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.download(DefaultRepositoryCacheManager.java:996)
at
org.apache.ivy.plugins.resolver.BasicResolver.download(BasicResolver.java:836)
at
org.apache.ivy.plugins.resolver.RepositoryResolver.download(RepositoryResolver.java:305)
at
org.apache.ivy.plugins.resolver.IBiblioResolver.download(IBiblioResolver.java:563)
at
org.apache.ivy.core.resolve.ResolveEngine.downloadArtifacts(ResolveEngine.java:405)
at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:351)
at org.apache.ivy.Ivy.resolve(Ivy.java:522)
{code}
{code:xml}
{code}
was:
We are trying to use Maven's artifacts if they have already been downloaded.
To that end, we have a file-based {{ibiblio}} resolver that points to the local
.m2 repository directory. If maven is used to download an artifact so that it
is in .m2 and not in Ivy's cache, we are getting errors from the origin check
in {{DefaultRepositoryCacheManager}}.
{code}
java.lang.IllegalArgumentException:
org.apache.maven.shared#maven-shared-utils;3.2.1!maven-shared-utils.jar origin
location must be absolute: file:/C:/Users/Name/.m2/repository/org/apache/mav
en/shared/maven-shared-utils/3.2.1/maven-shared-utils-3.2.1.jar
at org.apache.ivy.util.Checks.checkAbsolute(Checks.java:57)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getArchiveFileInCache(DefaultRepositoryCacheManager.java:410)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.download(DefaultRepositoryCacheManager.java:996)
at
org.apache.ivy.plugins.resolver.BasicResolver.download(BasicResolver.java:836)
at
org.apache.ivy.plugins.resolver.RepositoryResolver.download(RepositoryResolver.java:305)
at
org.apache.ivy.plugins.resolver.IBiblioResolver.download(IBiblioResolver.java:563)
at
org.apache.ivy.core.resolve.ResolveEngine.downloadArtifacts(ResolveEngine.java:405)
at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:351)
at org.apache.ivy.Ivy.resolve(Ivy.java:522)
{code}
{code:xml}
{code}
> useOrigin="true" fails with file-based ibiblio
> --
>
> Key: IVY-1616
> URL: https://issues.apache.org/jira/browse/IVY-1616
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Eric Milles
>Priority: Major
>
> We are trying to use Maven's artifacts if they have already been downloaded.
> To that end, we have a file-based {{ibiblio}} resolver that points to the
> local .m2 repository directory. If maven is used to download an artifact so
> that it is in .m2 and not in Ivy's cache, we are getting errors from the
> origin check in {{DefaultRepositoryCacheManager}}.
> {code}
> java.lang.IllegalArgumentException:
> org.apache.maven.shared#maven-shared-utils;3.2.1!maven-shared-utils.jar
> origin location must be absolute:
> file:/C:/Users/Name/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.2.1/maven-shared-utils-3.2.1.jar
> at org.apache.ivy.util.Checks.checkAbsolute(Checks.java:57)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getArchiveFileInCache(DefaultRepositoryCacheManager.java:410)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.download(DefaultRepositoryCacheManager.java:996)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.download(BasicResolver.java:836)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.download(RepositoryResolver.java:305)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.download(IBiblioResolver.java:563)
> at
> org.apache.ivy.core.resolve.ResolveEngine.downloadArtifacts(ResolveEngine.java:405)
>
[jira] [Updated] (IVY-1616) useOrigin="true" fails with file-based ibiblio
[
https://issues.apache.org/jira/browse/IVY-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated IVY-1616:
-
Description:
We are trying to use Maven's artifacts if they have already been downloaded.
To that end, we have a file-based {{ibiblio}} resolver that points to the local
.m2 repository directory. If maven is used to download an artifact so that it
is in .m2 and not in Ivy's cache, we are getting errors from the origin check
in {{DefaultRepositoryCacheManager}}.
{code}
java.lang.IllegalArgumentException:
org.apache.maven.shared#maven-shared-utils;3.2.1!maven-shared-utils.jar origin
location must be absolute: file:/C:/Users/Name/.m2/repository/org/apache/mav
en/shared/maven-shared-utils/3.2.1/maven-shared-utils-3.2.1.jar
at org.apache.ivy.util.Checks.checkAbsolute(Checks.java:57)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getArchiveFileInCache(DefaultRepositoryCacheManager.java:410)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.download(DefaultRepositoryCacheManager.java:996)
at
org.apache.ivy.plugins.resolver.BasicResolver.download(BasicResolver.java:836)
at
org.apache.ivy.plugins.resolver.RepositoryResolver.download(RepositoryResolver.java:305)
at
org.apache.ivy.plugins.resolver.IBiblioResolver.download(IBiblioResolver.java:563)
at
org.apache.ivy.core.resolve.ResolveEngine.downloadArtifacts(ResolveEngine.java:405)
at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:351)
at org.apache.ivy.Ivy.resolve(Ivy.java:522)
{code}
{code:xml}
{code}
was:
We are trying to use Maven's artifacts if they have already been downloaded.
To that end, we have a file-based {{ibiblio}} resolver that points to the local
.m2 repository directory. We are getting errors from the origin check in
{{DefaultRepositoryCacheManager}}.
{code}
java.lang.IllegalArgumentException:
org.apache.maven.shared#maven-shared-utils;3.2.1!maven-shared-utils.jar origin
location must be absolute: file:/C:/Users/Name/.m2/repository/org/apache/mav
en/shared/maven-shared-utils/3.2.1/maven-shared-utils-3.2.1.jar
at org.apache.ivy.util.Checks.checkAbsolute(Checks.java:57)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getArchiveFileInCache(DefaultRepositoryCacheManager.java:410)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.download(DefaultRepositoryCacheManager.java:996)
at
org.apache.ivy.plugins.resolver.BasicResolver.download(BasicResolver.java:836)
at
org.apache.ivy.plugins.resolver.RepositoryResolver.download(RepositoryResolver.java:305)
at
org.apache.ivy.plugins.resolver.IBiblioResolver.download(IBiblioResolver.java:563)
at
org.apache.ivy.core.resolve.ResolveEngine.downloadArtifacts(ResolveEngine.java:405)
at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:351)
at org.apache.ivy.Ivy.resolve(Ivy.java:522)
{code}
{code:xml}
{code}
> useOrigin="true" fails with file-based ibiblio
> --
>
> Key: IVY-1616
> URL: https://issues.apache.org/jira/browse/IVY-1616
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Eric Milles
>Priority: Major
>
> We are trying to use Maven's artifacts if they have already been downloaded.
> To that end, we have a file-based {{ibiblio}} resolver that points to the
> local .m2 repository directory. If maven is used to download an artifact so
> that it is in .m2 and not in Ivy's cache, we are getting errors from the
> origin check in {{DefaultRepositoryCacheManager}}.
> {code}
> java.lang.IllegalArgumentException:
> org.apache.maven.shared#maven-shared-utils;3.2.1!maven-shared-utils.jar
> origin location must be absolute:
> file:/C:/Users/Name/.m2/repository/org/apache/mav
> en/shared/maven-shared-utils/3.2.1/maven-shared-utils-3.2.1.jar
> at org.apache.ivy.util.Checks.checkAbsolute(Checks.java:57)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getArchiveFileInCache(DefaultRepositoryCacheManager.java:410)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.download(DefaultRepositoryCacheManager.java:996)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.download(BasicResolver.java:836)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.download(RepositoryResolver.java:305)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.download(IBiblioResolver.java:563)
> at
> org.apache.ivy.core.resolve.ResolveEngine.downloadArtifacts(ResolveEngine.java:405)
> at
>
[jira] [Created] (IVY-1616) useOrigin="true" fails with file-based ibiblio
Eric Milles created IVY-1616:
Summary: useOrigin="true" fails with file-based ibiblio
Key: IVY-1616
URL: https://issues.apache.org/jira/browse/IVY-1616
Project: Ivy
Issue Type: Bug
Affects Versions: 2.5.0
Reporter: Eric Milles
We are trying to use Maven's artifacts if they have already been downloaded.
To that end, we have a file-based {{ibiblio}} resolver that points to the local
.m2 repository directory. We are getting errors from the origin check in
{{DefaultRepositoryCacheManager}}.
{code}
java.lang.IllegalArgumentException:
org.apache.maven.shared#maven-shared-utils;3.2.1!maven-shared-utils.jar origin
location must be absolute: file:/C:/Users/Name/.m2/repository/org/apache/mav
en/shared/maven-shared-utils/3.2.1/maven-shared-utils-3.2.1.jar
at org.apache.ivy.util.Checks.checkAbsolute(Checks.java:57)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getArchiveFileInCache(DefaultRepositoryCacheManager.java:410)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.download(DefaultRepositoryCacheManager.java:996)
at
org.apache.ivy.plugins.resolver.BasicResolver.download(BasicResolver.java:836)
at
org.apache.ivy.plugins.resolver.RepositoryResolver.download(RepositoryResolver.java:305)
at
org.apache.ivy.plugins.resolver.IBiblioResolver.download(IBiblioResolver.java:563)
at
org.apache.ivy.core.resolve.ResolveEngine.downloadArtifacts(ResolveEngine.java:405)
at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:351)
at org.apache.ivy.Ivy.resolve(Ivy.java:522)
{code}
{code:xml}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (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=16793821#comment-16793821
]
Eric Milles edited comment on IVY-1586 at 3/15/19 5:52 PM:
---
Same issue for
com.ibm.watson.developer_cloud:natural-language-understanding:6.0.0. The POM
references the core library twice:
{code:xml}
com.ibm.watson.developer_cloud
core
6.0.0
compile
com.ibm.watson.developer_cloud
core
6.0.0
tests
test
{code}
And Ivy is translating to this single dependency element. The artifact element
has blank conf instead of having two artifact elements, one in master or
compile conf with no classifier and one in test conf with classifier tests.
{code:xml}
{code}
So the core dependency is only retrieved using the "tests" classifier.
was (Author: emilles):
Same issue for
com.ibm.watson.developer_cloud:natural-language-understanding:6.0.0. The POM
references the core library twice:
{code:xml}
com.ibm.watson.developer_cloud
core
6.0.0
compile
com.ibm.watson.developer_cloud
core
6.0.0
tests
test
{code}
And Ivy is translating to this single dependency element:
{code:xml}
{code}
So the core dependency is only retrieved using the "tests" classifier.
> 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
>Priority: Blocker
> 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
(v7.6.3#76005)
[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=16793821#comment-16793821
]
Eric Milles commented on IVY-1586:
--
Same issue for
com.ibm.watson.developer_cloud:natural-language-understanding:6.0.0. The POM
references the core library twice:
{code:xml}
com.ibm.watson.developer_cloud
core
6.0.0
compile
com.ibm.watson.developer_cloud
core
6.0.0
tests
test
{code}
And Ivy is translating to this single dependency element:
{code:xml}
{code}
So the core dependency is only retrieved using the "tests" classifier.
> 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
>Priority: Blocker
> 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
(v7.6.3#76005)
[jira] [Created] (IVY-1531) Translation of POM to Ivy XML with * exclusion is removing main artifact
Eric Milles created IVY-1531: Summary: Translation of POM to Ivy XML with * exclusion is removing main artifact Key: IVY-1531 URL: https://issues.apache.org/jira/browse/IVY-1531 Project: Ivy Issue Type: Bug Components: Maven Compatibility Affects Versions: 2.4.0 Reporter: Eric Milles Using the change from issue 1470 (makepom with transitive=false dependency) we get a POM file with * for group and artifact exclusion. This may also occur naturally in POMs, but the main case for us is a library with transitive=false on a dependency. Ex: dependency groupIdorg.owasp.esapi/groupId artifactIdesapi/artifactId version2.1.0/version exclusions exclusion groupId*/groupId artifactId*/artifactId /exclusion /exclusions /dependency When we are consuming this library as a dependency out of Nexus, Ivy translates the above into: dependency org=org.owasp.esapi name=esapi rev=2.1.0 force=true conf=compile-compile(*),master(*);runtime-runtime(*) exclude org=* module=* name=* type=* ext=* conf= matcher=exact/ /dependency This is having the effect of excluding all artifacts, including the master jar. We are expecting to get the master jar, its sources and javadocs if they exist but no transitive dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IVY-1520) Have makepom task take description from ivy-module info description element
Eric Milles created IVY-1520: Summary: Have makepom task take description from ivy-module info description element Key: IVY-1520 URL: https://issues.apache.org/jira/browse/IVY-1520 Project: Ivy Issue Type: Improvement Components: Ant Affects Versions: 2.4.0 Reporter: Eric Milles Priority: Minor I've been exploring the Ant ivy:makepom task in more detail and found that I can transfer the module, organisation and homepage from the original Ivy file but not the description. The docs for makepom say that I can set property ivy.pom.description or use a description element. But using either of these does not present me with a straightforward means of transferring the description from the resolved Ivy file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IVY-1516) Module that uses extends is not picking up exclude element(s) from patent's dependencies definition
Eric Milles created IVY-1516: Summary: Module that uses extends is not picking up exclude element(s) from patent's dependencies definition Key: IVY-1516 URL: https://issues.apache.org/jira/browse/IVY-1516 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.4.0 Environment: Ivy 2.4.0, Ant 1.9.4 Reporter: Eric Milles I have a base project that defines a number of configurations and dependencies, including a few exclude elements to prevent conflicting dependencies from coming in transitively. In a child module, the configurations and dependencies are being inherited properly, but the excludes no longer take effect. ivy-module info module=A organisation=com.org / configurations conf name=local visibility=private description=Artifacts necessary for local development and testing / conf name=master / /configurations dependencies defaultconf=master defaultconfmapping=*-master,runtime() dependency org=log4j name=log4j rev=1.2.17 / dependency org=org.slf4j name=slf4j-api rev=1.7.10 / dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 / dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 / !-- ensure logging flows through the chosen 4 by excluding potential interlopers -- exclude conf=local matcher=regexp org=.*(commons-logging|logback|log4j|slf4j) / exclude conf=master matcher=regexp module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* / /dependencies /ivy-module ivy-module info module=B organisation=com.org extends module=A organisation=com.org extendType=configurations,dependencies location=../A/ivy.xml revision=latest / dependencies defaultconf=master defaultconfmapping=*-master,runtime() dependency ... conf=local /!-- this dependency includes log4j transitively and the exclude from module A should stop that from coming in -- /dependencies /info -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IVY-1516) Module that extends is not picking up exclude element(s) from parent's dependencies
[
https://issues.apache.org/jira/browse/IVY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated IVY-1516:
-
Environment: Ivy 2.4.0, IvyDE 2.2.0.final, Ant 1.9.4 (was: Ivy 2.4.0, Ant
1.9.4)
Module that extends is not picking up exclude element(s) from parent's
dependencies
---
Key: IVY-1516
URL: https://issues.apache.org/jira/browse/IVY-1516
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.4.0
Environment: Ivy 2.4.0, IvyDE 2.2.0.final, Ant 1.9.4
Reporter: Eric Milles
I have a base project that defines a number of configurations and
dependencies, including a few exclude elements to prevent conflicting
dependencies from coming in transitively. In a child module, the
configurations and dependencies are being inherited properly, but the
excludes no longer take effect.
{noformat}
ivy-module version=2.0
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ant.apache.org/ivy/schemas/ivy.xsd;
info module=A organisation=com.org /
configurations
conf name=local visibility=private
description=Artifacts necessary for local development and testing /
conf name=master /
/configurations
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency org=log4j name=log4j rev=1.2.17 /
dependency org=org.slf4j name=slf4j-api rev=1.7.10 /
dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 /
dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 /
!-- ensure logging flows through the chosen 4 by excluding potential
interlopers --
exclude conf=local matcher=regexp
org=.*(commons-logging|logback|log4j|slf4j) /
exclude conf=master matcher=regexp
module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* /
/dependencies
/ivy-module
ivy-module version=2.0
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ant.apache.org/ivy/schemas/ivy.xsd;
info module=B organisation=com.org
extends module=A organisation=com.org
extendType=configurations,dependencies location=../A/ivy.xml
revision=latest /
dependencies defaultconf=master
defaultconfmapping=*-master,runtime()
dependency ... conf=local /!-- this dependency includes
commons-logging transitively and the exclude from module A should stop that
from coming in so that jcl-over-slf4j is used instead --
/dependencies
/info
/ivy-module
{noformat}
Also, if the dependency here defined in B was moved up to A, the exclude
properly removes commons-logging from A's libraries. But commons-logging
will appear in B's libraries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IVY-1516) Module that extends is not picking up exclude element(s) from parent's dependencies
[
https://issues.apache.org/jira/browse/IVY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated IVY-1516:
-
Description:
I have a base project that defines a number of configurations and dependencies,
including a few exclude elements to prevent conflicting dependencies from
coming in transitively. In a child module, the configurations and dependencies
are being inherited properly, but the excludes no longer take effect.
{noformat}
ivy-module version=2.0
info module=A organisation=com.org /
configurations
conf name=local visibility=private
description=Artifacts necessary for local development and testing /
conf name=master /
/configurations
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency org=log4j name=log4j rev=1.2.17 /
dependency org=org.slf4j name=slf4j-api rev=1.7.10 /
dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 /
dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 /
!-- ensure logging flows through the chosen 4 by excluding potential
interlopers --
exclude conf=local matcher=regexp
org=.*(commons-logging|logback|log4j|slf4j) /
exclude conf=master matcher=regexp
module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* /
/dependencies
/ivy-module
ivy-module version=2.0
info module=B organisation=com.org
extends module=A organisation=com.org
extendType=configurations,dependencies location=../A/ivy.xml
revision=latest /
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency ... conf=local /!-- this dependency includes
commons-logging transitively and the exclude from module A should stop that
from coming in so that jcl-over-slf4j is used instead --
/dependencies
/info
/ivy-module
{noformat}
was:
I have a base project that defines a number of configurations and dependencies,
including a few exclude elements to prevent conflicting dependencies from
coming in transitively. In a child module, the configurations and dependencies
are being inherited properly, but the excludes no longer take effect.
ivy-module
info module=A organisation=com.org /
configurations
conf name=local visibility=private
description=Artifacts necessary for local development and testing /
conf name=master /
/configurations
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency org=log4j name=log4j rev=1.2.17 /
dependency org=org.slf4j name=slf4j-api rev=1.7.10 /
dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 /
dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 /
!-- ensure logging flows through the chosen 4 by excluding potential
interlopers --
exclude conf=local matcher=regexp
org=.*(commons-logging|logback|log4j|slf4j) /
exclude conf=master matcher=regexp
module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* /
/dependencies
/ivy-module
ivy-module
info module=B organisation=com.org
extends module=A organisation=com.org
extendType=configurations,dependencies location=../A/ivy.xml
revision=latest /
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency ... conf=local /!-- this dependency includes
commons-logging transitively and the exclude from module A should stop that
from coming in so that jcl-over-slf4j is used instead --
/dependencies
/info
Module that extends is not picking up exclude element(s) from parent's
dependencies
---
Key: IVY-1516
URL: https://issues.apache.org/jira/browse/IVY-1516
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.4.0
Environment: Ivy 2.4.0, Ant 1.9.4
Reporter: Eric Milles
I have a base project that defines a number of configurations and
dependencies, including a few exclude elements to prevent conflicting
dependencies from coming in transitively. In a child module, the
configurations and dependencies are being inherited properly, but the
excludes no longer take effect.
{noformat}
ivy-module version=2.0
info module=A organisation=com.org /
configurations
conf name=local visibility=private
description=Artifacts necessary for local development and testing /
conf name=master /
/configurations
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency org=log4j name=log4j rev=1.2.17 /
dependency org=org.slf4j name=slf4j-api rev=1.7.10 /
dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 /
dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 /
!-- ensure logging flows through the chosen 4 by excluding potential
[jira] [Updated] (IVY-1516) Module that extends is not picking up exclude element(s) from parent's dependencies
[ https://issues.apache.org/jira/browse/IVY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Milles updated IVY-1516: - Summary: Module that extends is not picking up exclude element(s) from parent's dependencies (was: Module that uses extends is not picking up exclude element(s) from patent's dependencies definition) Module that extends is not picking up exclude element(s) from parent's dependencies --- Key: IVY-1516 URL: https://issues.apache.org/jira/browse/IVY-1516 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.4.0 Environment: Ivy 2.4.0, Ant 1.9.4 Reporter: Eric Milles I have a base project that defines a number of configurations and dependencies, including a few exclude elements to prevent conflicting dependencies from coming in transitively. In a child module, the configurations and dependencies are being inherited properly, but the excludes no longer take effect. ivy-module info module=A organisation=com.org / configurations conf name=local visibility=private description=Artifacts necessary for local development and testing / conf name=master / /configurations dependencies defaultconf=master defaultconfmapping=*-master,runtime() dependency org=log4j name=log4j rev=1.2.17 / dependency org=org.slf4j name=slf4j-api rev=1.7.10 / dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 / dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 / !-- ensure logging flows through the chosen 4 by excluding potential interlopers -- exclude conf=local matcher=regexp org=.*(commons-logging|logback|log4j|slf4j) / exclude conf=master matcher=regexp module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* / /dependencies /ivy-module ivy-module info module=B organisation=com.org extends module=A organisation=com.org extendType=configurations,dependencies location=../A/ivy.xml revision=latest / dependencies defaultconf=master defaultconfmapping=*-master,runtime() dependency ... conf=local /!-- this dependency includes commons-logging transitively and the exclude from module A should stop that from coming in so that jcl-over-slf4j is used instead -- /dependencies /info -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IVY-1516) Module that extends is not picking up exclude element(s) from parent's dependencies
[
https://issues.apache.org/jira/browse/IVY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated IVY-1516:
-
Description:
I have a base project that defines a number of configurations and dependencies,
including a few exclude elements to prevent conflicting dependencies from
coming in transitively. In a child module, the configurations and dependencies
are being inherited properly, but the excludes no longer take effect.
{noformat}
ivy-module version=2.0
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ant.apache.org/ivy/schemas/ivy.xsd;
info module=A organisation=com.org /
configurations
conf name=local visibility=private
description=Artifacts necessary for local development and testing /
conf name=master /
/configurations
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency org=log4j name=log4j rev=1.2.17 /
dependency org=org.slf4j name=slf4j-api rev=1.7.10 /
dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 /
dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 /
!-- ensure logging flows through the chosen 4 by excluding potential
interlopers --
exclude conf=local matcher=regexp
org=.*(commons-logging|logback|log4j|slf4j) /
exclude conf=master matcher=regexp
module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* /
/dependencies
/ivy-module
ivy-module version=2.0
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ant.apache.org/ivy/schemas/ivy.xsd;
info module=B organisation=com.org
extends module=A organisation=com.org
extendType=configurations,dependencies location=../A/ivy.xml
revision=latest /
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency ... conf=local /!-- this dependency includes
commons-logging transitively and the exclude from module A should stop that
from coming in so that jcl-over-slf4j is used instead --
/dependencies
/info
/ivy-module
{noformat}
was:
I have a base project that defines a number of configurations and dependencies,
including a few exclude elements to prevent conflicting dependencies from
coming in transitively. In a child module, the configurations and dependencies
are being inherited properly, but the excludes no longer take effect.
{noformat}
ivy-module version=2.0
info module=A organisation=com.org /
configurations
conf name=local visibility=private
description=Artifacts necessary for local development and testing /
conf name=master /
/configurations
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency org=log4j name=log4j rev=1.2.17 /
dependency org=org.slf4j name=slf4j-api rev=1.7.10 /
dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 /
dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 /
!-- ensure logging flows through the chosen 4 by excluding potential
interlopers --
exclude conf=local matcher=regexp
org=.*(commons-logging|logback|log4j|slf4j) /
exclude conf=master matcher=regexp
module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* /
/dependencies
/ivy-module
ivy-module version=2.0
info module=B organisation=com.org
extends module=A organisation=com.org
extendType=configurations,dependencies location=../A/ivy.xml
revision=latest /
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency ... conf=local /!-- this dependency includes
commons-logging transitively and the exclude from module A should stop that
from coming in so that jcl-over-slf4j is used instead --
/dependencies
/info
/ivy-module
{noformat}
Module that extends is not picking up exclude element(s) from parent's
dependencies
---
Key: IVY-1516
URL: https://issues.apache.org/jira/browse/IVY-1516
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.4.0
Environment: Ivy 2.4.0, Ant 1.9.4
Reporter: Eric Milles
I have a base project that defines a number of configurations and
dependencies, including a few exclude elements to prevent conflicting
dependencies from coming in transitively. In a child module, the
configurations and dependencies are being inherited properly, but the
excludes no longer take effect.
{noformat}
ivy-module version=2.0
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ant.apache.org/ivy/schemas/ivy.xsd;
info module=A organisation=com.org /
configurations
conf name=local visibility=private
description=Artifacts necessary for local development and testing /
[jira] [Updated] (IVY-1516) Module that uses extends is not picking up exclude element(s) from patent's dependencies definition
[ https://issues.apache.org/jira/browse/IVY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Milles updated IVY-1516: - Description: I have a base project that defines a number of configurations and dependencies, including a few exclude elements to prevent conflicting dependencies from coming in transitively. In a child module, the configurations and dependencies are being inherited properly, but the excludes no longer take effect. ivy-module info module=A organisation=com.org / configurations conf name=local visibility=private description=Artifacts necessary for local development and testing / conf name=master / /configurations dependencies defaultconf=master defaultconfmapping=*-master,runtime() dependency org=log4j name=log4j rev=1.2.17 / dependency org=org.slf4j name=slf4j-api rev=1.7.10 / dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 / dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 / !-- ensure logging flows through the chosen 4 by excluding potential interlopers -- exclude conf=local matcher=regexp org=.*(commons-logging|logback|log4j|slf4j) / exclude conf=master matcher=regexp module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* / /dependencies /ivy-module ivy-module info module=B organisation=com.org extends module=A organisation=com.org extendType=configurations,dependencies location=../A/ivy.xml revision=latest / dependencies defaultconf=master defaultconfmapping=*-master,runtime() dependency ... conf=local /!-- this dependency includes commons-logging transitively and the exclude from module A should stop that from coming in so that jcl-over-slf4j is used instead -- /dependencies /info was: I have a base project that defines a number of configurations and dependencies, including a few exclude elements to prevent conflicting dependencies from coming in transitively. In a child module, the configurations and dependencies are being inherited properly, but the excludes no longer take effect. ivy-module info module=A organisation=com.org / configurations conf name=local visibility=private description=Artifacts necessary for local development and testing / conf name=master / /configurations dependencies defaultconf=master defaultconfmapping=*-master,runtime() dependency org=log4j name=log4j rev=1.2.17 / dependency org=org.slf4j name=slf4j-api rev=1.7.10 / dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 / dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 / !-- ensure logging flows through the chosen 4 by excluding potential interlopers -- exclude conf=local matcher=regexp org=.*(commons-logging|logback|log4j|slf4j) / exclude conf=master matcher=regexp module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* / /dependencies /ivy-module ivy-module info module=B organisation=com.org extends module=A organisation=com.org extendType=configurations,dependencies location=../A/ivy.xml revision=latest / dependencies defaultconf=master defaultconfmapping=*-master,runtime() dependency ... conf=local /!-- this dependency includes log4j transitively and the exclude from module A should stop that from coming in -- /dependencies /info Module that uses extends is not picking up exclude element(s) from patent's dependencies definition --- Key: IVY-1516 URL: https://issues.apache.org/jira/browse/IVY-1516 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.4.0 Environment: Ivy 2.4.0, Ant 1.9.4 Reporter: Eric Milles I have a base project that defines a number of configurations and dependencies, including a few exclude elements to prevent conflicting dependencies from coming in transitively. In a child module, the configurations and dependencies are being inherited properly, but the excludes no longer take effect. ivy-module info module=A organisation=com.org / configurations conf name=local visibility=private description=Artifacts necessary for local development and testing / conf name=master / /configurations dependencies defaultconf=master defaultconfmapping=*-master,runtime() dependency org=log4j name=log4j rev=1.2.17 / dependency org=org.slf4j name=slf4j-api rev=1.7.10 / dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 / dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 / !-- ensure logging flows through the chosen 4 by excluding potential interlopers -- exclude conf=local matcher=regexp
[jira] [Updated] (IVY-1516) Module that extends is not picking up exclude element(s) from parent's dependencies
[
https://issues.apache.org/jira/browse/IVY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated IVY-1516:
-
Description:
I have a base project that defines a number of configurations and dependencies,
including a few exclude elements to prevent conflicting dependencies from
coming in transitively. In a child module, the configurations and dependencies
are being inherited properly, but the excludes no longer take effect.
{noformat}
ivy-module version=2.0
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ant.apache.org/ivy/schemas/ivy.xsd;
info module=A organisation=com.org /
configurations
conf name=local visibility=private
description=Artifacts necessary for local development and testing /
conf name=master /
/configurations
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency org=log4j name=log4j rev=1.2.17 /
dependency org=org.slf4j name=slf4j-api rev=1.7.10 /
dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 /
dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 /
!-- ensure logging flows through the chosen 4 by excluding potential
interlopers --
exclude conf=local matcher=regexp
org=.*(commons-logging|logback|log4j|slf4j) /
exclude conf=master matcher=regexp
module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* /
/dependencies
/ivy-module
ivy-module version=2.0
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ant.apache.org/ivy/schemas/ivy.xsd;
info module=B organisation=com.org
extends module=A organisation=com.org
extendType=configurations,dependencies location=../A/ivy.xml
revision=latest /
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency ... conf=local /!-- this dependency includes
commons-logging transitively and the exclude from module A should stop that
from coming in so that jcl-over-slf4j is used instead --
/dependencies
/info
/ivy-module
{noformat}
Also, if the dependency here defined in B was moved up to A, the exclude
properly removes commons-logging from A's libraries. But commons-logging will
appear in B's libraries.
was:
I have a base project that defines a number of configurations and dependencies,
including a few exclude elements to prevent conflicting dependencies from
coming in transitively. In a child module, the configurations and dependencies
are being inherited properly, but the excludes no longer take effect.
{noformat}
ivy-module version=2.0
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ant.apache.org/ivy/schemas/ivy.xsd;
info module=A organisation=com.org /
configurations
conf name=local visibility=private
description=Artifacts necessary for local development and testing /
conf name=master /
/configurations
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency org=log4j name=log4j rev=1.2.17 /
dependency org=org.slf4j name=slf4j-api rev=1.7.10 /
dependency org=org.slf4j name=slf4j-log4j12 rev=1.7.10 /
dependency org=org.slf4j name=jcl-over-slf4j rev=1.7.10 /
!-- ensure logging flows through the chosen 4 by excluding potential
interlopers --
exclude conf=local matcher=regexp
org=.*(commons-logging|logback|log4j|slf4j) /
exclude conf=master matcher=regexp
module=(commons-logging|logback|log4j-over|slf4j-(?!api|log4j)).* /
/dependencies
/ivy-module
ivy-module version=2.0
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ant.apache.org/ivy/schemas/ivy.xsd;
info module=B organisation=com.org
extends module=A organisation=com.org
extendType=configurations,dependencies location=../A/ivy.xml
revision=latest /
dependencies defaultconf=master defaultconfmapping=*-master,runtime()
dependency ... conf=local /!-- this dependency includes
commons-logging transitively and the exclude from module A should stop that
from coming in so that jcl-over-slf4j is used instead --
/dependencies
/info
/ivy-module
{noformat}
Module that extends is not picking up exclude element(s) from parent's
dependencies
---
Key: IVY-1516
URL: https://issues.apache.org/jira/browse/IVY-1516
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.4.0
Environment: Ivy 2.4.0, Ant 1.9.4
Reporter: Eric Milles
I have a base project that defines a number of configurations and
dependencies, including a few exclude elements to prevent conflicting
dependencies from coming in transitively. In a child module, the
[jira] [Commented] (IVYDE-345) IvyDE 2.2.0.beta1 with Ivy 2.3.0 fails to load multiple Ivy classpath containers in Eclipse
[ https://issues.apache.org/jira/browse/IVYDE-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814249#comment-13814249 ] Eric Milles commented on IVYDE-345: --- Nicolas, Thanks for the follow-up. When I submitted the bug, I was using Eclipse 3.8.1. I am now running 4.3.1 and trying out 4.4M releases. With those, I am not seeing the problem anymore. Eric IvyDE 2.2.0.beta1 with Ivy 2.3.0 fails to load multiple Ivy classpath containers in Eclipse --- Key: IVYDE-345 URL: https://issues.apache.org/jira/browse/IVYDE-345 Project: IvyDE Issue Type: Bug Components: classpath container Affects Versions: 2.2.0.beta1 Environment: Eclipse Platform 3.8.1 Reporter: Eric Milles After updating Ivy to 2.3.0 in Eclipse (IvyDE remains at 2.2.0.beta1), and project with multiple IvyDE classpath containers defined in the .classpath file will only load the last one. For example, I have a project set to load conf 'local' for the test libraries as one classpath container and conf 'master' for the main application dependencies as another classpath container (only this container is deployed by WTP). Only the 'master' container is showing up now. If I comment out the 'master' container in .classpath and Resolve, the 'local' container shows up. So it is not the .classpath XML that has a problem. IvyDE is dropping all but the last container. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (IVYDE-345) IvyDE 2.2.0.beta1 with Ivy 2.3.0 fails to load multiple Ivy classpath containers in Eclipse
Eric Milles created IVYDE-345: - Summary: IvyDE 2.2.0.beta1 with Ivy 2.3.0 fails to load multiple Ivy classpath containers in Eclipse Key: IVYDE-345 URL: https://issues.apache.org/jira/browse/IVYDE-345 Project: IvyDE Issue Type: Bug Components: classpath container Affects Versions: 2.2.0.beta1 Environment: Eclipse Platform 3.8.1 Reporter: Eric Milles After updating Ivy to 2.3.0 in Eclipse (IvyDE remains at 2.2.0.beta1), and project with multiple IvyDE classpath containers defined in the .classpath file will only load the last one. For example, I have a project set to load conf 'local' for the test libraries as one classpath container and conf 'master' for the main application dependencies as another classpath container (only this container is deployed by WTP). Only the 'master' container is showing up now. If I comment out the 'master' container in .classpath and Resolve, the 'local' container shows up. So it is not the .classpath XML that has a problem. IvyDE is dropping all but the last container. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
