You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Hans Dockter (JIRA)" <ji...@apache.org> on 2008/03/05 14:57:40 UTC
[jira] Created: (IVY-758) Unwanted error messages when using
different settings with different resolvers for the same cache.
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
Fix For: unspecified
>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;working@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.
[jira] Commented: (IVY-758) Unwanted error messages when using
different settings with different resolvers for the same cache.
Posted by "Russel Winder (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730055#action_12730055 ]
Russel Winder commented on IVY-758:
-----------------------------------
Seems to affect 2.1.0-rc1 as well.
> 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;working@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.
[jira] Commented: (IVY-758) Unwanted error messages when using
different settings with different resolvers for the same cache.
Posted by "Hans Dockter (JIRA)" <ji...@apache.org>.
[ 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;working@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.
[jira] Commented: (IVY-758) Unwanted error messages when using
different settings with different resolvers for the same cache.
Posted by "Hans Dockter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603963#action_12603963 ]
Hans Dockter commented on IVY-758:
----------------------------------
I have this problem also under the following circumstances. I publish a dependency to a local repository with one resolver and read this dependency with another one. This gives me also the error messages mentioned above.
> 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
> Fix For: unspecified
>
>
> 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;working@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.