[jira] [Commented] (IVY-1502) Be a nice freedesktop citizen, move the ~/.ivy to the appropriate location
[ https://issues.apache.org/jira/browse/IVY-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844644#comment-17844644 ] Jaikiran Pai commented on IVY-1502: --- Just a note - the chances of any new features or enhancements or even regular bug fixes are very remote for reasons stated in https://www.mail-archive.com/dev@ant.apache.org/msg49479.html > Be a nice freedesktop citizen, move the ~/.ivy to the appropriate location > > > Key: IVY-1502 > URL: https://issues.apache.org/jira/browse/IVY-1502 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.3.0 > Environment: linux >Reporter: PerfectCarl >Priority: Minor > > According to the XDG specification [1], there is a better way to store the > user specific data of an application by dumping in new hidden folder in ~/. > More information about it can be found [2] > The specification defines places to store the data so that the user profile > can be updated and moved properly while reducing some weird bugs. > Those places would be ~/.local/ivy or ~/.cache/ivy and other (depending on > the data stored) > [1]: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html > [2]: https://ploum.net/207-modify-your-application-to-use-xdg-folders/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IVY-1633) Unable to follow redirects with user info in URL
[
https://issues.apache.org/jira/browse/IVY-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464290#comment-17464290
]
Jaikiran Pai commented on IVY-1633:
---
> The use case here allows the redirecting server to provide default "readonly"
>credentials, then the client can choose to elevate their privileges with their
>own credentials as required and if none are provided then the server
>credentials are used.
> If we invert the order, then a client could never override the credentials
> provided by the redirecting server.
I think the client (Ivy) having a final control over which credential gets used
makes sense. That way, users can at least configure a different credential for
that redirected URL if they want to. So what you have now I think is fine then.
Would you be able to include a test case in the patch, in the Ivy test suite to
make sure this works (and continues to work) as expected? If not, I'll add one
myself before merging this.
> Unable to follow redirects with user info in URL
>
>
> Key: IVY-1633
> URL: https://issues.apache.org/jira/browse/IVY-1633
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.5.0
> Environment: % java -version
> java version "1.8.0_271"
> Java(TM) SE Runtime Environment (build 1.8.0_271-b09)
> Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
> % ant -version
> Apache Ant(TM) version 1.10.12 compiled on October 13 2021
> % ls /usr/local/Cellar/ant/1.10.12/libexec/lib/ivy*
> /usr/local/Cellar/ant/1.10.12/libexec/lib/ivy-2.5.0.jar
>Reporter: John Robert Fallows
>Priority: Major
> Attachments: ivy-userinfo.patch
>
>
> Maven2 compatible repositories sending 302 redirect with user info embedded
> in the location response header are followed properly by Maven but not by Ivy.
> See example at [https://github.com/aklivity/toystore].
> {quote}% ./mvnw dependency:resolve
> [INFO] Scanning for projects...
> [INFO]
> [INFO] < io.aklivity.sandbox:toystore
> >
> [INFO] Building toystore develop-SNAPSHOT
> [INFO] [ jar
> ]-
> Downloading from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.pom
> Downloaded from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.pom
> (550 B at 348 B/s)
> Downloading from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/parent/0.3/parent-0.3.pom
> Downloaded from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/parent/0.3/parent-0.3.pom
> (1.8 kB at 1.9 kB/s)
> Downloading from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.jar
> Downloaded from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.jar
> (1.5 kB at 1.4 kB/s)
> [INFO]
> [INFO] --- maven-dependency-plugin:2.8:resolve (default-cli) @ toystore ---
> [INFO]
> [INFO] The following files have been resolved:
> [INFO] io.aklivity.sandbox:toys:jar:0.3:compile
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {quote}
> whereas for Ivy
> {quote}% ant
> Buildfile: /Users/jfallows/GitHub/aklivity/toystore/build.xml
>
> resolve:
> [ivy:convertpom] :: Apache Ivy 2.5.0 - 20191020104435 ::
> https://ant.apache.org/ivy/ ::
> [ivy:convertpom] :: loading settings :: file =
> /Users/jfallows/GitHub/aklivity/toystore/ivysettings.xml
> [ivy:retrieve] :: resolving dependencies ::
> io.aklivity.sandbox#toystore;develop-SNAPSHOT
> [ivy:retrieve] confs: [default, master, compile, provided, runtime, test,
> system, sources, javadoc, optional]
> [ivy:retrieve] :: resolution report :: resolve 1148ms :: artifacts dl 0ms
> -
> | | modules || artifacts |
> | conf | number| search|dwnlded|evicted|| number|dwnlded|
> -
> | default | 1 | 0 | 0 | 0 || 0 | 0 |
> | master | 0 | 0 | 0 | 0 || 0 | 0 |
> | compile | 1 | 0 | 0 | 0 || 0 | 0 |
> | provided | 0 | 0 | 0 | 0 || 0 | 0 |
> | runtime | 1 | 0 | 0 | 0 || 0 | 0 |
> | test | 1 | 0 | 0 | 0 || 0 | 0 |
> | system | 0 | 0 | 0 | 0 || 0 | 0 |
> | sources | 0 | 0 | 0 | 0 ||
[jira] [Commented] (IVY-1633) Unable to follow redirects with user info in URL
[
https://issues.apache.org/jira/browse/IVY-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461774#comment-17461774
]
Jaikiran Pai commented on IVY-1633:
---
Hello John, I took a quick look at this. It appears that even Java's
implementation of HTTPURLConnection doesn't handle redirects of this form where
ther userinfo is part of the redirected "Location".
Looking at your patch, I think one thing we might have to consider in that
change is the "priority" of which credential gets used for that particular URL.
What I mean is, the IvyAuthenticator uses a CredentialsStore which is queried
for credentials, for a particular realm and host. In your patch, that
credential store will be queried first and only if it returns null then the
user/pass from the URL (if any) is used. I think it should be the other way
around. The userinfo (if any) in the requesting URL should be first checked and
only if it is missing, then the credential store should be queried. We will
have to see if there are any other implications of this.
FWIW, there seems to be a JDK issue requesting a similar enhancement (not
specifically to redirected requests, but URLs in general)
[https://bugs.openjdk.java.net/browse/JDK-5043482] and the recommendation seems
to be use an Authenticator (like the IvyAuthenticator) to handle this use case.
> Unable to follow redirects with user info in URL
>
>
> Key: IVY-1633
> URL: https://issues.apache.org/jira/browse/IVY-1633
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.5.0
> Environment: % java -version
> java version "1.8.0_271"
> Java(TM) SE Runtime Environment (build 1.8.0_271-b09)
> Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
> % ant -version
> Apache Ant(TM) version 1.10.12 compiled on October 13 2021
> % ls /usr/local/Cellar/ant/1.10.12/libexec/lib/ivy*
> /usr/local/Cellar/ant/1.10.12/libexec/lib/ivy-2.5.0.jar
>Reporter: John Robert Fallows
>Priority: Major
> Attachments: ivy-userinfo.patch
>
>
> Maven2 compatible repositories sending 302 redirect with user info embedded
> in the location response header are followed properly by Maven but not by Ivy.
> See example at [https://github.com/aklivity/toystore].
> {quote}% ./mvnw dependency:resolve
> [INFO] Scanning for projects...
> [INFO]
> [INFO] < io.aklivity.sandbox:toystore
> >
> [INFO] Building toystore develop-SNAPSHOT
> [INFO] [ jar
> ]-
> Downloading from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.pom
> Downloaded from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.pom
> (550 B at 348 B/s)
> Downloading from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/parent/0.3/parent-0.3.pom
> Downloaded from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/parent/0.3/parent-0.3.pom
> (1.8 kB at 1.9 kB/s)
> Downloading from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.jar
> Downloaded from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.jar
> (1.5 kB at 1.4 kB/s)
> [INFO]
> [INFO] --- maven-dependency-plugin:2.8:resolve (default-cli) @ toystore ---
> [INFO]
> [INFO] The following files have been resolved:
> [INFO] io.aklivity.sandbox:toys:jar:0.3:compile
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {quote}
> whereas for Ivy
> {quote}% ant
> Buildfile: /Users/jfallows/GitHub/aklivity/toystore/build.xml
>
> resolve:
> [ivy:convertpom] :: Apache Ivy 2.5.0 - 20191020104435 ::
> https://ant.apache.org/ivy/ ::
> [ivy:convertpom] :: loading settings :: file =
> /Users/jfallows/GitHub/aklivity/toystore/ivysettings.xml
> [ivy:retrieve] :: resolving dependencies ::
> io.aklivity.sandbox#toystore;develop-SNAPSHOT
> [ivy:retrieve] confs: [default, master, compile, provided, runtime, test,
> system, sources, javadoc, optional]
> [ivy:retrieve] :: resolution report :: resolve 1148ms :: artifacts dl 0ms
> -
> | | modules || artifacts |
> | conf | number| search|dwnlded|evicted|| number|dwnlded|
> -
> | default | 1 | 0 | 0 | 0 || 0 | 0 |
> | master | 0 | 0 | 0 | 0 || 0 | 0 |
> | compile | 1 | 0 | 0 |
[jira] [Updated] (IVY-1633) Unable to follow redirects with user info in URL
[
https://issues.apache.org/jira/browse/IVY-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai updated IVY-1633:
--
Priority: Major (was: Blocker)
> Unable to follow redirects with user info in URL
>
>
> Key: IVY-1633
> URL: https://issues.apache.org/jira/browse/IVY-1633
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.5.0
> Environment: % java -version
> java version "1.8.0_271"
> Java(TM) SE Runtime Environment (build 1.8.0_271-b09)
> Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
> % ant -version
> Apache Ant(TM) version 1.10.12 compiled on October 13 2021
> % ls /usr/local/Cellar/ant/1.10.12/libexec/lib/ivy*
> /usr/local/Cellar/ant/1.10.12/libexec/lib/ivy-2.5.0.jar
>Reporter: John Robert Fallows
>Priority: Major
> Attachments: ivy-userinfo.patch
>
>
> Maven2 compatible repositories sending 302 redirect with user info embedded
> in the location response header are followed properly by Maven but not by Ivy.
> See example at [https://github.com/aklivity/toystore].
> {quote}% ./mvnw dependency:resolve
> [INFO] Scanning for projects...
> [INFO]
> [INFO] < io.aklivity.sandbox:toystore
> >
> [INFO] Building toystore develop-SNAPSHOT
> [INFO] [ jar
> ]-
> Downloading from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.pom
> Downloaded from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.pom
> (550 B at 348 B/s)
> Downloading from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/parent/0.3/parent-0.3.pom
> Downloaded from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/parent/0.3/parent-0.3.pom
> (1.8 kB at 1.9 kB/s)
> Downloading from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.jar
> Downloaded from anonymous:
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.jar
> (1.5 kB at 1.4 kB/s)
> [INFO]
> [INFO] --- maven-dependency-plugin:2.8:resolve (default-cli) @ toystore ---
> [INFO]
> [INFO] The following files have been resolved:
> [INFO] io.aklivity.sandbox:toys:jar:0.3:compile
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {quote}
> whereas for Ivy
> {quote}% ant
> Buildfile: /Users/jfallows/GitHub/aklivity/toystore/build.xml
>
> resolve:
> [ivy:convertpom] :: Apache Ivy 2.5.0 - 20191020104435 ::
> https://ant.apache.org/ivy/ ::
> [ivy:convertpom] :: loading settings :: file =
> /Users/jfallows/GitHub/aklivity/toystore/ivysettings.xml
> [ivy:retrieve] :: resolving dependencies ::
> io.aklivity.sandbox#toystore;develop-SNAPSHOT
> [ivy:retrieve] confs: [default, master, compile, provided, runtime, test,
> system, sources, javadoc, optional]
> [ivy:retrieve] :: resolution report :: resolve 1148ms :: artifacts dl 0ms
> -
> | | modules || artifacts |
> | conf | number| search|dwnlded|evicted|| number|dwnlded|
> -
> | default | 1 | 0 | 0 | 0 || 0 | 0 |
> | master | 0 | 0 | 0 | 0 || 0 | 0 |
> | compile | 1 | 0 | 0 | 0 || 0 | 0 |
> | provided | 0 | 0 | 0 | 0 || 0 | 0 |
> | runtime | 1 | 0 | 0 | 0 || 0 | 0 |
> | test | 1 | 0 | 0 | 0 || 0 | 0 |
> | system | 0 | 0 | 0 | 0 || 0 | 0 |
> | sources | 0 | 0 | 0 | 0 || 0 | 0 |
> | javadoc | 0 | 0 | 0 | 0 || 0 | 0 |
> | optional | 0 | 0 | 0 | 0 || 0 | 0 |
> -
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve] WARNINGS
> [ivy:retrieve] module not found: io.aklivity.sandbox#toys;0.3
> [ivy:retrieve] ibiblio: tried
> [ivy:retrieve]
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.pom
> [ivy:retrieve] -- artifact io.aklivity.sandbox#toys;0.3!toys.jar:
> [ivy:retrieve]
> https://maven.packages.aklivity.io/io/aklivity/sandbox/toys/0.3/toys-0.3.jar
> [ivy:retrieve] ibiblio: tried
> [ivy:retrieve]
>
[jira] [Resolved] (IVY-1630) get started link take me to adds websites
[ https://issues.apache.org/jira/browse/IVY-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai resolved IVY-1630. --- Assignee: Jaikiran Pai Resolution: Fixed > get started link take me to adds websites > - > > Key: IVY-1630 > URL: https://issues.apache.org/jira/browse/IVY-1630 > Project: Ivy > Issue Type: Bug >Reporter: dyea >Assignee: Jaikiran Pai >Priority: Minor > > search in this link for > Getting Started with Apache Ivy > https://ant.apache.org/ivy/links.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IVY-1630) get started link take me to adds websites
[ https://issues.apache.org/jira/browse/IVY-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426752#comment-17426752 ] Jaikiran Pai commented on IVY-1630: --- Thank you for bringing this to attention. I've updated the site to remove references to that link. > get started link take me to adds websites > - > > Key: IVY-1630 > URL: https://issues.apache.org/jira/browse/IVY-1630 > Project: Ivy > Issue Type: Bug >Reporter: dyea >Priority: Minor > > search in this link for > Getting Started with Apache Ivy > https://ant.apache.org/ivy/links.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (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
]
Jaikiran Pai resolved IVY-1616.
---
Fix Version/s: master
Resolution: Fixed
This is now fixed and should be available in next release.
> 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
> Fix For: master
>
>
> 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] [Resolved] (IVY-1615) Ivy standalone : specify settings from URL
[
https://issues.apache.org/jira/browse/IVY-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai resolved IVY-1615.
---
Fix Version/s: master
Resolution: Fixed
Thank you for that patch. I've merged it along with a test case and credited
you for that contribution.
> Ivy standalone : specify settings from URL
> --
>
> Key: IVY-1615
> URL: https://issues.apache.org/jira/browse/IVY-1615
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.5.0
>Reporter: Jason A. Guild
>Assignee: Jaikiran Pai
>Priority: Minor
> Labels: CLI, settings, standalone
> Fix For: master
>
> Attachments: cli_ivysettings_from_url.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When using ivy in standalone mode via CLI, allow the {{-settings}} option to
> read xml settings from a URL instead of a filesystem path. This allows
> convenient access to centralized settings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IVY-1615) Ivy standalone : specify settings from URL
[
https://issues.apache.org/jira/browse/IVY-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai reassigned IVY-1615:
-
Assignee: Jaikiran Pai
> Ivy standalone : specify settings from URL
> --
>
> Key: IVY-1615
> URL: https://issues.apache.org/jira/browse/IVY-1615
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.5.0
>Reporter: Jason A. Guild
>Assignee: Jaikiran Pai
>Priority: Minor
> Labels: CLI, settings, standalone
> Attachments: cli_ivysettings_from_url.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When using ivy in standalone mode via CLI, allow the {{-settings}} option to
> read xml settings from a URL instead of a filesystem path. This allows
> convenient access to centralized settings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IVY-1618) ResolveEngine resets dictator resolver to null in the global configuration
[
https://issues.apache.org/jira/browse/IVY-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai resolved IVY-1618.
---
Fix Version/s: master
Resolution: Fixed
> ResolveEngine resets dictator resolver to null in the global configuration
> --
>
> Key: IVY-1618
> URL: https://issues.apache.org/jira/browse/IVY-1618
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0
> Environment: Windows 10, Java 8, Ivy 2.5.0.
>Reporter: Sergei Zhirikov
>Assignee: Jaikiran Pai
>Priority: Minor
> Fix For: master
>
>
> ResolveEngine does not initialize its dictatorResover field in the
> constructor. As the result, when
> {code:java}
> public ResolveReport resolve(ModuleDescriptor md, ResolveOptions
> options){code}
> is called, the {{oldDictator}} local variable will be set to null in the
> beginning of the method. Then, in the end of the same method, inside the
> {{finally}} block, {{setDictatorResolver(null)}} will be called, which will
> not only set the private field in the ResolveEngine itself, but will also
> reset the dictator resolver in the global configuration. Why would it do
> that???
> The problem manifests itself when an {{Ivy}} instance is configured (using
> Java API) with only a dictator resolver, it will be able to handle a single
> call to {{resolve(...)}} successfully, and all subsequent calls will fail
> because of "no resolver available" (because the one that is supposed to be
> available, has been reset by the ResolveEngine, as described above).
> I have to admit that I am not very familiar with Ivy internals, but I find it
> extremely puzzling that an object that is a part of the internal
> implementation would change the global configuration at will.
> Looking at the implementation of {{Ivy}} and {{IvyContext}} classes, I get
> the impression that an {{Ivy}} instance is supposed to be thread-safe, in the
> sense that it should allow to call {{resolve(...)}} on the same instance from
> multiple threads safely. Am I mistaken? If there is supposed to be any thread
> safety, it is broken by the peculiar behavior of ResolveEngine with respect
> to setting the dictator resolver.
> In any case, I think it would be really helpful to explicitly mention thread
> safety (or lack thereof) in the Javadoc page of the main {{Ivy}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1618) ResolveEngine resets dictator resolver to null in the global configuration
[
https://issues.apache.org/jira/browse/IVY-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310384#comment-17310384
]
Jaikiran Pai commented on IVY-1618:
---
The setDictatorResolver on ResolveEngine shouldn't be changing the resolver on
the Ivy settings. This has now been fixed and will be available in the next
release. Thank you for reporting this issue.
> ResolveEngine resets dictator resolver to null in the global configuration
> --
>
> Key: IVY-1618
> URL: https://issues.apache.org/jira/browse/IVY-1618
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0
> Environment: Windows 10, Java 8, Ivy 2.5.0.
>Reporter: Sergei Zhirikov
>Assignee: Jaikiran Pai
>Priority: Minor
>
> ResolveEngine does not initialize its dictatorResover field in the
> constructor. As the result, when
> {code:java}
> public ResolveReport resolve(ModuleDescriptor md, ResolveOptions
> options){code}
> is called, the {{oldDictator}} local variable will be set to null in the
> beginning of the method. Then, in the end of the same method, inside the
> {{finally}} block, {{setDictatorResolver(null)}} will be called, which will
> not only set the private field in the ResolveEngine itself, but will also
> reset the dictator resolver in the global configuration. Why would it do
> that???
> The problem manifests itself when an {{Ivy}} instance is configured (using
> Java API) with only a dictator resolver, it will be able to handle a single
> call to {{resolve(...)}} successfully, and all subsequent calls will fail
> because of "no resolver available" (because the one that is supposed to be
> available, has been reset by the ResolveEngine, as described above).
> I have to admit that I am not very familiar with Ivy internals, but I find it
> extremely puzzling that an object that is a part of the internal
> implementation would change the global configuration at will.
> Looking at the implementation of {{Ivy}} and {{IvyContext}} classes, I get
> the impression that an {{Ivy}} instance is supposed to be thread-safe, in the
> sense that it should allow to call {{resolve(...)}} on the same instance from
> multiple threads safely. Am I mistaken? If there is supposed to be any thread
> safety, it is broken by the peculiar behavior of ResolveEngine with respect
> to setting the dictator resolver.
> In any case, I think it would be really helpful to explicitly mention thread
> safety (or lack thereof) in the Javadoc page of the main {{Ivy}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IVY-1618) ResolveEngine resets dictator resolver to null in the global configuration
[
https://issues.apache.org/jira/browse/IVY-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai reassigned IVY-1618:
-
Assignee: Jaikiran Pai
> ResolveEngine resets dictator resolver to null in the global configuration
> --
>
> Key: IVY-1618
> URL: https://issues.apache.org/jira/browse/IVY-1618
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0
> Environment: Windows 10, Java 8, Ivy 2.5.0.
>Reporter: Sergei Zhirikov
>Assignee: Jaikiran Pai
>Priority: Minor
>
> ResolveEngine does not initialize its dictatorResover field in the
> constructor. As the result, when
> {code:java}
> public ResolveReport resolve(ModuleDescriptor md, ResolveOptions
> options){code}
> is called, the {{oldDictator}} local variable will be set to null in the
> beginning of the method. Then, in the end of the same method, inside the
> {{finally}} block, {{setDictatorResolver(null)}} will be called, which will
> not only set the private field in the ResolveEngine itself, but will also
> reset the dictator resolver in the global configuration. Why would it do
> that???
> The problem manifests itself when an {{Ivy}} instance is configured (using
> Java API) with only a dictator resolver, it will be able to handle a single
> call to {{resolve(...)}} successfully, and all subsequent calls will fail
> because of "no resolver available" (because the one that is supposed to be
> available, has been reset by the ResolveEngine, as described above).
> I have to admit that I am not very familiar with Ivy internals, but I find it
> extremely puzzling that an object that is a part of the internal
> implementation would change the global configuration at will.
> Looking at the implementation of {{Ivy}} and {{IvyContext}} classes, I get
> the impression that an {{Ivy}} instance is supposed to be thread-safe, in the
> sense that it should allow to call {{resolve(...)}} on the same instance from
> multiple threads safely. Am I mistaken? If there is supposed to be any thread
> safety, it is broken by the peculiar behavior of ResolveEngine with respect
> to setting the dictator resolver.
> In any case, I think it would be really helpful to explicitly mention thread
> safety (or lack thereof) in the Javadoc page of the main {{Ivy}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IVY-1626) Investigate impact of Bintray/JCenter shutdown
[ https://issues.apache.org/jira/browse/IVY-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai reassigned IVY-1626: - Assignee: Jaikiran Pai > Investigate impact of Bintray/JCenter shutdown > -- > > Key: IVY-1626 > URL: https://issues.apache.org/jira/browse/IVY-1626 > Project: Ivy > Issue Type: Task >Reporter: Aurélien Pupier >Assignee: Jaikiran Pai >Priority: Major > > on 1st May 2021, the Bintray/Jcenter service will be shutdown. Ivy is > providing bintray resolver. I think it is set by default (o maybe it is Grape > that is setting by default?) > https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ > Which changes in codebase are required? > Which changes in user config can be done to avoid issues if cannot upgrade to > latest version easily? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IVY-1626) Investigate impact of Bintray/JCenter shutdown
[ https://issues.apache.org/jira/browse/IVY-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310350#comment-17310350 ] Jaikiran Pai commented on IVY-1626: --- I've added a note to the bintray resovler that bintray and jcenter are going to be decommissioned. > Investigate impact of Bintray/JCenter shutdown > -- > > Key: IVY-1626 > URL: https://issues.apache.org/jira/browse/IVY-1626 > Project: Ivy > Issue Type: Task >Reporter: Aurélien Pupier >Priority: Major > > on 1st May 2021, the Bintray/Jcenter service will be shutdown. Ivy is > providing bintray resolver. I think it is set by default (o maybe it is Grape > that is setting by default?) > https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ > Which changes in codebase are required? > Which changes in user config can be done to avoid issues if cannot upgrade to > latest version easily? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IVY-1626) Investigate impact of Bintray/JCenter shutdown
[ https://issues.apache.org/jira/browse/IVY-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai resolved IVY-1626. --- Fix Version/s: master Resolution: Fixed > Investigate impact of Bintray/JCenter shutdown > -- > > Key: IVY-1626 > URL: https://issues.apache.org/jira/browse/IVY-1626 > Project: Ivy > Issue Type: Task >Reporter: Aurélien Pupier >Assignee: Jaikiran Pai >Priority: Major > Fix For: master > > > on 1st May 2021, the Bintray/Jcenter service will be shutdown. Ivy is > providing bintray resolver. I think it is set by default (o maybe it is Grape > that is setting by default?) > https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ > Which changes in codebase are required? > Which changes in user config can be done to avoid issues if cannot upgrade to > latest version easily? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IVY-1628) ConcurrentModificationException in MessageLoggerHelper.sumupProblems
[
https://issues.apache.org/jira/browse/IVY-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai resolved IVY-1628.
---
Resolution: Fixed
> ConcurrentModificationException in MessageLoggerHelper.sumupProblems
>
>
> Key: IVY-1628
> URL: https://issues.apache.org/jira/browse/IVY-1628
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Environment: Groovy 2.4.12
>Reporter: Monroe Walker
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: master
>
>
> Our Jenkins build job occasionally fails with
> {code:java}
> java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) at
> java.util.ArrayList$Itr.next(ArrayList.java:861) at
> org.apache.ivy.util.MessageLoggerHelper.sumupProblems(MessageLoggerHelper.java:45)
> at
> org.apache.ivy.util.MessageLoggerEngine.sumupProblems(MessageLoggerEngine.java:136)
> at org.apache.ivy.util.Message.sumupProblems(Message.java:143) at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:347) at
> org.apache.ivy.Ivy.resolve(Ivy.java:523)
> {code}
> It seems this must be due to a warning / error being logged while
> `sumupProblems` is printing the captured warning/errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1628) ConcurrentModificationException in MessageLoggerHelper.sumupProblems
[
https://issues.apache.org/jira/browse/IVY-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17309074#comment-17309074
]
Jaikiran Pai commented on IVY-1628:
---
Thank you [~mwalker]. I'll go ahead and mark this issue resolved now.
> ConcurrentModificationException in MessageLoggerHelper.sumupProblems
>
>
> Key: IVY-1628
> URL: https://issues.apache.org/jira/browse/IVY-1628
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Environment: Groovy 2.4.12
>Reporter: Monroe Walker
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: master
>
>
> Our Jenkins build job occasionally fails with
> {code:java}
> java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) at
> java.util.ArrayList$Itr.next(ArrayList.java:861) at
> org.apache.ivy.util.MessageLoggerHelper.sumupProblems(MessageLoggerHelper.java:45)
> at
> org.apache.ivy.util.MessageLoggerEngine.sumupProblems(MessageLoggerEngine.java:136)
> at org.apache.ivy.util.Message.sumupProblems(Message.java:143) at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:347) at
> org.apache.ivy.Ivy.resolve(Ivy.java:523)
> {code}
> It seems this must be due to a warning / error being logged while
> `sumupProblems` is printing the captured warning/errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1628) ConcurrentModificationException in MessageLoggerHelper.sumupProblems
[
https://issues.apache.org/jira/browse/IVY-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308345#comment-17308345
]
Jaikiran Pai commented on IVY-1628:
---
I went ahead and added a test to verify that the fix works
[https://github.com/apache/ant-ivy/commit/f1093f67d43c29baaa76c42cb51488cd4d61fd81.]
The test consistently fails without the fix.
> ConcurrentModificationException in MessageLoggerHelper.sumupProblems
>
>
> Key: IVY-1628
> URL: https://issues.apache.org/jira/browse/IVY-1628
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Environment: Groovy 2.4.12
>Reporter: Monroe Walker
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: master
>
>
> Our Jenkins build job occasionally fails with
> {code:java}
> java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) at
> java.util.ArrayList$Itr.next(ArrayList.java:861) at
> org.apache.ivy.util.MessageLoggerHelper.sumupProblems(MessageLoggerHelper.java:45)
> at
> org.apache.ivy.util.MessageLoggerEngine.sumupProblems(MessageLoggerEngine.java:136)
> at org.apache.ivy.util.Message.sumupProblems(Message.java:143) at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:347) at
> org.apache.ivy.Ivy.resolve(Ivy.java:523)
> {code}
> It seems this must be due to a warning / error being logged while
> `sumupProblems` is printing the captured warning/errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IVY-1628) ConcurrentModificationException in MessageLoggerHelper.sumupProblems
[
https://issues.apache.org/jira/browse/IVY-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308345#comment-17308345
]
Jaikiran Pai edited comment on IVY-1628 at 3/25/21, 4:22 AM:
-
I went ahead and added a test to verify that the fix works
[https://github.com/apache/ant-ivy/commit/f1093f67d43c29baaa76c42cb51488cd4d61fd81.]
Without the fix, the test consistently fails with the same exception that you
reported.
was (Author: jaikiran):
I went ahead and added a test to verify that the fix works
[https://github.com/apache/ant-ivy/commit/f1093f67d43c29baaa76c42cb51488cd4d61fd81.]
The test consistently fails without the fix.
> ConcurrentModificationException in MessageLoggerHelper.sumupProblems
>
>
> Key: IVY-1628
> URL: https://issues.apache.org/jira/browse/IVY-1628
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Environment: Groovy 2.4.12
>Reporter: Monroe Walker
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: master
>
>
> Our Jenkins build job occasionally fails with
> {code:java}
> java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) at
> java.util.ArrayList$Itr.next(ArrayList.java:861) at
> org.apache.ivy.util.MessageLoggerHelper.sumupProblems(MessageLoggerHelper.java:45)
> at
> org.apache.ivy.util.MessageLoggerEngine.sumupProblems(MessageLoggerEngine.java:136)
> at org.apache.ivy.util.Message.sumupProblems(Message.java:143) at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:347) at
> org.apache.ivy.Ivy.resolve(Ivy.java:523)
> {code}
> It seems this must be due to a warning / error being logged while
> `sumupProblems` is printing the captured warning/errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1628) ConcurrentModificationException in MessageLoggerHelper.sumupProblems
[
https://issues.apache.org/jira/browse/IVY-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308331#comment-17308331
]
Jaikiran Pai commented on IVY-1628:
---
Hello [~mwalker] , the implementation(s) of the MessageLogger (both the
AbstractMessageLogger and the MessageLoggerEngine), internally use an ArrayList
to keep track of "errors" and "warns". The code change that I did to use a copy
constructor of ArrayList internally, in such cases, just does an Array copy and
doesn't use the iterators, which is where the concurrent modification checks
reside. So I believe the change in that commit should address the issue.
> ConcurrentModificationException in MessageLoggerHelper.sumupProblems
>
>
> Key: IVY-1628
> URL: https://issues.apache.org/jira/browse/IVY-1628
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Environment: Groovy 2.4.12
>Reporter: Monroe Walker
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: master
>
>
> Our Jenkins build job occasionally fails with
> {code:java}
> java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) at
> java.util.ArrayList$Itr.next(ArrayList.java:861) at
> org.apache.ivy.util.MessageLoggerHelper.sumupProblems(MessageLoggerHelper.java:45)
> at
> org.apache.ivy.util.MessageLoggerEngine.sumupProblems(MessageLoggerEngine.java:136)
> at org.apache.ivy.util.Message.sumupProblems(Message.java:143) at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:347) at
> org.apache.ivy.Ivy.resolve(Ivy.java:523)
> {code}
> It seems this must be due to a warning / error being logged while
> `sumupProblems` is printing the captured warning/errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1628) ConcurrentModificationException in MessageLoggerHelper.sumupProblems
[
https://issues.apache.org/jira/browse/IVY-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306690#comment-17306690
]
Jaikiran Pai commented on IVY-1628:
---
Thank you for reporting this. I've pushed a fix which should address this
https://github.com/apache/ant-ivy/commit/083e3f685c1fe29092e59c63b87e81d31fc9babe/
> ConcurrentModificationException in MessageLoggerHelper.sumupProblems
>
>
> Key: IVY-1628
> URL: https://issues.apache.org/jira/browse/IVY-1628
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Environment: Groovy 2.4.12
>Reporter: Monroe Walker
>Assignee: Jaikiran Pai
>Priority: Major
>
> Our Jenkins build job occasionally fails with
> {code:java}
> java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) at
> java.util.ArrayList$Itr.next(ArrayList.java:861) at
> org.apache.ivy.util.MessageLoggerHelper.sumupProblems(MessageLoggerHelper.java:45)
> at
> org.apache.ivy.util.MessageLoggerEngine.sumupProblems(MessageLoggerEngine.java:136)
> at org.apache.ivy.util.Message.sumupProblems(Message.java:143) at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:347) at
> org.apache.ivy.Ivy.resolve(Ivy.java:523)
> {code}
> It seems this must be due to a warning / error being logged while
> `sumupProblems` is printing the captured warning/errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IVY-1628) ConcurrentModificationException in MessageLoggerHelper.sumupProblems
[
https://issues.apache.org/jira/browse/IVY-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai resolved IVY-1628.
---
Fix Version/s: master
Resolution: Fixed
> ConcurrentModificationException in MessageLoggerHelper.sumupProblems
>
>
> Key: IVY-1628
> URL: https://issues.apache.org/jira/browse/IVY-1628
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Environment: Groovy 2.4.12
>Reporter: Monroe Walker
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: master
>
>
> Our Jenkins build job occasionally fails with
> {code:java}
> java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) at
> java.util.ArrayList$Itr.next(ArrayList.java:861) at
> org.apache.ivy.util.MessageLoggerHelper.sumupProblems(MessageLoggerHelper.java:45)
> at
> org.apache.ivy.util.MessageLoggerEngine.sumupProblems(MessageLoggerEngine.java:136)
> at org.apache.ivy.util.Message.sumupProblems(Message.java:143) at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:347) at
> org.apache.ivy.Ivy.resolve(Ivy.java:523)
> {code}
> It seems this must be due to a warning / error being logged while
> `sumupProblems` is printing the captured warning/errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IVY-1628) ConcurrentModificationException in MessageLoggerHelper.sumupProblems
[
https://issues.apache.org/jira/browse/IVY-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai reassigned IVY-1628:
-
Assignee: Jaikiran Pai
> ConcurrentModificationException in MessageLoggerHelper.sumupProblems
>
>
> Key: IVY-1628
> URL: https://issues.apache.org/jira/browse/IVY-1628
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Environment: Groovy 2.4.12
>Reporter: Monroe Walker
>Assignee: Jaikiran Pai
>Priority: Major
>
> Our Jenkins build job occasionally fails with
> {code:java}
> java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) at
> java.util.ArrayList$Itr.next(ArrayList.java:861) at
> org.apache.ivy.util.MessageLoggerHelper.sumupProblems(MessageLoggerHelper.java:45)
> at
> org.apache.ivy.util.MessageLoggerEngine.sumupProblems(MessageLoggerEngine.java:136)
> at org.apache.ivy.util.Message.sumupProblems(Message.java:143) at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:347) at
> org.apache.ivy.Ivy.resolve(Ivy.java:523)
> {code}
> It seems this must be due to a warning / error being logged while
> `sumupProblems` is printing the captured warning/errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IVY-1628) ConcurrentModificationException in MessageLoggerHelper.sumupProblems
[
https://issues.apache.org/jira/browse/IVY-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai updated IVY-1628:
--
Component/s: (was: Ant)
Core
> ConcurrentModificationException in MessageLoggerHelper.sumupProblems
>
>
> Key: IVY-1628
> URL: https://issues.apache.org/jira/browse/IVY-1628
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Environment: Groovy 2.4.12
>Reporter: Monroe Walker
>Priority: Major
>
> Our Jenkins build job occasionally fails with
> {code:java}
> java.util.ConcurrentModificationExceptionjava.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911) at
> java.util.ArrayList$Itr.next(ArrayList.java:861) at
> org.apache.ivy.util.MessageLoggerHelper.sumupProblems(MessageLoggerHelper.java:45)
> at
> org.apache.ivy.util.MessageLoggerEngine.sumupProblems(MessageLoggerEngine.java:136)
> at org.apache.ivy.util.Message.sumupProblems(Message.java:143) at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:347) at
> org.apache.ivy.Ivy.resolve(Ivy.java:523)
> {code}
> It seems this must be due to a warning / error being logged while
> `sumupProblems` is printing the captured warning/errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1626) Investigate impact of Bintray/JCenter shutdown
[ https://issues.apache.org/jira/browse/IVY-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303846#comment-17303846 ] Jaikiran Pai commented on IVY-1626: --- > Ivy is providing bintray resolver. I think it is set by default Hello [~apupier] , Ivy doesn't use bintray resolver by default. It ships with a ibiblio and filesystem default resolvers. > Investigate impact of Bintray/JCenter shutdown > -- > > Key: IVY-1626 > URL: https://issues.apache.org/jira/browse/IVY-1626 > Project: Ivy > Issue Type: Task >Reporter: Aurélien Pupier >Priority: Major > > on 1st May 2021, the Bintray/Jcenter service will be shutdown. Ivy is > providing bintray resolver. I think it is set by default (o maybe it is Grape > that is setting by default?) > https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ > Which changes in codebase are required? > Which changes in user config can be done to avoid issues if cannot upgrade to > latest version easily? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IVY-1614) Ivy needs to translate Maven version ranges
[
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284084#comment-17284084
]
Jaikiran Pai commented on IVY-1614:
---
Hello Björn,
I forgot to reply to this the other day:
>But my second example which is what I originally reported here is still valid.
>The produced ivy file does not use Ivy ranges syntax.
Ivy infact understands and supports the Maven version range syntax. So what you
are seeing in that generated Ivy file is indeed valid Ivy syntax that it will
honour. The only reason why you see the issue that you are currently seeing is
because of the difference in version number comparison algorithm of Ivy and
Maven (which I explained in my previous comment).
In short, Ivy considers "[2.3.0,3.0.0)" and "[2.3.0,3.0.0[" one and the same.
i.e. version greater than or equal to 2.3.0 and lesser than 3.0.0. I just added
a testcase in the Ivy project to prove/verify this exact version range
https://github.com/apache/ant-ivy/commit/2cf83cc35ab1bd8b2fa9d968e879f7b488072642/
> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with
> this in your Ivy file:
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1623) Are @ symbols reserved in revision strings?
[
https://issues.apache.org/jira/browse/IVY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17271357#comment-17271357
]
Jaikiran Pai commented on IVY-1623:
---
>From what I can see in the code and its history, I'm not sure why that check
>is there. The "workspaceName" is an internal detail and shouldn't have
>impacted this dependency resolution. I can't seem to find any document which
>states taht the use of "@" is disallowed in versions. I'll try and spend some
>time on the code to understand what it's trying to do, in the coming days and
>see if we can come with a fix without introducing any regressions.
> Are @ symbols reserved in revision strings?
> ---
>
> Key: IVY-1623
> URL: https://issues.apache.org/jira/browse/IVY-1623
> Project: Ivy
> Issue Type: Question
> Environment: Plain ivy 2.5.0 on the command line, no ant or IDE.
>Reporter: Dave
>Priority: Major
>
> I'm trying to set a dependency with a revision containing multiple @ symbols.
> The naming of these revision strings is outwith my control, so no lectures
> please!
> Here's my simplified ivy.xml:
> {{}}
> {{}}
> {{ }}
> {{ }}
> {{ rev="1.70.0_pkg159@win32@cpp_3_3.3@msvc_141@msvc_141@msvc_15@x86-64" />}}
> {{ }}
> {{}}
> When I attempt to retrieve the dependencies I get the following:
> {{ ERRORS}}
> {{my-url-resolver: unhandled revision =>
> 1.70.0_pkg159@win32@cpp_3_3.3@msvc_141@msvc_141@msvc_15@x86-64}}
> This appears to be due to code in {{BasicResolver}} that checks for the
> presence of an @, and if it's not followed by the "workspaceName", throws the
> above error.
> So, is @ a reserved character? I don't see any mention this in the ivy
> documentation.
> The "workspaceName" doesn't appear to be referenced within ivy itself, so
> what's it for?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1614) Ivy needs to translate Maven version ranges
[
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270099#comment-17270099
]
Jaikiran Pai commented on IVY-1614:
---
I had a deeper look at this one and the related code. This issue doesn't have
to do with the apparent syntax difference of version range specifiers. Turns
out this issue boils down to the version number comparison algorithm that Ivy
uses. Ivy, as noted in the doc[1], for "latest-revision" strategy:
"compares the revisions as strings, using an algorithm close to the one used in
PHP version_compare function"
The specific example in this issue uses the org.eclipse.emf:common module with
a version range [2.3.0,3.0.0). The Maven central repo has 2.1.0 and
2.3.0-v200706262000 versions for this module (in the maven-metadata.xml). Ivy
does identify 2.3.0-v200706262000 as a potential match. This potential match is
then compared against the version range that is specified [2.3.0,3.0.0) in this
case. It compares 2.3.0-v200706262000 against 2.3.0 (the lower range) and the
result of this comparison states that 2.3.0-v200706262000 is "lesser" than
2.3.0, so Ivy rejects this version. This result matches the result of php
version_compare function that the code follows (as documented). Of course, this
contradicts to what Maven tool does with version comparisons (it considers
2.3.0-v200706262000 "greater" than 2.3.0). So that's why it works with Maven
but not in Ivy.
On a related note, you can see that the version range specifier syntax isn't
the cause of this issue, because in the example you mention, Ivy does
successfully resolve the dependency:
it's only the following two dependencies:
where it goes wrong due the version compare logic.
[1] https://ant.apache.org/ivy/history/2.5.0/settings/latest-strategies.html
> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with
> this in your Ivy file:
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IVY-1622) Support for Gradle Module Metadata in install task
[ https://issues.apache.org/jira/browse/IVY-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai reassigned IVY-1622: - Assignee: Jaikiran Pai > Support for Gradle Module Metadata in install task > -- > > Key: IVY-1622 > URL: https://issues.apache.org/jira/browse/IVY-1622 > Project: Ivy > Issue Type: Improvement >Affects Versions: 2.5.0 >Reporter: Björn Kautler >Assignee: Jaikiran Pai >Priority: Major > > Gradle since some time introduced its own metadata file for artifacts, as > poms were simply not rich enough and not extensible. > How it works is, that in the pom or ivy file a reference to the metadata file > is present. If the resolver of Gradle finds this reference, it uses the > metadata file. > We use the Ivy install task to assemble an internal Ivy repository from > public Maven or ivy repositories. But this means, that the Gradle module > metadata is lost which is a real pity. > It would be nice if the Ivy install task could translate this reference to > the produced ivy file and if found also download the module metadata file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IVY-1622) Support for Gradle Module Metadata in install task
[ https://issues.apache.org/jira/browse/IVY-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269321#comment-17269321 ] Jaikiran Pai commented on IVY-1622: --- Thank you for those links. Those are official enough. > Support for Gradle Module Metadata in install task > -- > > Key: IVY-1622 > URL: https://issues.apache.org/jira/browse/IVY-1622 > Project: Ivy > Issue Type: Improvement >Affects Versions: 2.5.0 >Reporter: Björn Kautler >Priority: Major > > Gradle since some time introduced its own metadata file for artifacts, as > poms were simply not rich enough and not extensible. > How it works is, that in the pom or ivy file a reference to the metadata file > is present. If the resolver of Gradle finds this reference, it uses the > metadata file. > We use the Ivy install task to assemble an internal Ivy repository from > public Maven or ivy repositories. But this means, that the Gradle module > metadata is lost which is a real pity. > It would be nice if the Ivy install task could translate this reference to > the produced ivy file and if found also download the module metadata file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IVY-1614) Ivy needs to translate Maven version ranges
[
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269263#comment-17269263
]
Jaikiran Pai commented on IVY-1614:
---
Thank you. I'll spend some time on this.
> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with
> this in your Ivy file:
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1622) Support for Gradle Module Metadata in install task
[
https://issues.apache.org/jira/browse/IVY-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269173#comment-17269173
]
Jaikiran Pai commented on IVY-1622:
---
Looking at
[https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html#sub:interactions-other-build-tools,]
it states:
```
the {{pom.xml}} or {{ivy.xml}} file will contain a _marker comment_ which tells
Gradle that Gradle Module Metadata exists for this module
```
However, I can't find any official document which states what that marker
comment is. Looking at the sample pom you mention, it looks like the marker is
something along the lines of:
```
```
Do you know of any official document which states what the marker comment is
supposed to be?
> Support for Gradle Module Metadata in install task
> --
>
> Key: IVY-1622
> URL: https://issues.apache.org/jira/browse/IVY-1622
> Project: Ivy
> Issue Type: Improvement
>Affects Versions: 2.5.0
>Reporter: Björn Kautler
>Priority: Major
>
> Gradle since some time introduced its own metadata file for artifacts, as
> poms were simply not rich enough and not extensible.
> How it works is, that in the pom or ivy file a reference to the metadata file
> is present. If the resolver of Gradle finds this reference, it uses the
> metadata file.
> We use the Ivy install task to assemble an internal Ivy repository from
> public Maven or ivy repositories. But this means, that the Gradle module
> metadata is lost which is a real pity.
> It would be nice if the Ivy install task could translate this reference to
> the produced ivy file and if found also download the module metadata file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1614) Ivy needs to translate Maven version ranges
[
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269166#comment-17269166
]
Jaikiran Pai commented on IVY-1614:
---
That command won't even run. It ends up with a `ivy file not found: ivy.xml`.
Plus, I would much rather have the reproducer from the original reporter (which
is you in this case) than one of us guessing.
> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with
> this in your Ivy file:
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1614) Ivy needs to translate Maven version ranges
[
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269132#comment-17269132
]
Jaikiran Pai commented on IVY-1614:
---
Hello [~vampire] , would it be possible to attach a simple reproducer to this
issue? That will help in being sure that we are looking into the right issue
and proper fix. Of course, I could come up with a sample build myself, but
having a reproducer makes it much more quicker and easier to work on it.
> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with
> this in your Ivy file:
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IVY-1621) Create maven-metadata.xml in Maven repository (Nexus)
[
https://issues.apache.org/jira/browse/IVY-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai reassigned IVY-1621:
-
Assignee: Jaikiran Pai
> Create maven-metadata.xml in Maven repository (Nexus)
> -
>
> Key: IVY-1621
> URL: https://issues.apache.org/jira/browse/IVY-1621
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.5.0
> Environment: * ivy 2.4.0 or 2.5.0
> * Sonatype Nexus 3.x repo manager
> * ant 1.10
>Reporter: Alexander Ziller
>Assignee: Jaikiran Pai
>Priority: Major
>
> h1. Goal:
> Use ivy dependency management where dependency has revision
> "latest.integration"
>
> h1. Problems:
> Ivy cannot find the artifact with revision "latest.integration".
>
> h1. Cause:
> Ivy uses 2 methods to find the revision "latest.integration" depending on
> setting "useMavenMetadata":
> *true*
> ivy attempts to load the file "maven-metadata.xml" which was supposed to be
> generated by the client uploading the artifact (in this case: ivy!).
> {color:#de350b}This fails as IVY does not generate/upload the
> maven-metadata.xml file in the repository{color}
> *false*
> ivy attempts to do a HTML listing of the directory of the artifact.
> {color:#de350b}This fails because in Nexus3 the HTML browsing of the repo
> uses another base URL than it was done in Nexus2 or the Maven Repo{color}
>
> h1. {color:#172b4d}possible Solution:{color}
>
> {color:#172b4d}During upload of an artifact (especially SNAPSHOT) let IVY
> generate and upload the maven-metadata.xml as well so it can use its own
> logic during download to find the correct version.{color}
>
> h1. {color:#172b4d}Further details:{color}
>
> {color:#172b4d}another developer also found this problem and created an
> example code to verify the behavior:{color}
> {color:#172b4d}[https://github.com/dgeissl/nexus-ivy-example]{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1621) Create maven-metadata.xml in Maven repository (Nexus)
[
https://issues.apache.org/jira/browse/IVY-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17246494#comment-17246494
]
Jaikiran Pai commented on IVY-1621:
---
Failure of Ivy against Nexus 3 seems to be an major issue. I haven't had a
chance to look into Nexus 3. I don't have a Nexus 3 (prod) installation handy
to try out a few things. If there are some public facing Nexus 3 instances that
I can check out and try this against, please do let me know. In the meantime, I
will try and install Nexus 3 locally one of these days to give it a try.
> Create maven-metadata.xml in Maven repository (Nexus)
> -
>
> Key: IVY-1621
> URL: https://issues.apache.org/jira/browse/IVY-1621
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.5.0
> Environment: * ivy 2.4.0 or 2.5.0
> * Sonatype Nexus 3.x repo manager
> * ant 1.10
>Reporter: Alexander Ziller
>Priority: Major
>
> h1. Goal:
> Use ivy dependency management where dependency has revision
> "latest.integration"
>
> h1. Problems:
> Ivy cannot find the artifact with revision "latest.integration".
>
> h1. Cause:
> Ivy uses 2 methods to find the revision "latest.integration" depending on
> setting "useMavenMetadata":
> *true*
> ivy attempts to load the file "maven-metadata.xml" which was supposed to be
> generated by the client uploading the artifact (in this case: ivy!).
> {color:#de350b}This fails as IVY does not generate/upload the
> maven-metadata.xml file in the repository{color}
> *false*
> ivy attempts to do a HTML listing of the directory of the artifact.
> {color:#de350b}This fails because in Nexus3 the HTML browsing of the repo
> uses another base URL than it was done in Nexus2 or the Maven Repo{color}
>
> h1. {color:#172b4d}possible Solution:{color}
>
> {color:#172b4d}During upload of an artifact (especially SNAPSHOT) let IVY
> generate and upload the maven-metadata.xml as well so it can use its own
> logic during download to find the correct version.{color}
>
> h1. {color:#172b4d}Further details:{color}
>
> {color:#172b4d}another developer also found this problem and created an
> example code to verify the behavior:{color}
> {color:#172b4d}[https://github.com/dgeissl/nexus-ivy-example]{color}
>
--
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=16980276#comment-16980276
]
Jaikiran Pai commented on IVY-1616:
---
Thank you for confirming. I'll take a look and come up with a fix.
> 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-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=16979766#comment-16979766
]
Jaikiran Pai commented on IVY-1616:
---
Hello Eric, just to be sure, this metadata in the cache was generated by this
new version of Ivy 2.5.0, right? I mean, the cache was new when this project
was built? We had some issues in a previous version of Ivy which would cause
metadata parsing issues, so just checking, before I look more into this.
> 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] [Assigned] (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
]
Jaikiran Pai reassigned IVY-1616:
-
Assignee: Jaikiran Pai
> 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-1607) Apache IVYDE 2.5.0.cr1 does not resolve correctly.
[
https://issues.apache.org/jira/browse/IVY-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16966393#comment-16966393
]
Jaikiran Pai commented on IVY-1607:
---
Thank you for confirming.
> Apache IVYDE 2.5.0.cr1 does not resolve correctly.
> --
>
> Key: IVY-1607
> URL: https://issues.apache.org/jira/browse/IVY-1607
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Michael Breu
>Priority: Major
> Fix For: 2.5.0
>
> Attachments: Ivy2.5.0.5rcTests.zip
>
>
> Sorry, to cross post the issue IVYDE-391 here, however the IVYDE project does
> not seem to react on this issue in Apache Ivy 2.5.0.cr1_20180412005305 (and
> even has no reference to version 2.5.0.cr1), and I'm not sure, whether the
> problem is rooted in in 2.5.0-rc1 .
> On https://www.apache.org/dist/ant/ivyde/updatesite/ the apache Ivy library
> "Apache Ivy 2.5.0.cr1_20180412005305" is provided, and it seems that this is
> now installed as default, because it is the newest version. (BTW: it seems
> that it is published as *cr* (change request?), not as *rc* (release
> candidate?))
>
> However: It does not resolve certain dependencies correclty. E.g
> {{ {{version="2.1" }}
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd;
> >
> organisation="Ivy Test"
> module="Ivy250rcTest"
> status="integration">
>
>
>
>
>
>
>
>
> rev="2.12.0" conf="*->runtime"/>
>
> rev="2.12.0" conf="*->default"/>
>
> rev="2.12.0" conf="*->default"/>
>
>
>
> does not resolve log4j-core.jar, although included.
>
> Find enclosed a simple eclipse project that demonstrates this issue.
>
> If you can reproduce this problem, please withdraw version IVYDE 2.5.0.cr...
> . It spoils every installation and it seems very hard to reset to a previous
> version.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IVYDE-391) Apache IVY 2.5.0.cr1 does not resolve correctly.
[
https://issues.apache.org/jira/browse/IVYDE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai resolved IVYDE-391.
Resolution: Fixed
Resolved through https://issues.apache.org/jira/browse/IVY-1607
> Apache IVY 2.5.0.cr1 does not resolve correctly.
>
>
> Key: IVYDE-391
> URL: https://issues.apache.org/jira/browse/IVYDE-391
> Project: IvyDE
> Issue Type: Bug
> Components: classpath container
>Affects Versions: master
> Environment: # I tested it with
> #
> # Version: Oxygen.3a Release (4.7.3a) [but I also reproduced it in recent
> Eclipse 2019 06]
> #
> # *** Features:
> # org.apache.ivyde.feature (2.3.1.201703031747) "Apache IvyDE"
> #
> # org.apache.ivy (2.5.0.cr1_20180412005306) "Ivy" [Resolved]
> # org.apache.ivy.eclipse.ant (2.5.0.cr1_20180412005306) "Apache Ivy Ant
> Plugin" [Resolved]
> # org.apache.ivyde.eclipse (2.3.1.201703031747) "Apache IvyDE" [Active]
> # org.apache.ivyde.eclipse.resolvevisualizer (2.3.0.201703031747) "Apache
> IvyDE Resolve
> #
> # *** User Preferences:
> # #Fri Aug 02 18:55:42 CEST 2019
> # \!/=
> #
> /bundle_defaults/org.apache.ivyde.eclipse/acceptedTypes=jar,bundle,ejb,maven-plugin
> # /bundle_defaults/org.apache.ivyde.eclipse/autoResolve.change=true
> # /bundle_defaults/org.apache.ivyde.eclipse/autoResolve.close=true
> # /bundle_defaults/org.apache.ivyde.eclipse/autoResolve.open=false
> # /bundle_defaults/org.apache.ivyde.eclipse/booleanPreference=true
> # /bundle_defaults/org.apache.ivyde.eclipse/choicePreference=choice2
> # /bundle_defaults/org.apache.ivyde.eclipse/editor.color.default=0,0,0
> # /bundle_defaults/org.apache.ivyde.eclipse/editor.color.procInstr=128,128,128
> # /bundle_defaults/org.apache.ivyde.eclipse/editor.color.string=0,128,0
> # /bundle_defaults/org.apache.ivyde.eclipse/editor.color.tag=0,0,128
> # /bundle_defaults/org.apache.ivyde.eclipse/editor.color.xmlComment=128,0,0
> # /bundle_defaults/org.apache.ivyde.eclipse/error.popup=true
> # /bundle_defaults/org.apache.ivyde.eclipse/ivuUserDir=
> # /bundle_defaults/org.apache.ivyde.eclipse/ivyConsole.ivyDELogLevel=2
> # /bundle_defaults/org.apache.ivyde.eclipse/ivyConsole.logLevel=2
> # /bundle_defaults/org.apache.ivyde.eclipse/ivyConsole.openOnStartup=false
> # /bundle_defaults/org.apache.ivyde.eclipse/ivy_conf_path=
> # /bundle_defaults/org.apache.ivyde.eclipse/ivy_org=
> # /bundle_defaults/org.apache.ivyde.eclipse/ivy_org_url=
> #
> /bundle_defaults/org.apache.ivyde.eclipse/javadocSuffixes=-javadoc,-javadocs,-doc,-docs
> # /bundle_defaults/org.apache.ivyde.eclipse/javadocTypes=javadoc
> # /bundle_defaults/org.apache.ivyde.eclipse/loadSettingsOnDemand=false
> # /bundle_defaults/org.apache.ivyde.eclipse/mapIfOnlyOneJavadoc=false
> # /bundle_defaults/org.apache.ivyde.eclipse/mapIfOnlyOneSource=false
> # /bundle_defaults/org.apache.ivyde.eclipse/offline=false
> # /bundle_defaults/org.apache.ivyde.eclipse/order.alphabetical=false
> # /bundle_defaults/org.apache.ivyde.eclipse/propertyFiles=
> # /bundle_defaults/org.apache.ivyde.eclipse/readOSGIMetadata=false
> # /bundle_defaults/org.apache.ivyde.eclipse/resolveBeforeLaunch=false
> # /bundle_defaults/org.apache.ivyde.eclipse/resolveInWorkspace=false
> # /bundle_defaults/org.apache.ivyde.eclipse/resolveOnStartup=0
> # /bundle_defaults/org.apache.ivyde.eclipse/retrievedClasspath=false
> #
> /bundle_defaults/org.apache.ivyde.eclipse/retrievedClasspath.pattern=lib/[artifact]-[revision].[ext]
> # /bundle_defaults/org.apache.ivyde.eclipse/retrievedClasspath.sync=false
> # /bundle_defaults/org.apache.ivyde.eclipse/retrievedClasspath.types=jar
> #
> /bundle_defaults/org.apache.ivyde.eclipse/sourceSuffixes=-source,-sources,-src
> # /bundle_defaults/org.apache.ivyde.eclipse/sourceTypes=source
> # /bundle_defaults/org.apache.ivyde.eclipse/stringPreference=Default value
> # /bundle_defaults/org.apache.ivyde.eclipse/transitiveResolve=true
> #
> /bundle_defaults/org.apache.ivyde.eclipse/workspaceResolver.ignoreBranch=false
> #
> /bundle_defaults/org.apache.ivyde.eclipse/workspaceResolver.ignoreVersion=false
> #
> #
>Reporter: Michael Breu
>Priority: Major
> Attachments: Ivy2.5.0.5rcTests.zip
>
>
> On [https://www.apache.org/dist/ant/ivyde/updatesite/] the apache Ivy library
> "Apache Ivy 2.5.0.cr1_20180412005305" is provided, and it seems that this is
> now installed as default, because it is the newest version.
>
> However: It does not resolve certain dependencies correclty. E.g
> {{ {{ version="2.1" }}
> {{ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
> {{
> xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd"}}
> {{>}}
> {{ {{ organisation="Ivy Test"}}
> {{ module="Ivy250rcTest"}}
> {{ status="integration">}}
> {{ }}
> {{ }}
> {{ }}
> {{
[jira] [Resolved] (IVY-1574) publish sha512 sums with releases
[ https://issues.apache.org/jira/browse/IVY-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai resolved IVY-1574. --- Fix Version/s: 2.5.0 Resolution: Fixed Recently release 2.5.0 of Ivy publishes SHA512 checksums too. > publish sha512 sums with releases > - > > Key: IVY-1574 > URL: https://issues.apache.org/jira/browse/IVY-1574 > Project: Ivy > Issue Type: Task > Components: Maven Compatibility >Affects Versions: 2.4.0 >Reporter: Mike Drob >Assignee: Jaikiran Pai >Priority: Major > Fix For: 2.5.0 > > > according to > http://www.apache.org/dev/release-distribution.html#sigs-and-sums it would be > nice to have sha512 sums published for release artifacts. > looking at http://www.apache.org/dist/ant/ivy/2.4.0/ and > http://www.apache.org/dist/ant/ivy/2.4.0/maven2/2.4.0/ there are only sha1 > sums posted -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IVY-1571) resolve loops and throws StackOverflowError
[ https://issues.apache.org/jira/browse/IVY-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai resolved IVY-1571. --- Resolution: Incomplete > resolve loops and throws StackOverflowError > --- > > Key: IVY-1571 > URL: https://issues.apache.org/jira/browse/IVY-1571 > Project: Ivy > Issue Type: Bug >Reporter: Naresh >Priority: Major > > Hi, > We have 40+ modules, for some of modules, while resolving the "commons-io" > and "httpclient" dependencies, it loops and throws StackOverflowError > Can you please help with this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IVY-1583) Consecutive calls to 'ivy:retrieve' on the same project does not retrieve all artifacts
[
https://issues.apache.org/jira/browse/IVY-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965597#comment-16965597
]
Jaikiran Pai commented on IVY-1583:
---
Hello [~nlenzi] , is this reproducible against the recently released 2.5.0
version of Ivy https://www.mail-archive.com/dev@ant.apache.org/msg48240.html?
> Consecutive calls to 'ivy:retrieve' on the same project does not retrieve all
> artifacts
> ---
>
> Key: IVY-1583
> URL: https://issues.apache.org/jira/browse/IVY-1583
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc1
>Reporter: Nicholas Lenzi
>Priority: Major
>
> Our group is currently using ivy 2.4.0, and evaluated 2.5.0-rc1.
> We were able to work around this issue by modifying the ivy.xml file for all
> effected modules. Seems like bug.
> Before
> {noformat}
>
> conf="compile->default" />
>
> {noformat}
> After
> {noformat}
>
> conf="compile->default" >
>
>
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1607) Apache IVYDE 2.5.0.cr1 does not resolve correctly.
[
https://issues.apache.org/jira/browse/IVY-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965596#comment-16965596
]
Jaikiran Pai commented on IVY-1607:
---
[~Wallenstein61], Ivy 2.5.0 has been released recently
[https://www.mail-archive.com/dev@ant.apache.org/msg48240.html.] Can you check
if the issue you reported has been resolved with IvyDE picking up this new
latest version of Ivy?
> Apache IVYDE 2.5.0.cr1 does not resolve correctly.
> --
>
> Key: IVY-1607
> URL: https://issues.apache.org/jira/browse/IVY-1607
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Michael Breu
>Priority: Major
> Attachments: Ivy2.5.0.5rcTests.zip
>
>
> Sorry, to cross post the issue IVYDE-391 here, however the IVYDE project does
> not seem to react on this issue in Apache Ivy 2.5.0.cr1_20180412005305 (and
> even has no reference to version 2.5.0.cr1), and I'm not sure, whether the
> problem is rooted in in 2.5.0-rc1 .
> On https://www.apache.org/dist/ant/ivyde/updatesite/ the apache Ivy library
> "Apache Ivy 2.5.0.cr1_20180412005305" is provided, and it seems that this is
> now installed as default, because it is the newest version. (BTW: it seems
> that it is published as *cr* (change request?), not as *rc* (release
> candidate?))
>
> However: It does not resolve certain dependencies correclty. E.g
> {{ {{version="2.1" }}
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd;
> >
> organisation="Ivy Test"
> module="Ivy250rcTest"
> status="integration">
>
>
>
>
>
>
>
>
> rev="2.12.0" conf="*->runtime"/>
>
> rev="2.12.0" conf="*->default"/>
>
> rev="2.12.0" conf="*->default"/>
>
>
>
> does not resolve log4j-core.jar, although included.
>
> Find enclosed a simple eclipse project that demonstrates this issue.
>
> If you can reproduce this problem, please withdraw version IVYDE 2.5.0.cr...
> . It spoils every installation and it seems very hard to reset to a previous
> version.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IVY-1584) 'ivy:resolve' fails on spring-boot-starter
[
https://issues.apache.org/jira/browse/IVY-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai resolved IVY-1584.
---
Resolution: Invalid
> 'ivy:resolve' fails on spring-boot-starter
> --
>
> Key: IVY-1584
> URL: https://issues.apache.org/jira/browse/IVY-1584
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc1
>Reporter: Nicholas Lenzi
>Priority: Major
>
> When we attempt to resolve spring-boot-starter, we get an error indicating
> org.springframework.boot tests-jar cannot be resolved. We do not see this
> issue with IVY 2.4.0.
> We were able to work around this issue by changing the ivy.xml. Seems like a
> bug.
> Before:
> {noformat}
>
> rev="1.5.9.RELEASE" conf="compile->default">
>
>
> {noformat}
> After:
> {noformat}
>
> rev="1.5.9.RELEASE" force="true" conf="compile->default"/>
> rev="1.5.9.RELEASE" conf="compile->default">
>
>
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1584) 'ivy:resolve' fails on spring-boot-starter
[
https://issues.apache.org/jira/browse/IVY-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965351#comment-16965351
]
Jaikiran Pai commented on IVY-1584:
---
Hello [~nlenzi] , I'm closing this one since this appears to be an issue with
the published artifacts itself. Please reopen with additional details if you
feel otherwise.
> 'ivy:resolve' fails on spring-boot-starter
> --
>
> Key: IVY-1584
> URL: https://issues.apache.org/jira/browse/IVY-1584
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc1
>Reporter: Nicholas Lenzi
>Priority: Major
>
> When we attempt to resolve spring-boot-starter, we get an error indicating
> org.springframework.boot tests-jar cannot be resolved. We do not see this
> issue with IVY 2.4.0.
> We were able to work around this issue by changing the ivy.xml. Seems like a
> bug.
> Before:
> {noformat}
>
> rev="1.5.9.RELEASE" conf="compile->default">
>
>
> {noformat}
> After:
> {noformat}
>
> rev="1.5.9.RELEASE" force="true" conf="compile->default"/>
> rev="1.5.9.RELEASE" conf="compile->default">
>
>
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1485) Incorrect revision of dependencies put in to delivered Ivy files
[
https://issues.apache.org/jira/browse/IVY-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962026#comment-16962026
]
Jaikiran Pai commented on IVY-1485:
---
[~VIJAY25051991], can you attach an ivy.xml and the relevant build.xml which
reproduces this issue? I want to make sure it's the same issue you are running
into. Also, we just released 2.5.0 last week, so please give your use case a
try against that and see if that works there.
As for this issue in general, I had kept aside this issue while wokring on
releasing 2.5.0, given the complexity involved in this one. Now that 2.5.0 is
released, I'll see if I can come up with a solution for this.
> Incorrect revision of dependencies put in to delivered Ivy files
>
>
> Key: IVY-1485
> URL: https://issues.apache.org/jira/browse/IVY-1485
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0, 2.4.0-RC1
>Reporter: Perrin Morrow
>Assignee: Jaikiran Pai
>Priority: Critical
> Attachments: 0001-Add-test-cases-for-IVY-1485.patch,
> 0002-Ensure-dependency-is-applicable-to-all-confs-of-matc.patch,
> ivy-1485-test-cases.patch
>
>
> Ivy deliver incorrectly replaces top-level dependency revision with one from
> a transitive dependency in a different conf.
> When writing the resolved Ivy properties into the cache, the Ivy
> ResolveEngine does not take into account the top-level confs. If it finds the
> same dependency on any transitive path it will prefer the resolved revision
> of the transitive dependency over that of the top-level dependency even when
> that transitive dependency is being resolved into a completely different
> top-level conf. This results in a delivered Ivy file, that when resolved
> again will pull in the wrong version of that top-level dependency.
> Consider the following Ivy dependency chain:
> {noformat}
> top-level
> [conf1]
> - modA#1
> [conf2]
> - modB#1
> - modA#2
> {noformat}
> Ivy resolve and retrieve will pull modA#1 into conf1 and modA#2 into conf2,
> as expected.
> Ivy deliver, however, will replace modA#1 with modA#2 in the delivered ivy
> descriptor. When that delivered ivy file is resolved again (by some other
> module depending on it) it will pull in modA#2 into both conf1 and conf2.
> This appears to be a regression in Ivy 2.3.0. It did not happen with Ivy
> 2.2.0. (Maybe related to IVY-1300?)
> We have written some test cases that demonstrate the problem (a diff against
> the Git repository master) which I will attach.
> We're also working on a patch to fix this but so far it has proved elusive.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1614) install task needs to translate version ranges
[
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16960241#comment-16960241
]
Jaikiran Pai commented on IVY-1614:
---
Hello [~vampire] , do you have the task usage example where you use the
ivy:install task, which causes this issue?
> install task needs to translate version ranges
> --
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with
> this in your Ivy file:
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IVY-1614) install task needs to translate version ranges
[
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai reassigned IVY-1614:
-
Assignee: Jaikiran Pai
> install task needs to translate version ranges
> --
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with
> this in your Ivy file:
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
> force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IVY-1613) Download page gpg example needs second parameter
[ https://issues.apache.org/jira/browse/IVY-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai resolved IVY-1613. --- Resolution: Fixed Thank you for reporting this. I just updated the page to fix this and also included a link to [https://www.apache.org/info/verification.html.] The page is now live. > Download page gpg example needs second parameter > > > Key: IVY-1613 > URL: https://issues.apache.org/jira/browse/IVY-1613 > Project: Ivy > Issue Type: Bug >Reporter: Sebb >Assignee: Jaikiran Pai >Priority: Major > > The download page has some instructions that are not quite right. > % gpg --verify apache-ivy-2.5.0-bin.tar.gz.asc > should read > % gpg --verify apache-ivy-2.5.0-bin.tar.gz.asc apache-ivy-2.5.0-bin.tar.gz > See https://www.apache.org/info/verification.html#specify_both -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IVY-1613) Download page gpg example needs second parameter
[ https://issues.apache.org/jira/browse/IVY-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai reassigned IVY-1613: - Assignee: Jaikiran Pai > Download page gpg example needs second parameter > > > Key: IVY-1613 > URL: https://issues.apache.org/jira/browse/IVY-1613 > Project: Ivy > Issue Type: Bug >Reporter: Sebb >Assignee: Jaikiran Pai >Priority: Major > > The download page has some instructions that are not quite right. > % gpg --verify apache-ivy-2.5.0-bin.tar.gz.asc > should read > % gpg --verify apache-ivy-2.5.0-bin.tar.gz.asc apache-ivy-2.5.0-bin.tar.gz > See https://www.apache.org/info/verification.html#specify_both -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IVY-1612) Remove old fr\jayasoft\ivy\ant\antlib.xml from the jar
[ https://issues.apache.org/jira/browse/IVY-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai resolved IVY-1612. --- Fix Version/s: master Resolution: Fixed > Remove old fr\jayasoft\ivy\ant\antlib.xml from the jar > --- > > Key: IVY-1612 > URL: https://issues.apache.org/jira/browse/IVY-1612 > Project: Ivy > Issue Type: Task > Components: Ant, Core >Affects Versions: 2.5.0 >Reporter: Jan Materne >Assignee: Jan Materne >Priority: Minor > Fix For: master > > > The antlib definition file fr\jayasoft\ivy\ant\antlib.xml is there since 2007 > for BWC. > Now we should remove that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IVY-1612) Remove old fr\jayasoft\ivy\ant\antlib.xml from the jar
[ https://issues.apache.org/jira/browse/IVY-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai reopened IVY-1612: --- Reopening just to add a "Fix version" > Remove old fr\jayasoft\ivy\ant\antlib.xml from the jar > --- > > Key: IVY-1612 > URL: https://issues.apache.org/jira/browse/IVY-1612 > Project: Ivy > Issue Type: Task > Components: Ant, Core >Affects Versions: 2.5.0 >Reporter: Jan Materne >Assignee: Jan Materne >Priority: Minor > > The antlib definition file fr\jayasoft\ivy\ant\antlib.xml is there since 2007 > for BWC. > Now we should remove that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IVY-1612) Remove old fr\jayasoft\ivy\ant\antlib.xml from the jar
[ https://issues.apache.org/jira/browse/IVY-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai closed IVY-1612. - > Remove old fr\jayasoft\ivy\ant\antlib.xml from the jar > --- > > Key: IVY-1612 > URL: https://issues.apache.org/jira/browse/IVY-1612 > Project: Ivy > Issue Type: Task > Components: Ant, Core >Affects Versions: 2.5.0 >Reporter: Jan Materne >Assignee: Jan Materne >Priority: Minor > Fix For: master > > > The antlib definition file fr\jayasoft\ivy\ant\antlib.xml is there since 2007 > for BWC. > Now we should remove that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IVY-1141) dependencies failed using branch attribute (and extra attributes)
[
https://issues.apache.org/jira/browse/IVY-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai updated IVY-1141:
--
Fix Version/s: (was: master)
> dependencies failed using branch attribute (and extra attributes)
> -
>
> Key: IVY-1141
> URL: https://issues.apache.org/jira/browse/IVY-1141
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.0
> Environment: windows
>Reporter: Danny Angus
>Assignee: Nicolas Lalevée
>Priority: Major
> Labels: patch
> Attachments: basic-resolver-patch.diff, branch-fix.diff
>
>
> *** Investigation
> i tried to use the branch attribute inside my projekt DEV like this:
>
> branch="mybranch1" rev="latest.integration"
> conf="compile,tests->default"/>
> .
> If I now try to resolve my dependencies, it failed
> because ivy 2.1.0 try to resolve the latest version (5.6) of testng/testng
> which has NO branch-keyword inside it's ivy.xml. The ivy.xml
> of version testng/testng/4.6 contains the following:
>
> organisation="testng" module="testng"
> branch="mybranch1" revision="4.6.1.2"
> status="release"
> publication="2006022700">
> .
> It looks like the resolver skip this 4.6.1.2 version (which is the only one
> containing the
> branch attribute "mybranch1") and try to download the 5.6 (containing NO
> branch attribute !).
> I go the following error message:
> [ivy:configure] :: Ivy 2.1.0 - 20090925235825 :: http://ant.apache.org/ivy/ ::
> ...
> -
> [ivy:resolve] :: problems summary ::
> [ivy:resolve] WARNINGS
> [ivy:resolve] ::
> [ivy:resolve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:resolve] ::
> [ivy:resolve] :: testng#testng#mybranch1;latest.integration:
> several problems occured while resolving dependency:
> testng#testng#mybranch1;latest.integration {compile=[default],
> tests=[default]}:
> [ivy:resolve] java.text.ParseException: inconsistent module
> descriptor file found in 'I:\testng\testng\5.6\ivy.xml': bad branch name:
> expected='mybranch1' found='null';
> [ivy:resolve] java.text.ParseException: inconsistent module
> descriptor file found in
> 'http://ivyrepos.dtnet.de/testng/testng/5.6/ivy.xml': bad branch name:
> expected='mybranch1' found='null';
> [ivy:resolve] ::
> [ivy:resolve]
> [ivy:resolve] ERRORS
> [ivy:resolve] shared-filesystem: bad branch name found in
> I:\testng\testng\5.6\ivy.xml: expected='mybranch1 found='null'
> [ivy:resolve] shared-web: bad branch name found in
> http://ivyrepos.dtnet.de/testng/testng/5.6/ivy.xml: expected='mybranch1
> found='null'
> [ivy:resolve]
> [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> *** Make it reproducable
> I create a VERY small sample project (build.xml & ivy.xml)
> using a sample ivyrepos on our server.
> Could somebody look closer to the problem by downloading the project from
> http://www.opensource-online.org/fileadmin/swd/ivy/ivy-test.zip
> To run, yust unzip and start "ant -f build.xml" and you can see the failure:
> [ivy:resolve] ::
> [ivy:resolve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:resolve] ::
> [ivy:resolve] :: testng#testng#mybranch1;latest.integration:
> java.text.ParseException: inconsistent module descriptor file found in 'http:/
> www.opensource-online.org/fileadmin/swd/ivy/testng/testng/5.6/ivy.xml': bad
> branch name: expected='mybranch1' found='';
> [ivy:resolve] ::
> [ivy:resolve]
> [ivy:resolve] ERRORS
> [ivy:resolve] default: bad branch name found in
> http://www.opensource-online.org/fileadmin/swd/ivy/testng/testng/5.6/ivy.xml:
> expected='myb
> anch1 found=''
> [ivy:resolve]
> [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> *** Same problem using extra attributes instead auf branch attribute
> if tried a workaround not using the branch-keyword but defining a own extra
> atrribute like this:
> http://softwaredemo.de/ivy/extra;>
> ...
>rev="latest.integration"
> conf="compile,tests->default"/>
> But this tells me a similar result - also a failure.
>
[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=16955126#comment-16955126 ] Jaikiran Pai commented on IVY-1586: --- > No javadocs, sources, etc. are downloaded to the ivy cache. That had me worried a bit. So I checked the Nutch project and its ivy.xml and ivysettings.xml. The dependencies have been configured (with default configuration mappings) such that the source, javadocs confs aren't pulled in by dependencies. As a result the sources and javadocs jars aren't pulled in and the current retrieve pattern used that is enough for it to succeed. > A final comment: the [ivy retrieve > docs|https://ant.apache.org/ivy/history/latest-milestone/use/retrieve.html] > mention mostly patterns without "type" or "classifier". Might need a clear > hint as many libs are shipped with javadocs and sources. I'll see what we can do there and add a note in the relevant place. > 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-1586-test.zip, 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=16952870#comment-16952870 ] Jaikiran Pai commented on IVY-1586: --- I had a look a the attached sample. It uses the following retrieve pattern "lib/[conf]/[artifact]-[revision].[ext]". Some of the artifacts from the dependencies have "source" and "javadoc" type artifacts which too get pulled in during retrieve. These artifacts are of a different "type". However, since the retrieve pattern you use doesn't take that into account, the target file to which they will be retrieved will end up being the same as that of the original jar. So it's really an issue in the retrieve pattern being used in that example. You can instead use "lib/[conf]/[type]/[artifact]-[revision].[ext]" > 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-1586-test.zip, 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=16952026#comment-16952026 ] Jaikiran Pai commented on IVY-1586: --- I remember trying your very own attached project to get this working. Before I verify it again, just one quick question - you tried this against a clean/fresh Ivy cache right? > 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-1586-test.zip, 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-1609) Removal of WARN deprecation when not valid
[
https://issues.apache.org/jira/browse/IVY-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949884#comment-16949884
]
Jaikiran Pai commented on IVY-1609:
---
Hello Greg,
You are right - it should only be logged when someone uses it. That message
isn't expected to be logged if no one is calling the setMakeSymlinksInMass
(directly or indirectly). So I had a look at the code and the only time this
method gets called is, if some did indeed use the `symlinkmass` option - either
by passing `symlinkmass` as a command line option to Main or setting the
symlinkmass option of retrieve task.
Are you certain that in the embedded case, the `symlinkmass` isn't being passed
to Main class or even retrieve task?
> Removal of WARN deprecation when not valid
> --
>
> Key: IVY-1609
> URL: https://issues.apache.org/jira/browse/IVY-1609
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Greg Perry
>Assignee: Jaikiran Pai
>Priority: Minor
> Labels: easyfix
>
> "WARN: symlinkmass option has been deprecated and will no longer be
> supported" gets fed back as a problem message, even when this option is not
> set.
> I noticed this when trying to get integration to work with embedding ivy.
> The program which utilizes ivy checks ResolveReport.getAllProblemMessages()
> after a resolve/retrieve is done.
> It assumes something did not go correctly.
> I don't think its appropriate to send this back in getAllProblemMessages when
> the symlinkmass is not set.
> This could be fixed simply by testing if symlinkmass is being set to true in
> the option
> RetrieveOptions.java line 184
> https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/retrieve/RetrieveOptions.java#L183-L188
>
> @Deprecated
> public RetrieveOptions setMakeSymlinksInMass(boolean makeSymlinksInMass) {
> this.makeSymlinksInMass = makeSymlinksInMass;
> *if (makeSymlinksInMass) {*
> Message.warn("symlinkmass option has been deprecated and will no
> longer be supported");
> *}*
> return this;
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IVY-1609) Removal of WARN deprecation when not valid
[
https://issues.apache.org/jira/browse/IVY-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaikiran Pai reassigned IVY-1609:
-
Assignee: Jaikiran Pai
> Removal of WARN deprecation when not valid
> --
>
> Key: IVY-1609
> URL: https://issues.apache.org/jira/browse/IVY-1609
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Greg Perry
>Assignee: Jaikiran Pai
>Priority: Minor
> Labels: easyfix
>
> "WARN: symlinkmass option has been deprecated and will no longer be
> supported" gets fed back as a problem message, even when this option is not
> set.
> I noticed this when trying to get integration to work with embedding ivy.
> The program which utilizes ivy checks ResolveReport.getAllProblemMessages()
> after a resolve/retrieve is done.
> It assumes something did not go correctly.
> I don't think its appropriate to send this back in getAllProblemMessages when
> the symlinkmass is not set.
> This could be fixed simply by testing if symlinkmass is being set to true in
> the option
> RetrieveOptions.java line 184
> https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/retrieve/RetrieveOptions.java#L183-L188
>
> @Deprecated
> public RetrieveOptions setMakeSymlinksInMass(boolean makeSymlinksInMass) {
> this.makeSymlinksInMass = makeSymlinksInMass;
> *if (makeSymlinksInMass) {*
> Message.warn("symlinkmass option has been deprecated and will no
> longer be supported");
> *}*
> return this;
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IVY-1609) Removal of WARN deprecation when not valid
[
https://issues.apache.org/jira/browse/IVY-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949137#comment-16949137
]
Jaikiran Pai commented on IVY-1609:
---
Hello Greg,
Are you saying that this message gets logged when the `makeSymlinksInMass`
attribute isn't being used (irrespective of the value)? The reason we added
that message is to prevent users from using that attribute or the setter
(irrespective of the value), so that we can just get rid of that setter in a
future version. This will give users a chance to be aware that this
method/attribute isnt' supposed to be used.
> Removal of WARN deprecation when not valid
> --
>
> Key: IVY-1609
> URL: https://issues.apache.org/jira/browse/IVY-1609
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Greg Perry
>Priority: Minor
> Labels: easyfix
>
> "WARN: symlinkmass option has been deprecated and will no longer be
> supported" gets fed back as a problem message, even when this option is not
> set.
> I noticed this when trying to get integration to work with embedding ivy.
> The program which utilizes ivy checks ResolveReport.getAllProblemMessages()
> after a resolve/retrieve is done.
> It assumes something did not go correctly.
> I don't think its appropriate to send this back in getAllProblemMessages when
> the symlinkmass is not set.
> This could be fixed simply by testing if symlinkmass is being set to true in
> the option
> RetrieveOptions.java line 184
> https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/retrieve/RetrieveOptions.java#L183-L188
>
> @Deprecated
> public RetrieveOptions setMakeSymlinksInMass(boolean makeSymlinksInMass) {
> this.makeSymlinksInMass = makeSymlinksInMass;
> *if (makeSymlinksInMass) {*
> Message.warn("symlinkmass option has been deprecated and will no
> longer be supported");
> *}*
> return this;
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IVY-1610) Invalid collision should not error retrieve
[ https://issues.apache.org/jira/browse/IVY-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai reassigned IVY-1610: - Assignee: Jaikiran Pai > Invalid collision should not error retrieve > --- > > Key: IVY-1610 > URL: https://issues.apache.org/jira/browse/IVY-1610 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.5.0-rc1 >Reporter: Greg Perry >Assignee: Jaikiran Pai >Priority: Major > > I get the following master branch: > *Multiple artifacts of the module com.google.protobuf#protobuf-java;3.4.0 are > retrieved to the same file! Update the retrieve pattern to fix this error* > The retrieve pattern I am using is : > *[originalname].[ext]* > within my Ivy.xml file I'm not directly pulling in the dependency of > protobuf, so its coming in as a transitive (probably twice or even 3 times) > I suspect 2 transitives are using the same library and the retrieve is upset > because it will be overwriting it. > If 2 or more transitives have the same groupId, artifactId, and versionId, > they effectively "are" the same file - so retrieve should not error out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IVY-1610) Invalid collision should not error retrieve
[ https://issues.apache.org/jira/browse/IVY-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaikiran Pai resolved IVY-1610. --- Fix Version/s: master Resolution: Fixed I think this is the same as what Sebastian mentioned in one of the comments in IVY-1586. I have pushed a fix for it as noted here https://issues.apache.org/jira/browse/IVY-1586?focusedCommentId=16949134=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16949134 > Invalid collision should not error retrieve > --- > > Key: IVY-1610 > URL: https://issues.apache.org/jira/browse/IVY-1610 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.5.0-rc1 >Reporter: Greg Perry >Assignee: Jaikiran Pai >Priority: Major > Fix For: master > > > I get the following master branch: > *Multiple artifacts of the module com.google.protobuf#protobuf-java;3.4.0 are > retrieved to the same file! Update the retrieve pattern to fix this error* > The retrieve pattern I am using is : > *[originalname].[ext]* > within my Ivy.xml file I'm not directly pulling in the dependency of > protobuf, so its coming in as a transitive (probably twice or even 3 times) > I suspect 2 transitives are using the same library and the retrieve is upset > because it will be overwriting it. > If 2 or more transitives have the same groupId, artifactId, and versionId, > they effectively "are" the same file - so retrieve should not error out. -- 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=16949134#comment-16949134 ] Jaikiran Pai commented on IVY-1586: --- [~snagel], I just pushed a fix which I believe should fix the "Multiple artifacts of the module .. are retrieved to the same file!". It was a genuine bug. Thank you for reporting it. As usual please try the latest nightly when you get a chance. I plan to release Ivy soon, so it would be good to have this verified. > 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-1586-test.zip, 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-1610) Invalid collision should not error retrieve
[ https://issues.apache.org/jira/browse/IVY-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949094#comment-16949094 ] Jaikiran Pai commented on IVY-1610: --- Hello Greg, Is there a ivy.xml that you can attach which reproduces this? > Invalid collision should not error retrieve > --- > > Key: IVY-1610 > URL: https://issues.apache.org/jira/browse/IVY-1610 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.5.0-rc1 >Reporter: Greg Perry >Priority: Major > > I get the following master branch: > *Multiple artifacts of the module com.google.protobuf#protobuf-java;3.4.0 are > retrieved to the same file! Update the retrieve pattern to fix this error* > The retrieve pattern I am using is : > *[originalname].[ext]* > within my Ivy.xml file I'm not directly pulling in the dependency of > protobuf, so its coming in as a transitive (probably twice or even 3 times) > I suspect 2 transitives are using the same library and the retrieve is upset > because it will be overwriting it. > If 2 or more transitives have the same groupId, artifactId, and versionId, > they effectively "are" the same file - so retrieve should not error out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IVY-1611) Need embedded way of getting log messages
[ https://issues.apache.org/jira/browse/IVY-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949089#comment-16949089 ] Jaikiran Pai commented on IVY-1611: --- > In 2.4.x - this was possible : > Main.setLogger(new IvyWrapperLogger(Message.MSG_INFO)); I don't see Main.setLogger being available in 2.4.x [https://github.com/apache/ant-ivy/blob/2.4.0/src/java/org/apache/ivy/Main.java.] Are you sure this Main class belongs to Ivy? > Need embedded way of getting log messages > - > > Key: IVY-1611 > URL: https://issues.apache.org/jira/browse/IVY-1611 > Project: Ivy > Issue Type: Bug >Reporter: Greg Perry >Priority: Major > > In 2.4.x - this was possible : > Main.setLogger(new IvyWrapperLogger(Message.MSG_INFO)); > And allowed logging messages to be propagated to the host application. > Now setLogger is either gone or private. > I tried this in 2.5.x > ivy.getLoggerEngine().pushLogger(new IvyWrapperLogger(Message.MSG_INFO)); > but I suspect it gets "popped" before > ResolveReport report = Main.run(cmd)is called -- 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=16937563#comment-16937563 ] jaikiran pai commented on IVY-1586: --- I'll look at the project in a while, but a quick thing: >> I have still troubles to get the Nutch build running using the nightly ivy >> jar (2.5.0-rc2-local-20190908122243). Can you try with a more recent one instead from here [https://builds.apache.org/view/All/job/Ivy/819/artifact/build/.|https://builds.apache.org/view/All/job/Ivy/819/artifact/build/] The one you are using is from 8th September. > 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-1586-test.zip, 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=16936502#comment-16936502 ] jaikiran pai commented on IVY-1586: --- Thank you for verifying and confirming that. Yes, when 2.5.0 will be released, a fresh cache would have to be used since the older version had ended up creating incorrect module descriptors. > 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=16936479#comment-16936479 ] jaikiran pai commented on IVY-1586: --- Hello [~snagel], I saw a comment that this isn't working but that comment was deleted later. Just want to make sure that this works fine now, for you. I plan to do a release of Ivy soon, so want to be sure that this is taken care of. > 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] [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-1598) Ivy CLI resolve pulls in test scope from Maven parent pom
[
https://issues.apache.org/jira/browse/IVY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935294#comment-16935294
]
jaikiran pai commented on IVY-1598:
---
{{java -jar org.apache.ivy_2.5.0.cr2_20190921121652.jar -confs default
-dependency com.github.dblock.waffle waffle-jna 1.8.1 -cache ./newivycache}}
{{should work fine}}
> Ivy CLI resolve pulls in test scope from Maven parent pom
> -
>
> Key: IVY-1598
> URL: https://issues.apache.org/jira/browse/IVY-1598
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Gintas Grigelionis
>Priority: Major
>
> Try e.g. java -jar ivy.jar -dependency com.github.dblock.waffle waffle-jna
> 1.7.5
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IVY-1598) Ivy CLI resolve pulls in test scope from Maven parent pom
[
https://issues.apache.org/jira/browse/IVY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935294#comment-16935294
]
jaikiran pai edited comment on IVY-1598 at 9/22/19 12:05 PM:
-
{{java -jar org.apache.ivy_2.5.0.cr2_20190921121652.jar -confs default
-dependency com.github.dblock.waffle waffle-jna 1.8.1 -cache ./newivycache}}
{{should work fine and no longer fetch the test dependencies, with the latest
nightly builds.}}
was (Author: jaikiran):
{{java -jar org.apache.ivy_2.5.0.cr2_20190921121652.jar -confs default
-dependency com.github.dblock.waffle waffle-jna 1.8.1 -cache ./newivycache}}
{{should work fine with the latest nightly builds.}}
> Ivy CLI resolve pulls in test scope from Maven parent pom
> -
>
> Key: IVY-1598
> URL: https://issues.apache.org/jira/browse/IVY-1598
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Gintas Grigelionis
>Priority: Major
>
> Try e.g. java -jar ivy.jar -dependency com.github.dblock.waffle waffle-jna
> 1.7.5
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IVY-1598) Ivy CLI resolve pulls in test scope from Maven parent pom
[
https://issues.apache.org/jira/browse/IVY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935294#comment-16935294
]
jaikiran pai edited comment on IVY-1598 at 9/22/19 12:05 PM:
-
{{java -jar org.apache.ivy_2.5.0.cr2_20190921121652.jar -confs default
-dependency com.github.dblock.waffle waffle-jna 1.8.1 -cache ./newivycache}}
{{should work fine with the latest nightly builds.}}
was (Author: jaikiran):
{{java -jar org.apache.ivy_2.5.0.cr2_20190921121652.jar -confs default
-dependency com.github.dblock.waffle waffle-jna 1.8.1 -cache ./newivycache}}
{{should work fine}}
> Ivy CLI resolve pulls in test scope from Maven parent pom
> -
>
> Key: IVY-1598
> URL: https://issues.apache.org/jira/browse/IVY-1598
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Gintas Grigelionis
>Priority: Major
>
> Try e.g. java -jar ivy.jar -dependency com.github.dblock.waffle waffle-jna
> 1.7.5
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (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 ] jaikiran pai resolved IVY-1586. --- Fix Version/s: master Resolution: Fixed > 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=16935024#comment-16935024 ] jaikiran pai commented on IVY-1586: --- [~snagel], I pushed a commit which should now fix the issue you noted in your recent comments. I have added a testcase which replicates your usecase and that is now passing. As usual, the nightly build is available at [https://builds.apache.org/view/A/view/Ant/job/Ivy/lastSuccessfulBuild/artifact/] for testing. > 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 > 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] [Reopened] (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 ] jaikiran pai reopened IVY-1586: --- Interesting that things change on the second run. That shouldn't have happened. I will take a look at your project this week. > 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 > 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.2#803003)
[jira] [Commented] (IVY-1580) Generated ivy.xml from pom with multiple dependencies with different classifier does not contain the main dependency
[
https://issues.apache.org/jira/browse/IVY-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925862#comment-16925862
]
jaikiran pai commented on IVY-1580:
---
Glad to hear.
> Generated ivy.xml from pom with multiple dependencies with different
> classifier does not contain the main dependency
>
>
> Key: IVY-1580
> URL: https://issues.apache.org/jira/browse/IVY-1580
> Project: Ivy
> Issue Type: Bug
> Components: Maven Compatibility
>Affects Versions: 2.5.0-rc1
>Reporter: Antoine Précigout
>Assignee: jaikiran pai
>Priority: Major
> Fix For: master
>
> Attachments: logback-classic-1.1.7-with-ivy-2.4.0.xml,
> logback-classic-1.1.7-with-ivy-2.5.0-rc1.xml
>
>
> Hi,
> Sorry for the title, it's a bit difficult to summerize the problem...
> So, since we updated our Eclipse environment to Ivy 2.5.0-rc1 (available via
> IvyDE), we encountered problems when resolving dependencies on our projects.
> Following a little investigation, it appear that the generated ivy.xml from
> the pom.xml of some dependencies differs from the previous version.
> I think the slf4j-log4j12 package is a good exemple to illustrate my point :
> +Details :+
> {code:xml}
>
> org.slf4j
> slf4j-log4j12
> 1.7.25
>
> {code}
> Pom.xml :
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>
> org.slf4j
> slf4j-parent
> 1.7.25
>
> slf4j-log4j12
> jar
> SLF4J LOG4J-12 Binding
> SLF4J LOG4J-12 Binding
> http://www.slf4j.org
>
>
> org.slf4j
> slf4j-api
>
>
> log4j
> log4j
>
>
> org.slf4j
> slf4j-api
> test-jar
> ${project.version}
> test
>
>
>
> {code}
> Generated Ivy.xml (dependency part) - 2.4.0
> {code:xml}
>
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> conf="test->runtime(*),master(*)">
>m:classifier="tests"/>
>
>[...]
>
> {code}
> Two differents dependency entries :
> - one for classic "jar"
> - one for the type "test-jar".
> In another hand :
> Generated Ivy.xml (dependency part) - 2.5.0-rc1
> {code:xml}
>
> conf="compile->compile(*),master(*);runtime->runtime(*);test->runtime(*),master(*)">
>m:classifier="tests"/>
>
>[...]
>
> {code}
> Only one dependency with artifact test-jar.
> As a result for some of our projects to only get the dependency test-jar...
> I think this is a bug, but maybe i did'nt understand a subtlety.
> PS : Is it link to the correction of IVY-1484 ?
> Thanks for your time :)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IVY-1607) Apache IVYDE 2.5.0.cr1 does not resolve correctly.
[
https://issues.apache.org/jira/browse/IVY-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924927#comment-16924927
]
jaikiran pai commented on IVY-1607:
---
I don't have Eclipse at hand, but this issue is most likely caused by IVY-1580
which, incidentally, I fixed just a few hours back. I plan to do a release of
Ivy soon, assuming there are no other blockers. Once that is done, it should
get picked up by IvyDE (I think).
> Apache IVYDE 2.5.0.cr1 does not resolve correctly.
> --
>
> Key: IVY-1607
> URL: https://issues.apache.org/jira/browse/IVY-1607
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Michael Breu
>Priority: Major
> Attachments: Ivy2.5.0.5rcTests.zip
>
>
> Sorry, to cross post the issue IVYDE-391 here, however the IVYDE project does
> not seem to react on this issue in Apache Ivy 2.5.0.cr1_20180412005305 (and
> even has no reference to version 2.5.0.cr1), and I'm not sure, whether the
> problem is rooted in in 2.5.0-rc1 .
> On https://www.apache.org/dist/ant/ivyde/updatesite/ the apache Ivy library
> "Apache Ivy 2.5.0.cr1_20180412005305" is provided, and it seems that this is
> now installed as default, because it is the newest version. (BTW: it seems
> that it is published as *cr* (change request?), not as *rc* (release
> candidate?))
>
> However: It does not resolve certain dependencies correclty. E.g
> {{ {{version="2.1" }}
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd;
> >
> organisation="Ivy Test"
> module="Ivy250rcTest"
> status="integration">
>
>
>
>
>
>
>
>
> rev="2.12.0" conf="*->runtime"/>
>
> rev="2.12.0" conf="*->default"/>
>
> rev="2.12.0" conf="*->default"/>
>
>
>
> does not resolve log4j-core.jar, although included.
>
> Find enclosed a simple eclipse project that demonstrates this issue.
>
> If you can reproduce this problem, please withdraw version IVYDE 2.5.0.cr...
> . It spoils every installation and it seems very hard to reset to a previous
> version.
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (IVY-1582) OutOfMemory during ANT deploy task
[ https://issues.apache.org/jira/browse/IVY-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jaikiran pai reassigned IVY-1582: - Assignee: jaikiran pai > OutOfMemory during ANT deploy task > -- > > Key: IVY-1582 > URL: https://issues.apache.org/jira/browse/IVY-1582 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.5.0-rc1 >Reporter: Sebastian Götz >Assignee: jaikiran pai >Priority: Minor > > I recently came to test the 2.5.0-rc1 to find out if it could cure a problem > with preemptive authentication during deploy. > For this I simply replaced the 2.4.0 jar-file with the 2.5.0-rc1 and > restarted the build server. The rest of the configuration remained untouched: > * Jenkins 2.107.3 > * Apache ANT 1.8.3 > * Oracle JDK 1.8.0_111 (x86) > * Windows 10 > During the deploy of the build artifact of subproject the upload failed with > an out of memory exception: > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Arrays.java:3236) > at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118) > at > java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93) > at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153) > at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:78) > at org.apache.ivy.util.FileUtil.copy(FileUtil.java:255) > at org.apache.ivy.util.FileUtil.copy(FileUtil.java:234) > at > org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:315) > at > org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:168) > at org.apache.ivy.util.FileUtil.copy(FileUtil.java:219) > at > org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:88) > at > org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:146) > at > org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:236) > at > org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:217) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:275) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:254) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:177) > at org.apache.ivy.Ivy.publish(Ivy.java:622) > at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:316) > at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:259) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:392) > at org.apache.tools.ant.Target.performTasks(Target.java:413) > at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > at org.apache.tools.ant.Project.executeTarget(Project.java:1368) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at org.apache.tools.ant.Project.executeTargets(Project.java:1251) > From the Jenkins configuration I cannot see that any memory flags are passed > to the ANT call. So I guess the default memory constraints apply. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Work started] (IVY-1582) OutOfMemory during ANT deploy task
[ https://issues.apache.org/jira/browse/IVY-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IVY-1582 started by jaikiran pai. - > OutOfMemory during ANT deploy task > -- > > Key: IVY-1582 > URL: https://issues.apache.org/jira/browse/IVY-1582 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.5.0-rc1 >Reporter: Sebastian Götz >Assignee: jaikiran pai >Priority: Minor > > I recently came to test the 2.5.0-rc1 to find out if it could cure a problem > with preemptive authentication during deploy. > For this I simply replaced the 2.4.0 jar-file with the 2.5.0-rc1 and > restarted the build server. The rest of the configuration remained untouched: > * Jenkins 2.107.3 > * Apache ANT 1.8.3 > * Oracle JDK 1.8.0_111 (x86) > * Windows 10 > During the deploy of the build artifact of subproject the upload failed with > an out of memory exception: > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Arrays.java:3236) > at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118) > at > java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93) > at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153) > at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:78) > at org.apache.ivy.util.FileUtil.copy(FileUtil.java:255) > at org.apache.ivy.util.FileUtil.copy(FileUtil.java:234) > at > org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:315) > at > org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:168) > at org.apache.ivy.util.FileUtil.copy(FileUtil.java:219) > at > org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:88) > at > org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:146) > at > org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:236) > at > org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:217) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:275) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:254) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:177) > at org.apache.ivy.Ivy.publish(Ivy.java:622) > at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:316) > at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:259) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:392) > at org.apache.tools.ant.Target.performTasks(Target.java:413) > at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > at org.apache.tools.ant.Project.executeTarget(Project.java:1368) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at org.apache.tools.ant.Project.executeTargets(Project.java:1251) > From the Jenkins configuration I cannot see that any memory flags are passed > to the ANT call. So I guess the default memory constraints apply. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[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=16924883#comment-16924883
]
jaikiran pai commented on IVY-1587:
---
I just tried this locally with 2.5.0-rc1, I see 2 artifacts:
{code}
java -jar ivy-2.5.0-rc1.jar -cache ./cache -dependency "org.slf4j"
"slf4j-log4j12" "1.7.25" -confs default -types jar -retrieve
lib/[originalname](-[type]).[ext]
{code}
and it resolved and retrieved both the jars:
{code}
:: resolving dependencies :: org.slf4j#slf4j-log4j12-caller;working
confs: [default]
found org.slf4j#slf4j-log4j12;1.7.25 in public
found org.slf4j#slf4j-api;1.7.25 in public
found log4j#log4j;1.2.17 in public
downloading
https://repo1.maven.org/maven2/org/slf4j/slf4j-log4j12/1.7.25/slf4j-log4j12-1.7.25.jar
...
.. (11kB)
.. (0kB)
[SUCCESSFUL ] org.slf4j#slf4j-log4j12;1.7.25!slf4j-log4j12.jar (916ms)
downloading
https://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.7.25/slf4j-api-1.7.25.jar
...
.. (40kB)
.. (0kB)
[SUCCESSFUL ] org.slf4j#slf4j-api;1.7.25!slf4j-api.jar (1093ms)
:: resolution report :: resolve 9064ms :: artifacts dl 2016ms
-
| |modules|| artifacts |
| conf | number| search|dwnlded|evicted|| number|dwnlded|
-
| default | 3 | 3 | 3 | 0 || 2 | 2 |
-
:: retrieving :: org.slf4j#slf4j-log4j12-caller
confs: [default]
2 artifacts copied, 0 already retrieved (52kB/7ms)
{code}
Here's the contents of the retrieved lib directory:
{code}
> ls lib
slf4j-api-1.7.25-jar.jarslf4j-log4j12-1.7.25-jar.jar
{code}
> 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.2#803003)
[jira] [Closed] (IVY-1604) Issue with Build when using IVY plugin
[ https://issues.apache.org/jira/browse/IVY-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jaikiran pai closed IVY-1604. - Resolution: Invalid > Issue with Build when using IVY plugin > -- > > Key: IVY-1604 > URL: https://issues.apache.org/jira/browse/IVY-1604 > Project: Ivy > Issue Type: Bug > Environment: Jenkins PROD instance >Reporter: Nidhi Telang >Priority: Major > Attachments: Console output.txt > > > One of our customers build is failing. Error message mentioned below. We have > checked some online article for this issue, but didn't get any proper > resolution. > Console output attached for your reference. > Ivy plugin - 1.22 version > BUILD FAILED > Class org.jfrog.build.extractor.listener.ArtifactoryBuildListener could not > be loaded because of an invalid dependency. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (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 ] jaikiran pai resolved IVY-1586. --- Resolution: Duplicate > 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 > 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.2#803003)
[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=16924881#comment-16924881 ] jaikiran pai commented on IVY-1586: --- I just pushed a fix for IVY-1580. Please give our nightly build https://builds.apache.org/view/A/view/Ant/job/Ivy/lastSuccessfulBuild/artifact/ a try to verify if this solves your issue (be sure to use a clean Ivy cache before trying this newer version). > 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 > 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.2#803003)
[jira] [Resolved] (IVY-1580) Generated ivy.xml from pom with multiple dependencies with different classifier does not contain the main dependency
[
https://issues.apache.org/jira/browse/IVY-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jaikiran pai resolved IVY-1580.
---
Fix Version/s: master
Resolution: Fixed
I have pushed a commit which contains a fix along with a test case for this
issue. Please give it a try against our nightly build
https://builds.apache.org/view/A/view/Ant/job/Ivy/lastSuccessfulBuild/artifact/
(do make sure that you try this against a clean Ivy cache).
> Generated ivy.xml from pom with multiple dependencies with different
> classifier does not contain the main dependency
>
>
> Key: IVY-1580
> URL: https://issues.apache.org/jira/browse/IVY-1580
> Project: Ivy
> Issue Type: Bug
> Components: Maven Compatibility
>Affects Versions: 2.5.0-rc1
>Reporter: Antoine Précigout
>Assignee: jaikiran pai
>Priority: Major
> Fix For: master
>
> Attachments: logback-classic-1.1.7-with-ivy-2.4.0.xml,
> logback-classic-1.1.7-with-ivy-2.5.0-rc1.xml
>
>
> Hi,
> Sorry for the title, it's a bit difficult to summerize the problem...
> So, since we updated our Eclipse environment to Ivy 2.5.0-rc1 (available via
> IvyDE), we encountered problems when resolving dependencies on our projects.
> Following a little investigation, it appear that the generated ivy.xml from
> the pom.xml of some dependencies differs from the previous version.
> I think the slf4j-log4j12 package is a good exemple to illustrate my point :
> +Details :+
> {code:xml}
>
> org.slf4j
> slf4j-log4j12
> 1.7.25
>
> {code}
> Pom.xml :
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>
> org.slf4j
> slf4j-parent
> 1.7.25
>
> slf4j-log4j12
> jar
> SLF4J LOG4J-12 Binding
> SLF4J LOG4J-12 Binding
> http://www.slf4j.org
>
>
> org.slf4j
> slf4j-api
>
>
> log4j
> log4j
>
>
> org.slf4j
> slf4j-api
> test-jar
> ${project.version}
> test
>
>
>
> {code}
> Generated Ivy.xml (dependency part) - 2.4.0
> {code:xml}
>
> conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> conf="test->runtime(*),master(*)">
>m:classifier="tests"/>
>
>[...]
>
> {code}
> Two differents dependency entries :
> - one for classic "jar"
> - one for the type "test-jar".
> In another hand :
> Generated Ivy.xml (dependency part) - 2.5.0-rc1
> {code:xml}
>
> conf="compile->compile(*),master(*);runtime->runtime(*);test->runtime(*),master(*)">
>m:classifier="tests"/>
>
>[...]
>
> {code}
> Only one dependency with artifact test-jar.
> As a result for some of our projects to only get the dependency test-jar...
> I think this is a bug, but maybe i did'nt understand a subtlety.
> PS : Is it link to the correction of IVY-1484 ?
> Thanks for your time :)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IVY-1584) 'ivy:resolve' fails on spring-boot-starter
[
https://issues.apache.org/jira/browse/IVY-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924847#comment-16924847
]
jaikiran pai commented on IVY-1584:
---
This looks like an issue with Spring dependencies itself. 1.5.9.RELEASE of
org.springframework.boot:spring-boot-autoconfigure:1.5.9.RELEASE pom.xml has
this:
```
...
org.springframework.boot
spring-boot
test-jar
test
```
So it requires a tests-jar org.springframework.boot:spring-boot:1.5.9.RELEASE,
but there isn't any here
http://repo1.maven.org/maven2/org/springframework/boot/spring-boot-test/1.5.9.RELEASE/
> 'ivy:resolve' fails on spring-boot-starter
> --
>
> Key: IVY-1584
> URL: https://issues.apache.org/jira/browse/IVY-1584
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.5.0-rc1
>Reporter: Nicholas Lenzi
>Priority: Major
>
> When we attempt to resolve spring-boot-starter, we get an error indicating
> org.springframework.boot tests-jar cannot be resolved. We do not see this
> issue with IVY 2.4.0.
> We were able to work around this issue by changing the ivy.xml. Seems like a
> bug.
> Before:
> {noformat}
>
> rev="1.5.9.RELEASE" conf="compile->default">
>
>
> {noformat}
> After:
> {noformat}
>
> rev="1.5.9.RELEASE" force="true" conf="compile->default"/>
> rev="1.5.9.RELEASE" conf="compile->default">
>
>
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (IVY-1592) Ivy creates wrong version numbers for transitive dependencies
[
https://issues.apache.org/jira/browse/IVY-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jaikiran pai resolved IVY-1592.
---
Fix Version/s: master
Resolution: Fixed
> Ivy creates wrong version numbers for transitive dependencies
> -
>
> Key: IVY-1592
> URL: https://issues.apache.org/jira/browse/IVY-1592
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.4.0, master
>Reporter: mgsoft
>Assignee: jaikiran pai
>Priority: Major
> Fix For: master
>
> Attachments: ivy.xml, ivysettings.xml
>
>
> The following ivy.xml file
>
> {code:java}
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd;>
>
>
> transitive="true" conf="*->default"/>
>
>
> {code}
>
> and the ivysettings.xml file:
>
> {code:java}
>
>
>
> value="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[module]-[revision](-[classifier]).[ext]"
> override="false"/>
>
>
>
>
>
>
>
>
>
>
> {code}
>
>
> yield to following error:
> {code:java}
> [ivy:retrieve] :: Apache Ivy 2.4.0 - 20141213170938 ::
> http://ant.apache.org/ivy/ ::
> [ivy:retrieve] :: loading settings :: file =
> /Users/mgsoft/development/eclipse/ws/photon/runtime-EclipseApplication/rcp_movie_sp4_to_ecl_rest_client/ivysettings.xml
> [ivy:retrieve] :: resolving dependencies :: #;working@DNSNAME.local
> [ivy:retrieve] confs: [default]
> [ivy:retrieve] found org.jboss.resteasy#resteasy-client;3.6.1.Final in central
> [ivy:retrieve] found org.jboss.resteasy#resteasy-jaxrs;3.6.1.Final in central
> [ivy:retrieve] :: resolution report :: resolve 1717ms :: artifacts dl 2ms
> -
> | | modules || artifacts |
> | conf | number| search|dwnlded|evicted|| number|dwnlded|
> -
> | default | 17 | 0 | 0 | 0 || 2 | 0 |
> -
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve] WARNINGS
> [ivy:retrieve] module not found: junit#junit;working@DNSNAME.local
> [ivy:retrieve] local-maven2: tried
> [ivy:retrieve]
> /Users/mgsoft/.m2/repository/junit/junit/working@DNSNAME.local/junit-work...@dnsname.local.xml
> [ivy:retrieve] -- artifact junit#junit;working@DNSNAME.local!junit.jar:
> [ivy:retrieve]
> /Users/mgsoft/.m2/repository/junit/junit/working@DNSNAME.local/junit-work...@dnsname.local.jar
> [ivy:retrieve] central: tried
> [ivy:retrieve]
> https://repo1.maven.org/maven2/junit/junit/working@DNSNAME.local/junit-work...@dnsname.local.pom
> [ivy:retrieve] -- artifact junit#junit;working@DNSNAME.local!junit.jar:
> [ivy:retrieve]
> https://repo1.maven.org/maven2/junit/junit/working@DNSNAME.local/junit-work...@dnsname.local.jar
> [ivy:retrieve] module not found:
> org.jboss.spec.javax.ws.rs#jboss-jaxrs-api_2.1_spec;working@DNSNAME.local
> [ivy:retrieve] local-maven2: tried
> [ivy:retrieve]
> /Users/mgsoft/.m2/repository/org/jboss/spec/javax/ws/rs/jboss-jaxrs-api_2.1_spec/working@DNSNAME.local/jboss-jaxrs-api_2.1_spec-work...@dnsname.local.xml
> [ivy:retrieve] -- artifact
> org.jboss.spec.javax.ws.rs#jboss-jaxrs-api_2.1_spec;working@DNSNAME.local!jboss-jaxrs-api_2.1_spec.jar:
> [ivy:retrieve]
> /Users/mgsoft/.m2/repository/org/jboss/spec/javax/ws/rs/jboss-jaxrs-api_2.1_spec/working@DNSNAME.local/jboss-jaxrs-api_2.1_spec-work...@dnsname.local.jar
> [ivy:retrieve] central: tried
> [ivy:retrieve]
> https://repo1.maven.org/maven2/org/jboss/spec/javax/ws/rs/jboss-jaxrs-api_2.1_spec/working@DNSNAME.local/jboss-jaxrs-api_2.1_spec-work...@dnsname.local.pom
> [ivy:retrieve] -- artifact
> org.jboss.spec.javax.ws.rs#jboss-jaxrs-api_2.1_spec;working@DNSNAME.local!jboss-jaxrs-api_2.1_spec.jar:
> [ivy:retrieve]
> https://repo1.maven.org/maven2/org/jboss/spec/javax/ws/rs/jboss-jaxrs-api_2.1_spec/working@DNSNAME.local/jboss-jaxrs-api_2.1_spec-work...@dnsname.local.jar
> [ivy:retrieve] module not found:
> org.jboss.spec.javax.xml.bind#jboss-jaxb-api_2.3_spec;working@DNSNAME.local
> [ivy:retrieve] local-maven2: tried
> [ivy:retrieve]
> /Users/mgsoft/.m2/repository/org/jboss/spec/javax/xml/bind/jboss-jaxb-api_2.3_spec/working@DNSNAME.local/jboss-jaxb-api_2.3_spec-work...@dnsname.local.xml
> [ivy:retrieve] -- artifact
> org.jboss.spec.javax.xml.bind#jboss-jaxb-api_2.3_spec;working@DNSNAME.local!jboss-jaxb-api_2.3_spec.jar:
> [ivy:retrieve]
> /Users/mgsoft/.m2/repository/org/jboss/spec/javax/xml/bind/jboss-jaxb-api_2.3_spec/working@DNSNAME.local/jboss-jaxb-api_2.3_spec-work...@dnsname.local.jar
> [ivy:retrieve] central: tried
> [ivy:retrieve]
>
[jira] [Commented] (IVY-1606) incorrect dependency order on buildlist
[
https://issues.apache.org/jira/browse/IVY-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916409#comment-16916409
]
jaikiran pai commented on IVY-1606:
---
Thank you for these details. I'll take a look at this and see what's causing
this. If it turns out that the PR you raised is the right fix, I'll go ahead
and merge it.
> incorrect dependency order on buildlist
> ---
>
> Key: IVY-1606
> URL: https://issues.apache.org/jira/browse/IVY-1606
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Sven
>Assignee: jaikiran pai
>Priority: Major
> Labels: patch
> Attachments: deps.png, example.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi,
> I am facing a problem with the ivy buildlist target:
> My scenario looks like the graph in picture deps.png (see attachments).
> The artefact 1B is having a dependency to A in Version 1.0.
> The artefact C is having a dependency to A in Version 2.0 AND a dependency to
> 1B (in Version 1.0).
> In the ivy.xml file the conflict manager „latest-revision" is active.
> Targets like report and resolve works like a charm, speaking Version 2.0 of
> artefact A is pulled, while Version 1.0 is evicted.
> But if I use the ivy:buildlist Tag, the dependency order looks like this:
>
> {code:java}
> run:
> [ivy:buildlist] :: Apache Ivy 2.5.0-RC1 - 20141213170938 ::
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: url =
> jar:file:/C:/Program%20Files/apache-ant-1.10.1/lib/ivy-2.4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> [echo] # buildlist: test#1B, test#A1, test#A, test#D
>
> BUILD SUCCESSFUL
> Total time: 0 seconds
> {code}
>
>
> As you can see, the dependency 1B is in first position, though it has an
> (evicted) dependency to A.
> After digging around in the source, I found the function
> _getModuleDescriptorDependency_ in the Class _CollectionOfModulesToSort_ is
> using a _VersionMatcher_ to determine the correct dependency order.
> So this class do not take the conflict-manager „latest-revision" into
> account.
> I workaround this, by patching die SortEngine like so:
>
> {code:java}
> 27d26
> < import org.apache.ivy.core.module.id.ModuleRevisionId;
> 32d30
> < import org.apache.ivy.plugins.version.AbstractVersionMatcher;
> 125,137c123
> < VersionMatcher matcher = new AbstractVersionMatcher("all") {
> <
> < @Override
> < public boolean isDynamic(ModuleRevisionId askedMrid) {
> < return false;
> < }
> <
> < @Override
> < public boolean accept(ModuleRevisionId askedMrid,
> ModuleRevisionId foundMrid) {
> < return true;
> < }
> < };
> < return matcher;
> ---
> > return settings.getVersionMatcher();
> {code}
>
>
> After that, in my opinion the build order is correct, as the Version of a
> dependency should not affect the dependency order:
> {code:java}
> run:
> [ivy:buildlist] :: Apache Ivy 2.5.0-CL - 20190826123506 ::
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: url =
> jar:file:/C:/Users/kuhnert/.ant/lib/ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml
> [echo] # buildlist: test#A1, test#A, test#1B, test#D
>
> BUILD SUCCESSFUL
> {code}
>
> If you think, this is the right approach, I can create a merge request for
> this ticket.
> Otherwise, I would be glad to hear your thoughts.
>
> Kind regards,
> Sven
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (IVY-1606) incorrect dependency order on buildlist
[
https://issues.apache.org/jira/browse/IVY-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jaikiran pai reassigned IVY-1606:
-
Assignee: jaikiran pai
> incorrect dependency order on buildlist
> ---
>
> Key: IVY-1606
> URL: https://issues.apache.org/jira/browse/IVY-1606
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Sven
>Assignee: jaikiran pai
>Priority: Major
> Labels: patch
> Attachments: deps.png, example.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi,
> I am facing a problem with the ivy buildlist target:
> My scenario looks like the graph in picture deps.png (see attachments).
> The artefact 1B is having a dependency to A in Version 1.0.
> The artefact C is having a dependency to A in Version 2.0 AND a dependency to
> 1B (in Version 1.0).
> In the ivy.xml file the conflict manager „latest-revision" is active.
> Targets like report and resolve works like a charm, speaking Version 2.0 of
> artefact A is pulled, while Version 1.0 is evicted.
> But if I use the ivy:buildlist Tag, the dependency order looks like this:
>
> {code:java}
> run:
> [ivy:buildlist] :: Apache Ivy 2.5.0-RC1 - 20141213170938 ::
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: url =
> jar:file:/C:/Program%20Files/apache-ant-1.10.1/lib/ivy-2.4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> [echo] # buildlist: test#1B, test#A1, test#A, test#D
>
> BUILD SUCCESSFUL
> Total time: 0 seconds
> {code}
>
>
> As you can see, the dependency 1B is in first position, though it has an
> (evicted) dependency to A.
> After digging around in the source, I found the function
> _getModuleDescriptorDependency_ in the Class _CollectionOfModulesToSort_ is
> using a _VersionMatcher_ to determine the correct dependency order.
> So this class do not take the conflict-manager „latest-revision" into
> account.
> I workaround this, by patching die SortEngine like so:
>
> {code:java}
> 27d26
> < import org.apache.ivy.core.module.id.ModuleRevisionId;
> 32d30
> < import org.apache.ivy.plugins.version.AbstractVersionMatcher;
> 125,137c123
> < VersionMatcher matcher = new AbstractVersionMatcher("all") {
> <
> < @Override
> < public boolean isDynamic(ModuleRevisionId askedMrid) {
> < return false;
> < }
> <
> < @Override
> < public boolean accept(ModuleRevisionId askedMrid,
> ModuleRevisionId foundMrid) {
> < return true;
> < }
> < };
> < return matcher;
> ---
> > return settings.getVersionMatcher();
> {code}
>
>
> After that, in my opinion the build order is correct, as the Version of a
> dependency should not affect the dependency order:
> {code:java}
> run:
> [ivy:buildlist] :: Apache Ivy 2.5.0-CL - 20190826123506 ::
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: url =
> jar:file:/C:/Users/kuhnert/.ant/lib/ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml
> [echo] # buildlist: test#A1, test#A, test#1B, test#D
>
> BUILD SUCCESSFUL
> {code}
>
> If you think, this is the right approach, I can create a merge request for
> this ticket.
> Otherwise, I would be glad to hear your thoughts.
>
> Kind regards,
> Sven
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IVY-1603) Latest version matcher fails when found branch is empty
[
https://issues.apache.org/jira/browse/IVY-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840010#comment-16840010
]
jaikiran pai commented on IVY-1603:
---
Hello [~Simon Wade], I forgot to update this issue earlier. I did test the
reproducer you attached and I do see what's happening. However, the failure is
expected (since the dependency does specify a branch but the ivy of the
dependency has a branch, even if an empty one). The place to fix this correctly
is to not set the branch to an empty string in first place in the ivy.xml. For
that to be fixed, I need to understand what/how that ivy.xml with an empty
branch got generated in first place. Do you know what/how that was created?
I will also see if we can improve this error message a bit to indicate the
mismatch of the branch which is causing this issue.
> Latest version matcher fails when found branch is empty
> ---
>
> Key: IVY-1603
> URL: https://issues.apache.org/jira/browse/IVY-1603
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Simon Wade
>Assignee: jaikiran pai
>Priority: Major
> Attachments: IVY-1603.patch, IVY-1603.zip
>
>
> Resolving a latest.integration revision fails when the found dependency
> contains an empty string for a branch. The cryptic error message looks
> something like:
> {noformat}
> [ivy:resolve] java.text.ParseException: inconsistent module descriptor file
> found in '[redacted]ivy-3.1.4-rc5.xml': bad revision: expected='3.1.4-rc5'
> found='3.1.4-rc5';
> {noformat}
>
> This issue doesn't appear to be present in 2.4.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IVY-1603) Latest version matcher fails when found branch is empty
[
https://issues.apache.org/jira/browse/IVY-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jaikiran pai reassigned IVY-1603:
-
Assignee: jaikiran pai
> Latest version matcher fails when found branch is empty
> ---
>
> Key: IVY-1603
> URL: https://issues.apache.org/jira/browse/IVY-1603
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Simon Wade
>Assignee: jaikiran pai
>Priority: Major
> Attachments: IVY-1603.patch, IVY-1603.zip
>
>
> Resolving a latest.integration revision fails when the found dependency
> contains an empty string for a branch. The cryptic error message looks
> something like:
> {noformat}
> [ivy:resolve] java.text.ParseException: inconsistent module descriptor file
> found in '[redacted]ivy-3.1.4-rc5.xml': bad revision: expected='3.1.4-rc5'
> found='3.1.4-rc5';
> {noformat}
>
> This issue doesn't appear to be present in 2.4.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IVY-1603) Latest version matcher fails when found branch is empty
[
https://issues.apache.org/jira/browse/IVY-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801385#comment-16801385
]
jaikiran pai commented on IVY-1603:
---
I had looked at this a few weeks back but wasn't able to reproduce this. If
there a simple way to reproduce this, I can give it a try again and see what
needs to be fixed.
> Latest version matcher fails when found branch is empty
> ---
>
> Key: IVY-1603
> URL: https://issues.apache.org/jira/browse/IVY-1603
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Simon Wade
>Priority: Major
> Attachments: IVY-1603.patch
>
>
> Resolving a latest.integration revision fails when the found dependency
> contains an empty string for a branch. The cryptic error message looks
> something like:
> {noformat}
> [ivy:resolve] java.text.ParseException: inconsistent module descriptor file
> found in '[redacted]ivy-3.1.4-rc5.xml': bad revision: expected='3.1.4-rc5'
> found='3.1.4-rc5';
> {noformat}
>
> This issue doesn't appear to be present in 2.4.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (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 ] jaikiran pai reassigned IVY-1586: - Assignee: jaikiran pai > 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 > 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=16796708#comment-16796708 ] jaikiran pai commented on IVY-1586: --- Sorry everyone, I just read this JIRA today. This is indeed a bug and is actually a duplicate of IVY-1580. I am in the middle of some (Ant) releases this week and once that is done, I will get back with some details and proposals for IVY-1580. Unfortunately, that one isn't an easy fix. I'll keep this one open in the meantime, given the number of inputs provided here. > 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 > 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] [Resolved] (IVY-1602) Cache corrupted when retrieves switch from directory symlink to copy
[ https://issues.apache.org/jira/browse/IVY-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jaikiran pai resolved IVY-1602. --- Resolution: Fixed Thank you reporting this along with the build file to reproduce the issue. I have pushed a fix and a testcase upstream to resolve this. > Cache corrupted when retrieves switch from directory symlink to copy > > > Key: IVY-1602 > URL: https://issues.apache.org/jira/browse/IVY-1602 > Project: Ivy > Issue Type: Bug > Components: Core >Reporter: Simon Wade >Assignee: jaikiran pai >Priority: Major > Fix For: master > > Attachments: IVY-1602.zip > > > After performing a retrieve that has created directory symlinks, a subsequent > retrieve with symlinks disabled deletes the contents of every file in the > corresponding cache directory (i.e. the directory that was the target of the > link). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IVY-1602) Cache corrupted when retrieves switch from directory symlink to copy
[ https://issues.apache.org/jira/browse/IVY-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jaikiran pai updated IVY-1602: -- Fix Version/s: master > Cache corrupted when retrieves switch from directory symlink to copy > > > Key: IVY-1602 > URL: https://issues.apache.org/jira/browse/IVY-1602 > Project: Ivy > Issue Type: Bug > Components: Core >Reporter: Simon Wade >Assignee: jaikiran pai >Priority: Major > Fix For: master > > Attachments: IVY-1602.zip > > > After performing a retrieve that has created directory symlinks, a subsequent > retrieve with symlinks disabled deletes the contents of every file in the > corresponding cache directory (i.e. the directory that was the target of the > link). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IVY-1602) Cache corrupted when retrieves switch from directory symlink to copy
[ https://issues.apache.org/jira/browse/IVY-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16756790#comment-16756790 ] jaikiran pai commented on IVY-1602: --- Hello Simon, Which version of Ivy is this? > Cache corrupted when retrieves switch from directory symlink to copy > > > Key: IVY-1602 > URL: https://issues.apache.org/jira/browse/IVY-1602 > Project: Ivy > Issue Type: Bug > Components: Core >Reporter: Simon Wade >Priority: Major > Attachments: IVY-1602.zip > > > After performing a retrieve that has created directory symlinks, a subsequent > retrieve with symlinks disabled deletes the contents of every file in the > corresponding cache directory (i.e. the directory that was the target of the > link). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IVY-1602) Cache corrupted when retrieves switch from directory symlink to copy
[ https://issues.apache.org/jira/browse/IVY-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jaikiran pai reassigned IVY-1602: - Assignee: jaikiran pai > Cache corrupted when retrieves switch from directory symlink to copy > > > Key: IVY-1602 > URL: https://issues.apache.org/jira/browse/IVY-1602 > Project: Ivy > Issue Type: Bug > Components: Core >Reporter: Simon Wade >Assignee: jaikiran pai >Priority: Major > Attachments: IVY-1602.zip > > > After performing a retrieve that has created directory symlinks, a subsequent > retrieve with symlinks disabled deletes the contents of every file in the > corresponding cache directory (i.e. the directory that was the target of the > link). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
