it's pretty straight forward if you use some code provided by the dependencies library (part of the maven-dependencies-plugin)
I wrote some code that uses it for the dependency convergence enforcer rule: http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.0/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java?view=markup <http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.0/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java?view=markup>in the execute you can see it gets a DependencyNode and passes a Vistor to it. In my case I used a visitor to get all the version numbers I needed. You could use the DependencyNodes (which have a getArtifact) and pass that artifact to an artifact resolver. keep a set of what you got. done and done. I don't know the current opinion on used the dependency api vs aether. Rex On Thu, Nov 18, 2010 at 3:24 PM, Lindsay Smith <[email protected]>wrote: > Thanks for the reply. > > Yes - using eclipse code would be lovely. There are efforts to bridge > maven and the eclipse build systems together, notably the Sonatype Tycho > project. However the missing piece right now is building p2 repositories > from Maven artifacts. Eclipse is quite happy to build them from bundles > found in other p2 repositories, or from bundles on the file system, but > there doesn't seem to be any established way yet of building them from a > project referring to Maven dependencies. > > I'm working on a way to do it using a maven project that downloads the > dependencies to the file system and calls some eclipse code to build the > repo, but I forsee that not being able to include multiple versions of the > same artifact would limit this approach over time. > > Thanks for the links, they provide interesting reading. Much appreciated. > > Lindsay > > > > -----Original Message----- > > From: Barrie Treloar [mailto:[email protected]] > > Sent: Thursday, 18 November 2010 4:14 p.m. > > To: Maven Developers List > > Subject: Re: Access to the raw list of dependencies - multiple versions > > of an artifact included > > > > On Thu, Nov 18, 2010 at 7:17 AM, Lindsay Smith <[email protected]> > > wrote: > > > Hi, > > > > > > > > > > > > I have a need to be able to download all the dependencies from a pom, > > even if there are multiple versions of the same dependency in the pom. > > The use case is that I'm hoping to use maven to create p2 repositories, > > and so these repositories can easily contain multiple versions of a > > bundle. > > > > > > > > > > > > I understand that maven's dependency resolution system culls multiple > > versions out, because its taking the view that the dependencies form a > > classpath. I expect to have to write a plugin to perform essentially > > what the dependency:copy-dependencies goal does, except that it needs > > to read the raw list of dependencies rather than the resolved list. > > > > > > > > > > > > What's the correct way to achieve this in a plugin? The MavenProject > > type contains the resolved list of dependencies, if I use the > > MavenModel type will this give me access to the raw list? If so, will > > I also have to manually process any inherited pom dependencies if I > > wanted to? > > > > > > > > > > > > Of course if there is an existing way to achieve this that would be > > even better. All help appreciated. > > > > If you are using p2, why aren't you using Eclipse code - there should > > be something to do this already. > > > > This is probably the reverse of > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=283745 > > > > You have a couple of options. > > > > Have a look at Aether https://docs.sonatype.org/display/AETHER/Home > > This may be all you need to trawl the repository for the bits you want. > > > > You may be able to get DefaultArtifactResolver > > (org.apache.maven.artifact.resolver.DefaultArtifactResolver.java from > > org.apache.maven:maven-artifact-manager:*) to do what you want, or at > > least look at the code to obtain the meta data and do the resolution > > yourself. > > > > --------------------------------------------------------------------- > > 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] > >
