[shrinkwrap-issues] [JBoss JIRA] (SHRINKRES-66) Allow "resolve" to take in Collection<String> and Collection<MavenDependency>

Karel Piwko (JIRA) jira-events at lists.jboss.org
Wed Sep 26 03:05:34 EDT 2012


    [ https://issues.jboss.org/browse/SHRINKRES-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721671#comment-12721671 ] 

Karel Piwko commented on SHRINKRES-66:
--------------------------------------

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.
                
> Allow "resolve" to take in Collection<String> and Collection<MavenDependency>
> -----------------------------------------------------------------------------
>
>                 Key: SHRINKRES-66
>                 URL: https://issues.jboss.org/browse/SHRINKRES-66
>             Project: ShrinkWrap Resolvers
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0-alpha-2, 2.0.0-alpha-3
>            Reporter: Andrew Rubinger
>              Labels: starter
>
> 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:
> {code}archive.addAsLibraries(resolver.resolve(artifacts.toArray(new String[artifacts.size()])).withTransitivity().as(File.class));{code}
> -----------
> Save the user the extra step of having to convert Collections to an array by enhancing the API to accept Collections natively.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the shrinkwrap-issues mailing list