The only option would be to do as we currently to with filters, which is not so fluent as you'd like:

Right. But to me it's not just about fluency. At the top of this thread I mentioned a favor for clarity over concision, and I don't think we can correctly guess the default for transitive vs. non-transitive. So the longer form, while more verbose, is more explicit and shows the user exactly what's going to happen.

* Added support to configure from POM metadata and settings.xml (and roping in what was previously EffectiveMavenPomDependencyResolver operations)

* Other related refactoring and renaming in the API

The last things to be put in place before starting to move the impl to see how it fits the newer model:

* Figure how we define ResolutionStrategy impls (what were previously called filters)

* Get consensus that the new API works for everyone interested

I'd like to get those 2 items resolved this week. In partilcular, Karel and I will be in #jbosstesting on Freenode Monday 18:00 CET to discuss the ResolutionStrategy API with respect to what Aether is expecting.

Next is a reorganization, naming-based refactoring, verification of JavaDocs and that all use cases are filled, but we're getting very close to a point where I'll wanna have an API review to look over everything, gather wider input, and approve this thing before we start porting the impl.

I want to chime in with a narrowly focused change request (not likely to cause a big ripple).

I urge you to select a different name for the methods withTransitivity() and withoutTransitivity(). The term "transitivity" does not mean what we're trying to make it mean. It likely got selected by conjugating "transitive", which is often used to describe the interdependency of artifacts (i.e., transitive dependencies). I'll explain the the problem with this word choice and suggest alternative method names.

The term "transitive" describes the relationship between objects. Something that is transitive is characterized by having or containing a direct object. It also implies that if the relation holds between a first element and a second and between the second element and a third, it holds between the first and third elements. Thus, if A depends on B and B depends on C, then A must depend on C. This logic holds for libraries, which is why we refer to dependencies as being transitive (and the complete set of dependencies for an artifact as the transitive closure).

The decision to resolve or not resolve the dependencies of a library doesn't affect whether it has a relationship to other objects. That's why withTransitivity() doesn't work in this use case. We are not disabling the transitive relationship. We are simply choosing not to honor it.

Thus, it's better if we focus on the action (honoring the traversal) and not the attribute (relationship to other objects). Here are some suggestions:

includeDependencies() / excludeDependencies() *

includeDependentArtifacts() / excludeDependentArtifacts()

withDependencies() / withoutDependencies()

withDependentArtifacts() / withoutDependentArtifacts()

includeTransitiveClosure() / excludeTransitiveClosure()

withTransitives() / withoutTransitives() <- I don't like the vauge use of "transitive" here, but I understand it will be familiar to users of Maven

* my preference

Feel free to run with other ideas. But just kee in mind, focus on describing what you are doing with the transitive closure, not whether there is one.

This introduces an SPI called "MavenResolutionFilterInternalView" in the impl package which provides the "setDefined*" support needed.

What's still outstanding is this point:

We have MavenResolutionFilter and MavenResolutionStrategy. The Strategy implementations allow filtering before, during, and after the resolution request to Aether. Yet *all* impls return the same filters for each of these operations. So why do we need "preResolution", "resolution" and "postResolution" defined at all? Moreover, why do we need MavenResolutionStrategy? Seems we could just have the filters, pass them through before, during, and after the request, and that'd suffice.