1 2 Previous Next 29 Replies Latest reply: Sep 24, 2011 8:50 AM by badr elhouari Go to original post RSS
  • 15. Re: Resolving Maven artifacts
    Samuel Santos Newbie

    Hi Karel,

     

    I do not dislike it

    But I'm not sure that it will be simpler for users.

     

    How will the user filter transitive dependencies? By implementing its own strategy (too much work for the normal user) or can he pass a filter as an argument to the resolveAs() method?

     

    Since MavenDependencyResolver will implement DependencyResolver, should we also create a new MavenTransitiveDependencyResolver that implements TransitiveDependencyResolver?

  • 16. Re: Resolving Maven artifacts
    Karel Piwko Master

    How will the user filter transitive dependencies? By implementing its own strategy (too much work for the normal user) or can he pass a filter as an argument to the resolveAs() method?

     

    By passing a filter by default. But we can't prevent him implementing his own strategy . By the way, transitive dependencies can be filtered by exclusions as well, e.g.

     

    artifact("foo:bar:1").exclusions("bar:bar", "bar:car")
    

     

    This even accept a wild card, so you can have the same result as StrictFilter via

     

    artifact("foo:bar:1).eclusion("*:*")
    

     

     

    Since MavenDependencyResolver will implement DependencyResolver, should we also create a new MavenTransitiveDependencyResolver that implements TransitiveDependencyResolver?

     

     

    No. It would be to compilacated for user to have two entry points AFAIK. This should be hidden in impl.

  • 17. Re: Resolving Maven artifacts
    Samuel Santos Newbie

    Hi Karel,

     

    Both solutions are equally easy to use and flexible enough for me.

    I personally think that this is a question of personal taste and would love to have more feedback from the community.

     

    Summarizing what we have discuss so other people can share their thoughts:

     

    SW-261: shortcut API (unchanged)

    Collection<GenericArchive> Maven.artifacts(String... coordinates);
    GenericArchive Maven.artifact(String coordinate);
    Maven Maven.withPom(String pomFile);
    Maven.withPom("pom.xml").artifact("foo:bar"); // no version required there, POM may contain specific remote repositories definitions as well
    

     

    SW-265 and SW-268: MavenDependencyResolver methods renaming (please comment these changes)

    Version 1

    // return the Maven artifact and its dependencies
    <T extends Archive<T>> Collection<T> MavenDependencyResolver.artifact("foo:bar:1").resolveTransitivelyAs(T type [, MavenResolutionFilter filter]);
    // return the artifact without any dependencies
    <T extends Archive<T>> T MavenDependencyResolver.artifact("foo:bar:1").resolveAs(T type);
    

    Version 2

    // Depending on the strategy used, may return "<T extends Archive<T>> Collection<T>" or "<T extends Archive<T>> T"
    MavenDependencyResolver.artifact("foo:bar:1").strategy(TransitiveDependencyResolver.class).resolveAs(T type [, MavenResolutionFilter filter]);
    

     

    In both cases we should also implement the following changes:

    // was MavenDependencyResolver loadReposFromPom(String path);
    MavenDependencyResolver loadMetadataFromPom(String file);
    // was MavenDependencyResolver loadDependenciesFromPom(String path) throws ResolutionException;
    MavenDependencyResolver includeDependenciesFromPom(String path) throws ResolutionException;
    // remove the following method
    MavenDependencyResolver loadDependenciesFromPom(final String path, final MavenResolutionFilter filter) throws ResolutionException;
    

     

     

    Karel, please correct me if I'm missing something.

    Cheers,

     

    Samuel

  • 18. Re: Resolving Maven artifacts
    Karel Piwko Master

    Hi Samuel,

     

     

    SW-265 and SW-268: MavenDependencyResolver methods renaming (please comment these changes)

    Version 1

    // return the Maven artifact and its dependencies<T extends Archive<T>> Collection<T> MavenDependencyResolver.artifact("foo:bar:1").resolveTransitivelyAs(T type [, MavenResolutionFilter filter]);// return the artifact without any dependencies<T extends Archive<T>> T MavenDependencyResolver.artifact("foo:bar:1").resolveAs(T type);

    Version 2

    // Depending on the strategy used, may return "<T extends Archive<T>> Collection<T>" or "<T extends Archive<T>> T"MavenDependencyResolver.artifact("foo:bar:1").strategy(TransitiveDependencyResolver.class).resolveAs(T type [, MavenResolutionFilter filter]);

     

     

    I'm fond of version 2 here.

     

     

    In both cases we should also implement the following changes:

    // was MavenDependencyResolver loadReposFromPom(String path);
     MavenDependencyResolver loadMetadataFromPom(String file);
    // was MavenDependencyResolver loadDependenciesFromPom(String path) throws ResolutionException;
     MavenDependencyResolver includeDependenciesFromPom(String path) throws ResolutionException;
    // remove the following methodMavenDependencyResolver loadDependenciesFromPom(final String path, final MavenResolutionFilter filter) throws ResolutionException;

     

     

     

    Yeah, loadMetadataFromPom() will load repositories and dependencies (for version management), includeDepedenciesFrom pom will do the same but include all the dependencies found to the resolution chain. I like it this way, much clearer than current API.

     

    Karel

  • 19. Re: Resolving Maven artifacts
    Samuel Santos Newbie

    Hi Karel,

     

    Would love to hear your thoughts on https://issues.jboss.org/browse/SHRINKWRAP-261.

     

    Cheers,

    Samuel

  • 20. Re: Resolving Maven artifacts
    José Freitas Newbie

    Hi Karen,

     

    I added two methods on MavenDependencyResolver interface:

     

    configureFromFileInClassPath(String path);

    which does kinda the same job from

    configureFrom(String path)

    but uses a file in classpath.

     

    and

     

    includeDependenciesFromPomInClassPath(final String path)

    which does kinda the same job from

    includeDependenciesFromPom(final String path)

    but uses a file in classpath.

     

    I'd like to know, what do you think about those new names?

    I like descriptive method names. but maybe they're too silly.

     

    btw, Andrew suggested to create a forum topic with all api methods to make a full api review.

  • 21. Re: Resolving Maven artifacts
    Andrew Rubinger Master

    spinner wrote:

    btw, Andrew suggested to create a forum topic with all api methods to make a full api review.

    Yup.  And then we can all decide on a time to together get into IRC and debate over method and class names.


    S,

    ALR

  • 22. Re: Resolving Maven artifacts
    Karel Piwko Master

    Wasn't the idea rather to have:

     

    includeDependenciesFromPom(URL url)

    and configureFrom(URL url) ?

     

    where you could use for example:

    • classpath:org/jboss/shrinkwrap/test/pom.xml (for classpath)
    • file:///tmp/bar/pom.xml (for file)

     

    We could extend API even further in future and make configureFrom(String path) method etc. just a convinient wrapper.

     

    Karel

  • 23. Re: Resolving Maven artifacts
    Karel Piwko Master

    Great idea. Be sure to invite Samuel as well!

     

    Karel

    Andrew Rubinger wrote:

     

    spinner wrote:

    btw, Andrew suggested to create a forum topic with all api methods to make a full api review.

    Yup.  And then we can all decide on a time to together get into IRC and debate over method and class names.


    S,

    ALR

  • 24. Re: Resolving Maven artifacts
    José Freitas Newbie

    If we're going to keep the same name,

    I'd prefer to use configureFrom(String path) as the only entry (as karel suggested for future work) and then work at to find out the way to locate the file.

     

    And IMHO, I don't think the user should write the resourcePath in a URL format, it's better to keep

    the input simple like: "org/jboss/shrinkwrap/test/pom.xml" or "tmp/bar/pom.xml"

    so we could look first for the filepath project related, then for the filepath classpath related and the for a stream in a jar.

     

    and btw, I made some changes and now I have it working, it extracts the stream from a jar and saves to tmp dir.

  • 25. Re: Resolving Maven artifacts
    Jason Porter Master

    I know I'm injecting myself in the middle of the discussion :) Using the maven resolver for Seam Catch testing I thought it would be very helpful to simply use a default settings file and add a repository to it (in my case the JBoss Nexus Repo). I didn't need to anything but that, creating and shipping a settings.xml with the tests seemed a little much. Could we get such a feature, or perhaps build up a settings.xml file programmatically?

  • 26. Re: Resolving Maven artifacts
    Andrew Rubinger Master

    This is a great idea.  Mind opening a JIRA with your thoughs?


    S,

    ALR

  • 27. Re: Resolving Maven artifacts
    Jason Porter Master

    SHRINKWRAP-314

  • 28. Re: Resolving Maven artifacts
    Samuel Santos Newbie

    Hi guys,

     

    I can join the IRC discussion tomorrow night (timezone GMT+1), probably during the afternoon for the most of you

     

    Is that OK for you?

  • 29. Re: Resolving Maven artifacts
    badr elhouari Novice

    Hi all,

     

    Can someone summarize the work done and especialy provide the community how we can use that !

     

    Thanks

1 2 Previous Next