The last meeting on ShrinkWrap Resolvers was a discussion on the grammars for resolving with regards to transitivity and post-resolution filtering. While we've each been reviewing the current API to best understand the problem domain, I think it's important that we frame these discussions based upon a clean slate and our ideal solution. In other words, identifying the relevant use cases and proposing psudocode to fit them.
I'd also like to value the following concepts, in order:
* Support for All Features in Current API
* Clear Behaviour
...meaning that we should expose all current features currently in place, we should make it clear to the user, and trim verbosity as much as possible without reducing the readability.
The following are some questions raised during the discussion.
1) Make resolution a pluggable mechanism?
In this scenario we make the assumption that resolution is more than simply "transitive or not transitive", and that we cannot predict all user requirements. Note that this might bleed partially into the notion of filtering, a post-resolution step which permits exclusion based on some criteria. However it may be beneficial for us to merge the concepts of merging and resolution strategy. So in that case we'd supply a bunch of canned "ResolutionStrategy" implementations, which are an encapsulation of the rules for inclusion.
2) Require the user to specify a ResolutionStrategy?
I like the grammar above because it becomes clear to the user exactly what strategy is in place; no question will be raised as to whether transitive deps will be sucked in, for example. This necessarily makes things more verbose, but I think the case is warranted, because I don't see how we can pick an intelligent default.
3) Kill the Shortcut API
I like shortcuts, but not separate entry points. 2 entry points make it difficult to switch between one style of supplying the call and another, and make for a more difficult-to-learn API. So the only shortcut I really like is a shorthand for selecting the MavenDependencyResolver.
OK, let's see some use cases.
a) Resolve a single artifact by GAV
b) Resolve a single artifact and all of its runtime dependencies by GAV
c) Resolve a single artifact by GA, and version from a POM
d) Resolve all dependencies declared in a POM
e) Resolve all dependencies declared in a POM, with some conditional exclusions