[
https://issues.apache.org/jira/browse/IVY-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774091#action_12774091
]
Eric Sirianni commented on IVY-1049:
------------------------------------
I agree. I came across this thread while googling for the "unknown resolver"
error:
http://www.mail-archive.com/[email protected]/msg02262.html
Without knowing the architecture of ivy, I don't understand why the resolver
names are stored in with the repository cache. From a high-level view, it
seems that the repository cache is just a cache of JAR files and dependency
definitions. What does it matter which resolver actually was used to populate
that cache?
This creates an unwanted coupling between ivysettings.xml files for independent
projects. They must use the same resolver names or face these constant
"unknwon resolver" errors. I think this is more than a documentation issue and
should be fixed in ivy if possible.
> Describe how to setup the caches, especailly for multiple ivysettings.xml-s
> ---------------------------------------------------------------------------
>
> Key: IVY-1049
> URL: https://issues.apache.org/jira/browse/IVY-1049
> Project: Ivy
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 2.0
> Reporter: Daniel Dekany
>
> When using more the one ivysettings.xml-s inside the same user account (same
> computer), the result is often a lot of "unknown resolver" errors, and other
> such mess. The cause is that caches were not set up properly: I guess usually
> there should be one repository cache per ivysettings.xml, then one dedicated
> resolution cache per ivysettings.xml too (at least, because if parallel
> builds use a common ivysettings.xml, then each of them needs its own). These
> I mostly deduced from mailing list discussions and experimenting, not from
> the documentation. So, these things should be well described, and then linked
> from every place that's about wiring ivysettings.xml-s. (Even maybe the
> "unknown resolver" error messages could contain a hint about what the problem
> could be.) Also, the users should be warned about the importance of lock
> strategies. (I know that in principle these could be find out from
> http://ant.apache.org/ivy/history/latest-release/concept.html#cache, but that
> description is at best sparse, and the implications are not described. Also
> it's not on a very well visible place.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
