Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

363 validate resolvers #367

Merged
merged 3 commits into from
Feb 12, 2012
Merged

363 validate resolvers #367

merged 3 commits into from
Feb 12, 2012

Conversation

vigdorchik
Copy link
Contributor

No description provided.

Eugene Vigdorchik added 2 commits February 10, 2012 13:17
@indrajitr
Copy link
Member

Wondering what need the explicit validateResolvers key would serve. There is low likelihood for an user to configure this. And if the need really comes up, (s)he can use publishConfiguration. Am I missing something obvious?

@harrah
Copy link
Member

harrah commented Feb 11, 2012

I agree. Perhaps just call warnResolversConflict in mkIvyConfiguration without need for a separate task.

@vigdorchik
Copy link
Contributor Author

Yes, sorry guys. I wasn't sure if mkIvyConfiguration is the only place where resolvers need to be validated. Now that it looks it really is, I've removed the key.

harrah added a commit that referenced this pull request Feb 12, 2012
@harrah harrah merged commit 13bcdf4 into sbt:0.12 Feb 12, 2012
indrajitr added a commit that referenced this pull request Mar 11, 2012
Warn when publish resolver and dependency resolvers have same name but different access mechanism.
Multiple resolvers having same name as well as same access mechanism (i.e., equality matching) isn't
usually a problem. A common scenario for this would be Maven based resolvers with exact (http based)
same access mechanism. Also see #367, #363
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants