[silenius]

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?

[kpiwko]

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.

[silenius]

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

[kpiwko]

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

[silenius]

Hi Karel,

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

Cheers,

Samuel

[spinner]

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.

[alrubinger]

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

[kpiwko]

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

[kpiwko]

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

[spinner]

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.

[lightguard]

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?

[alrubinger]

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

S,

ALR

[lightguard]

SHRINKWRAP-314

[silenius]

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?

[badr]

Hi all,

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

Thanks