-
15. Re: Resolving Maven artifacts
silenius Apr 13, 2011 10:46 PM (in response to kpiwko)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
kpiwko Apr 16, 2011 3:19 PM (in response to silenius)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
silenius Apr 26, 2011 10:42 AM (in response to kpiwko)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
kpiwko Apr 27, 2011 4:44 AM (in response to silenius)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
silenius Jun 28, 2011 12:08 PM (in response to kpiwko)Hi Karel,
Would love to hear your thoughts on https://issues.jboss.org/browse/SHRINKWRAP-261.
Cheers,
Samuel
-
20. Re: Resolving Maven artifacts
spinner Aug 9, 2011 8:27 AM (in response to silenius)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
alrubinger Aug 9, 2011 8:41 AM (in response to spinner)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
kpiwko Aug 9, 2011 10:25 AM (in response to spinner)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
kpiwko Aug 9, 2011 10:27 AM (in response to alrubinger)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
spinner Aug 9, 2011 12:22 PM (in response to kpiwko)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
lightguard Aug 9, 2011 1:32 PM (in response to silenius)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
alrubinger Aug 9, 2011 4:28 PM (in response to lightguard)This is a great idea. Mind opening a JIRA with your thoughs?
S,ALR
-
27. Re: Resolving Maven artifacts
lightguard Aug 9, 2011 5:46 PM (in response to alrubinger)SHRINKWRAP-314
-
28. Re: Resolving Maven artifacts
silenius Aug 9, 2011 8:17 PM (in response to kpiwko)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 Sep 24, 2011 8:50 AM (in response to silenius)Hi all,
Can someone summarize the work done and especialy provide the community how we can use that !
Thanks