1 2 3 4 Previous Next 49 Replies Latest reply on Nov 19, 2013 12:56 PM by Marines Lopez Soliz Go to original post
      • 31. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
        Andrew Rubinger Master

        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.

        • 32. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
          Andrew Rubinger Master

          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.

          • 33. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
            Andrew Rubinger Master

            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.

            • 34. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
              Karel Piwko Master

              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.

              • 35. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
                Karel Piwko Master

                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.

                • 36. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
                  Karel Piwko Master

                  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()))
                  
                  • 38. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
                    Andrew Rubinger Master

                    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.

                    • 40. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
                      Karel Piwko Master

                      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.

                      • 41. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
                        Andrew Rubinger Master

                        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.

                        • 42. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
                          Karel Piwko Master

                          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.

                          • 43. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
                            Andrew Rubinger Master

                            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);

                                }

                            • 44. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
                              Andrew Rubinger Master

                              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.