[alrubinger]

Done-zo: https://github.com/shrinkwrap/resolver/commit/a08411e60f944a9f45d31d2dceafe2f8c12d178d

[alrubinger]

I *was* missing something, but I get it now.

Pre-filtering needs to be done, for instance, to ban dependencies before they're able to suck in transitives.  During a request, we need filters as well (for Aether).  Post-filtering is *not* something we need to expose to users, as we've now got all tests passing without it (except I do employ an internal filter to weed out POM-packagetype ArtifactResults, but this is an impl detail).

What we need now is an intelligent way to expose out the Filters and Strategies into the API such that users can put them in place with the "using()" method.

[alrubinger]

No need to open a JIRA for this.  I found these tests and re-enabled the feature here:

  https://github.com/ALRubinger/resolver/commit/9cb2c9b1599f54c5c3be17e0c3575fb668ec75b5

We can rewrite the impl if you'd like, but have a look at the API in the patch to see how it's plugged in.

[alrubinger]

Current status as of this writing:

I've put all subtasks as linked issues incorporated by:

  https://issues.jboss.org/browse/SHRINKRES-39

Once those are resolved I think it's time to go to market and switch focus to some docs.  This should be the missing bits users have complaining about for a long time in defining more complex "real" deployment for Arquillian which take in pieces from Maven repos *and* the current project.

[kpiwko]

Andrew,

I've created strategies to have an ability to influence following use cases:

• Change a list of dependencies to be resolved before the resolution itself happens (preResolution filter)
• Reject some of the currently resolved dependencies directly in Aether resolution graph (resolutionFilter)
• Cherry pick only some of the dependencies that were resolved (postResolution)

Note, in previous versions we had MavenFilter which was working as either preResolution (when filter was used during import of dependencies) and

more common postResolution (e.g. selecting a specific scope only).

That's exactly what you've figured out in your last comment:

Andrew Rubinger wrote:

I *was* missing something, but I get it now.

Pre-filtering needs to be done, for instance, to ban dependencies before they're able to suck in transitives.  During a request, we need filters as well (for Aether).  Post-filtering is *not* something we need to expose to users, as we've now got all tests passing without it (except I do employ an internal filter to weed out POM-packagetype ArtifactResults, but this is an impl detail).

What we need now is an intelligent way to expose out the Filters and Strategies into the API such that users can put them in place with the "using()" method.

I have an interesting use case thinking about Strategy as a transformer, like following:

1/ User loads a pom file and includes all the dependencies

2/ Strategy would replace all "foo.bar" groupId with "enterprise.foo.bar" or add a version suffix or similar

This means that strategy is something that should work over MavenWorkingSession allowing it to do more tricky modifications and filters can be removed/generalized. The question is if we want to preserve strategy as something being applied in pre/during/post phase and how to make it an SPI without exposing Aether itself.

I'll dig out if can get rid of post-filtering and move it to aether resolution filtering, which would give us significant performance boost.

[kpiwko]

Andrew Rubinger wrote:

Why do you necessarily want to configure the settings *before* configuring from POM? 

For the very same reason I don't like the placement of offline() method. Because configuring from POM involves first Maven resolution (effective pom construction) and thus it is needed to configure repositories/mirrors/go-offline *before* configuring from POM.

The fact the POM resolution is hidden there should be promoted more loudly. We might possibly be able to delay the resolution itself to StrategyStage but that would require significant changes in current impl and would hit our cash-ability, e.g. POM would be parsed for every resolve call.

It's up to discussion what approach is preferred, but I prefer a requirement of configure settings and offline method to always happen before POM is loaded.

[kpiwko]

Andrew Rubinger wrote:

Karel Piwko wrote:

5/ We might need a strategy builder somewhere in the API

Please elaborate more on the use case and how you might see this working?

basically using(new FooStrategy()) method should allow users to do the following:

using(MavenStrategyBuilder.acceptScopes("compile", "default").withoutTransitives().rejectDependencies("a:b", "c:d").build())

Note that if we get rid of CombinedFilter and CombinedStrategy, current API will be simpler, but still far from ideal:

using(Arrays.asList(new AcceptScopesStrategy("compile", "default"), new RejectDepenenciesStrategy("a:b", "c:d"), new NonTransitiveStrategy()))

[alrubinger]

https://issues.jboss.org/browse/SHRINKRES-59

[alrubinger]

Karel Piwko wrote:

I have an interesting use case thinking about Strategy as a transformer, like following:

1/ User loads a pom file and includes all the dependencies

2/ Strategy would replace all "foo.bar" groupId with "enterprise.foo.bar" or add a version suffix or similar

That certainly describes a feature, but I'm not sure what the use case is?  Looking for something phrased like, "I have the need to port all of my deprecated junit groupIds to org.junit...".  In other words, I'm not sure this case exists until we see why it'd be used.

That said, this "transformer" notion begins to sound more and more like a generic interceptor chain, which may be a different construct from the Strategy (chain of filters used for pre- and during-resolution phases) or Filter (exclusion-based) notions that we already have.

Karel Piwko wrote:

I'll dig out if can get rid of post-filtering and move it to aether resolution filtering, which would give us significant performance boost.

The current state of SHRINKRES-39 now passes the tests without any post-resolution filtering done from an API perspective.  Though I don't see why that'd give us any performance boost; it's just passing resolved depdencies through a Filter callback which does some simple inspection.

[alrubinger]

Compelling argument for cachability and thus, speed.

https://issues.jboss.org/browse/SHRINKRES-60

[kpiwko]

That certainly describes a feature, but I'm not sure what the use case is?  Looking for something phrased like, "I have the need to port all of my deprecated junit groupIds to org.junit...".  In other words, I'm not sure this case exists until we see why it'd be used.

That said, this "transformer" notion begins to sound more and more like a generic interceptor chain, which may be a different construct from the Strategy (chain of filters used for pre- and during-resolution phases) or Filter (exclusion-based) notions that we already have.

Use case is noted here: https://issues.jboss.org/browse/SHRINKRES-58 e.g. replace all classifiers or versions mentioned in a pom file with something different. Not trying to make Shrinkres a swiss knife, however as speaking about API changes having SPI for interceptors would do the stuff much more flexible.

The current state of SHRINKRES-39 now passes the tests without any post-resolution filtering done from an API perspective.  Though I don't see why that'd give us any performance boost; it's just passing resolved depdencies through a Filter callback which does some simple inspection.

I have missed that it was already moved to during-resolution phase. The perfomance boost happens due to not all dependencies are fetched and then the filtering is done, if filtering is done on the fly (during-resolution), the resulting tree to be fetched can be significantly smaller.

[alrubinger]

Karel Piwko wrote:

Use case is noted here: https://issues.jboss.org/browse/SHRINKRES-58 e.g. replace all classifiers or versions mentioned in a pom file with something different. Not trying to make Shrinkres a swiss knife, however as speaking about API changes having SPI for interceptors would do the stuff much more flexible.

Hmm, I read SWR-58 to be more about allowing the user to set system properties to be considered while parsing the POM.  Like an equivalent to "-DmyProp=value" that we'd ordinarily do on the command-line.

[kpiwko]

Hmm, I read SWR-58 to be more about allowing the user to set system properties to be considered while parsing the POM.  Like an equivalent to "-DmyProp=value" that we'd ordinarily do on the command-line.

Correct. It could be solved with an interceptor in a hackish way, however allow user to pass properties or Map<String,String> is what this use case is really about.

[alrubinger]

Karel (and others!):

Please approve this or offer other naming suggestions?  https://github.com/ALRubinger/resolver/blob/SHRINKRES-51-60/impl-maven-archive-prototype/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven/prototyping/UseCasesTestCase.java#L403

/**

     * Use case 16: Clear configuration. Settings = "settings.xml". Load from POM: "pom.xml"

     *

     * SHRINKRES-60 SHRINKRES-51

     */

    public void configure() {

        Resolvers.configure(ConfigurableMavenResolverSystem.class).fromFile(new File("somepath")).resolve("GAV")

            .withoutTransitivity().as(File.class);

        Maven.configureResolver().fromFile("~/.m2/settings.xml").resolve("GAV").withoutTransitivity().as(File.class);

        Maven.configureResolver().fromClassloaderResource("settings.xml").resolve("GAV").withoutTransitivity()

            .as(File.class);

        Maven.configureResolver().fromClassloaderResource("settings.xml").loadPomFromFile((File) null).resolve("GA")

            .withoutTransitivity().as(File.class);

        @SuppressWarnings("unused")

        final JavaArchive archive = ShrinkWrapMaven.configureResolver().fromClassloaderResource("settings.xml")

            .resolve("GAV").withoutTransitivity().asSingle(JavaArchive.class);

    }

[alrubinger]

I've removed CombinedFilter but kept CombinedStrategy.  Do we really still need a builder?  Seems that using CombinedStrategy to compose N Strategies together works kind of nicely on its own.