[
https://issues.apache.org/jira/browse/IVY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761238#action_12761238
]
Hans Dockter commented on IVY-758:
----------------------------------
This is very disturbing for many Gradle users (and I'm for all users using
multiple Ivy builds on there machines). Reporting an error in a case where
everything is OK is a serious problem.
> Unwanted error messages when using different settings with different
> resolvers for the same cache.
> --------------------------------------------------------------------------------------------------
>
> Key: IVY-758
> URL: https://issues.apache.org/jira/browse/IVY-758
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.0.0-beta-2
> Reporter: Hans Dockter
> Priority: Minor
>
> From the mailing list:
> In my environment I use multiple settings to work with Ivy.
> One setting is the ivysettings.xml for building my build tool. The other
> setting is when I use my build tool which defines its own resolvers. If for
> example my build tool has been executed and has used Ivy to resolve a
> dependency that is also used by the build of my build tool, I get the
> following messages when building my build tool (chain is the name of a
> resolver defined by my build tool).
> [ivy:cachepath] == resolving dependencies
> org.gradle#gradle;work...@localhost->commons-lang#commons-lang;2.3
> [compile->default]
> [ivy:cachepath] loadData of commons-lang#commons-lang;2.3 of rootConf=compile
> [ivy:cachepath] using default to resolve commons-lang#commons-lang;2.3
> [ivy:cachepath] default: Checking cache for: dependency:
> commons-lang#commons-lang;2.3 {compile=[default]}
> Resource org/apache/ivy/plugins/parser/xml/ivy.xsd loaded from ant loader
> [ivy:cachepath] pre 1.3 ivy file: using exactOrRegexp as default matcher
> {quote}
> On Mar 5, 2008, at 2:07 PM, Xavier Hanin wrote:
> The problem is that Ivy caches which resolver was used to resolve a
> dependency, and when it reuses the cache, it tries to locate the resolver
> previously used. This makes using the same cache with different settings
> reporting errors like you see. I agree this is not very nice, but I haven't
> found a pleasant solution yet. The easiest would be to have a parameter to
> disable these messages, since it should work like this in most cases. But to
> be clean we'd need to deeply review the usage of this information, to know
> exactly what can be failing when the resolver information is not present or
> missing in current settings.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
