-
Feature Request
-
Resolution: Done
-
Major
-
2.0.0-alpha-2, 2.0.0-alpha-3
-
None
From Craig Ringer:
-----------
Since `resolve(…)` doesn’t take a `Collection`, only an array, I have to accumulate in a set or list then pass an array view of it to resolve(), eg given a Set artifacts:
archive.addAsLibraries(resolver.resolve(artifacts.toArray(new String[artifacts.size()])).withTransitivity().as(File.class));
-----------
Save the user the extra step of having to convert Collections to an array by enhancing the API to accept Collections natively.
[SHRINKRES-66] Allow "resolve" to take in Collection<String> and Collection<MavenDependency>
Karel Piwko
added a comment - Copying comment from github here:
I've seen those yesterday. I don't like the change. It makes the API too verbose.
I'm wondering what's the point of having method which resolves based on MavenDependency instead of coordinates.
While the MavenDependency might give you better control, you can't really get much from it:
you still need string coordinate
specifying optional does not make much sense, why would you try to resolve something optional or filter on optional dependencies?
specifying scope does not make much sense neither for very same reason
Having possibility to add exclusions is tempting. However, we can promote filters here. Moreover, filters give you an ability to globally exclude for free. Trying to get 1:1 matching with Maven only makes API too complex without giving a real advantage.
The only disadvantage happens when you want to exclude G:A(V1) from dependency and and G:A:V2 to be resolved. Then you have to write a custom filter, because current ones ignore version.
To conclude, I vote for having String-based resolve(), addDependency() methods only.
Karel Piwko
added a comment - Copying comment from github here:
I've seen those yesterday. I don't like the change. It makes the API too verbose.
I'm wondering what's the point of having method which resolves based on MavenDependency instead of coordinates.
While the MavenDependency might give you better control, you can't really get much from it:
you still need string coordinate
specifying optional does not make much sense, why would you try to resolve something optional or filter on optional dependencies?
specifying scope does not make much sense neither for very same reason
Having possibility to add exclusions is tempting. However, we can promote filters here. Moreover, filters give you an ability to globally exclude for free. Trying to get 1:1 matching with Maven only makes API too complex without giving a real advantage.
The only disadvantage happens when you want to exclude G:A(V1) from dependency and and G:A:V2 to be resolved. Then you have to write a custom filter, because current ones ignore version.
To conclude, I vote for having String-based resolve(), addDependency() methods only. 
Andrew Rubinger (Inactive)
added a comment - Added candidate to solve this in: https://github.com/ALRubinger/resolver/commit/8744d8c99f56457b04aec17e735802feb71d4adc; garner feedback on API name changes before pushing upstream.
Andrew Rubinger (Inactive)
added a comment - Added candidate to solve this in: https://github.com/ALRubinger/resolver/commit/8744d8c99f56457b04aec17e735802feb71d4adc ; garner feedback on API name changes before pushing upstream. Andrew Rubinger (Inactive)
added a comment - We need to debate how to go about API name changes here. Collections<String> and Collection<MavenDependency> will have the same erasure when the compiler is done with them, so we might start to explore renaming all the "resolve" methods to be specific as to their input types.
Andrew Rubinger (Inactive)
added a comment - We need to debate how to go about API name changes here. Collections<String> and Collection<MavenDependency> will have the same erasure when the compiler is done with them, so we might start to explore renaming all the "resolve" methods to be specific as to their input types. 
Resolved discussion on GitHub.
Conclusion: "resolve" to accept String, String..., Collection<String>. "addDependency" to accept MavenDependency, MavenDependency..., Collection<MavenDependency>.
Upstream: https://github.com/shrinkwrap/resolver/commit/908b0c3e9e1723fc983d5782b6c316d539000b34