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

    Samuel Santos wrote:

     

    I take back what I said.

     

    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.

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

    An update on some of the work done since my last post:

     

    * Added support for exposing dependency resolution information (as defined by SHRINKRES-27)

    * 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.

     

    S,

    ALR

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

    Also: I've not yet done the ENVIRONMENT support put in place by the SWR Maven Plugin.

     

    S,

    ALR

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

    Latest dev update in my fork:

     

    * ENVIRONMENT (ie. Plugin) configuration support now added:

     

    final File[] fromPlugin = Maven.resolver().configureFromPlugin().resolve("G:A").withTransitivity().as(File.class);
    

     

    * Added "exclusions" support, though some more eyes on the naming/API there would be great:

     

      https://gist.github.com/2729351

     

    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.

     

    S,

    ALR

  • 19. Re: SWR API Changes: Resolution Strategies, Transitivity, and Filters
    Dan Allen Master

    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.

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

    I've almost migrated currently existing implementation under newly defined API https://github.com/shrinkwrap/resolver/commits/SHRINKRES-39

    I'm experiencing following problems, which we haven't specified in original use cases:

     

    1/ Configured* and Configurable* interfaces should be polished a bit. I think that an ability to configureSettings(...) after configureFromPom(...) is not necessary at all.

        If you want to parse a pom, you basically want to configure mirrors or remote repositories before.

     

    2/ We have no goOffline() method. It seems to be pretty popular by users. Where should it go?

     

    3/ We have not discussed cashability of the objects at all. E.g. configure from a pom/settings xml once, then resolve one artifact multiple times. This feature seems handy.

     

    4/ I've implemented a strategy as a collection of pre-resolution, while-resolving and post-resolution filters. This should be able to cover

     

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

     

    6/ Classpath (a.k.a. Maven Reactor) support was temporarily dropped. It needs to be rewritten because current impl is a significant bottleneck.

     

    I have not touched maven-archive-impl-prototype yet,  however it the work here consists basically only of solving Configured/Configurable* problems and writing tests, which is pretty straightforward

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

     

    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

     

     

    It quite hard to find a correct name. I think the we need to omit anything with dependencies because it conflicts with current API. See examples:

     

    // get compile and runtime scoped dependencies defined in a pom file
    ...configureFromPom(...).importDefinedDependencies()...
    // get test scoped dependencies defined in a pom file
    ...configureFromPom(...).importTestDependencies()...
    
    
    // get g:a:v and g:b:v including transitive closure (includeDependencies() is very confusing here
    Maven.resolver().addDependency("g:a:v").and("g:b:v").resolve().includeDependencies()...
    
    
    
    

     

    withTransitiveClosure() is pretty self explanatory to me, but I guess it is too long. Therefore, if you want us to rename the methods, I'd prefer to go with

     

    withTransitives() / withoutTransitives()
    

     

    These two methods would be a shortcuts to:

     

     

    ...resolve().using(new AcceptTransitivesStrategy())....
    ...resolve().using(new RejectTransitivesStrategy())....
    

     

    to conform with strategy naming (AcceptAllStrategy, RejectDependenciesStrategy, AcceptScopesStrategy).

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

    Karel Piwko wrote:

    2/ We have no goOffline() method. It seems to be pretty popular by users. Where should it go?

    I've put this into the Maven StrategyStage:

     

    Maven.resolver().resolve("groupId:artifactId:version").offline().withoutTransitivity().asSingle(File.class);
    

     

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

     

    Looks good here to you?  Will require tests for resolution (as indicated in the issue).

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

    Karel Piwko wrote:

    1/ Configured* and Configurable* interfaces should be polished a bit. I think that an ability to configureSettings(...) after configureFromPom(...) is not necessary at all.

        If you want to parse a pom, you basically want to configure mirrors or remote repositories before.

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

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

    Karel Piwko wrote:

    3/ We have not discussed cashability of the objects at all. E.g. configure from a pom/settings xml once, then resolve one artifact multiple times. This feature seems handy.

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

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

    Karel Piwko wrote:

    4/ I've implemented a strategy as a collection of pre-resolution, while-resolving and post-resolution filters. This should be able to cover

    Looks like the editor cut off your thought here.

     

    I'd noticed that you'd put into place:

     

      MavenResolutionFilterBase

     

    ...though I'll admit I don't quite grok its intent.  What are these methods?

     

      setDefinedDependencies

       setDefinedDependencyManagement

     

    I'd like us to be very careful to write docs as we go, particularly for the API.

     

    So:  https://issues.jboss.org/browse/SHRINKRES-47

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

    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?

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

    Karel Piwko wrote:

    6/ Classpath (a.k.a. Maven Reactor) support was temporarily dropped. It needs to be rewritten because current impl is a significant bottleneck.

    Please open a feature request JIRA for this, detailing what you'd like to see?  Affecting "SHRINKRES-39 Unreleased Changes", and linked as "Incorporated By SHRINKRES-39".

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

    I've gone through to understand this some more, and have concluded that we really don't need this in the API.  Instead I've done:

     

      https://github.com/shrinkwrap/resolver/commit/5bdcbe531a1180f1c723d5665381787dc4595f92

     

    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.


    Or am I missing something?