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