Ok great, than you Bapiste. Without reading this source, I'd never even have
found the shared dependency plug-in. These docs have been really frustrating.
I'm not going to sit and complain, I'm volunteering to work on them and help
make some high leven guides to steer people like me in the right direction with
the proper recipes, examples etc. That is, once I have my brain wrapped around
it myself!
So the animals I want are:
- DefaultDependencyGraphBuilder, which I can annotate as a component to
instantiate, and should handle M2,M3,M3.1
- ArtifactRepository localRepository, which I can load as a @Parameter with
defaultValue = "${localRepository}".
If I have a configuration parameter for my plugin which is a list of
dependencies unrelated to the project dependencies, e.g.
<configuration>
<dependencies>
<dependentartifact>
<name>
<grouppid>
<artifactid>
</dependentartifact>
Will I end up with a Set<Artifacts> dependencies? And then use the two classes
above to resolve the artifacts?
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Baptiste MATHUS
Sent: Sunday, July 21, 2013 8:24 AM
To: Maven Users List
Subject: RE: API to resolve an artifact in Maven3
See
http://svn.codehaus.org/mojo/trunk/mojo/extra-enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/EnforceBytecodeVersion.javaand
the dependency builder part.
Cheers
Le 21 juil. 2013 05:03, "Richard Sand" <[email protected]> a écrit :
> Can someone please share the secret of how to do dependency resolution
> in Maven3? And specifically in 3.1?
>
> -Richard
>
> -----Original Message-----
> From: Richard Sand [mailto:[email protected]]
> Sent: Friday, July 19, 2013 3:45 PM
> To: 'Maven Users List'
> Subject: RE: API to resolve an artifact in Maven3
>
> +1 Anthony. The question is what is the preferred 3.x way of doing it,
> +not
> how to do it the old way. Unless the official answer is "do it the old
> way because..."
>
>
> -----Original Message-----
> From: Anthony Dahanne [mailto:[email protected]]
> Sent: Friday, July 19, 2013 2:32 PM
> To: Maven Users List
> Subject: Re: API to resolve an artifact in Maven3
>
> hello, I 'm slightly confused about your answer Igor.
> The other day I was wondering about how to keep a maven plugin doing
> artifact resolution compatible with both maven 3.0 and 3.1 and Robert
> answered me to use the maven dependency tree api :
>
> http://stackoverflow.com/questions/17685441/can-a-maven-mojo-relying-o
> n-aeth
> er-be-compatible-with-maven-3-0-x-and-3-1-x#comment25769765_17686482
>
> Now I am using something like that :
> Artifact enforceArtifact =
>
> defaultArtifactFactory.createArtifact(enforceGroupId,enforceArtifactId
> ,enfor
> ceVersion,"",enforceType);
> MavenProject enforcePom =
> mavenProjectBuilder.buildFromRepository(
> enforceArtifact, remoteRepositories, localRepository);
> DependencyNode rootNode =
> dependencyGraphBuilder.buildDependencyGraph(enforcePom, new
> CumulativeScopeArtifactFilter(Arrays.asList(Artifact.SCOPE_COMPILE,
> Artifact.SCOPE_RUNTIME)));
>
> and that works pretty well (I used to think relying on aether directly
> was the best approach, until this change of package made my plugins
> not maven
> 3.1 compatible)
>
> Which approach would you consider the best then (when writing a plugin
> doing dependency resolution) , using the Maven 2 API with maven-compat
> or relying on maven-dependency-tree ?
> Thanks for your answer !
> Anthony
>
>
>
>
>
>
> On Fri, Jul 19, 2013 at 1:44 PM, <[email protected]> wrote:
>
> > Please check next post
> >
> > http://mail-archives.apache.org/mod_mbox/maven-users/201307.mbox/%3c
> > 7A [email protected]%3e
> > It should helps you
> >
> > On Jul 19, 2013, at 9:39 PM, "Richard Sand" <[email protected]>
> wrote:
> >
> > > Quick Q- what's the proper way to resolve an artifact in a Maven3
> > plug-in, e.g. where the artifact isn't already a managed dependency
> > in the project.
> > >
> > > I found the Mojo Developer Cookbook (
> > http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook)
> > but it gives the Maven2 technique, and the classes used are deprecated.
> > >
> > > -Richard
> > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
