> Date: Sat, 4 Jan 2014 16:11:02 -0800 > Subject: Re: Topologically sorted list of Artifacts for use by a plugin? > From: ljnel...@gmail.com > To: users@maven.apache.org > > On Fri, Jan 3, 2014 at 6:17 PM, Martin Gainty <mgai...@hotmail.com> wrote: > > > MG>so I would say you are definitely on the right track > > > > Thanks; I'm not sure I am. > > > > MG>any reason for topological sorting of dependencies? > > > > In my original post, I wrote: > > (As background: I am working with Liquibase (http://www.liquibase.org/). > > Each of my .jar projects has a META-INF/liquibase/changelog.xml file in > > it. Various of these .jar projects already depend on each other--for unit > > and integration testing, I'd like to use this dependency order, harvest the > > changelog.xml resources in each .jar file, and then combine them to create > > only the database tables actually needed for the test. If a.jar has A's > > tables, and b.jar has B's tables and b.jar depends on a.jar, then I'd like > > to run a.jar!/META-INF/liquibase/changelog.xml first, then > > b.jar!/META-INF/liquibase/changelog.xml next, and I'd like to not have to > > specify this in any place in my pom.xmls, since the dependency order is > > already captured there.) > > > So the fact that I'm using > ProjectSorter<http://maven.apache.org/ref/3.0.5/maven-core/apidocs/org/apache/maven/project/ProjectSorter.html>strikes > me as wrong—worse than wrong: an awful hack, in fact—because I am > basically using the reactor to sort MavenProjects that I've roped in from > elsewhere. Yucko. > > Various people have noted tersely that the maven-dependency-plugin is what > I want. Of course, its *goals* are completely useless for this task MG_01_05>I went the same tack but I couldnt find a goal to collect all the dependencies so I deprecated that thought process
>—but > buried in an obscure StackOverflow comment tangentially related to the > maven-dependency-plugin I found a reference to this class: > http://maven.apache.org/shared/maven-dependency-tree/apidocs/index.html?org/apache/maven/shared/dependency/graph/DependencyGraphBuilder.html > If I understand it right, then code like the following should do the > trick > (untested, but you get the general idea): > > public class Artifacts { > > private final DependencyGraphBuilder dependencyGraphBuilder; > > public Artifacts(final DependencyGraphBuilder dependencyGraphBuilder) { > super(); > this.dependencyGraphBuilder = dependencyGraphBuilder; > } > > public Collection<? extends Artifact> > getDependencyArtifactsInTopologicalOrder(final MavenProject project) throws > DependencyGraphBuilderException { > List<Artifact> returnValue = null; > final DependencyNode projectNode = > this.dependencyGraphBuilder.buildDependencyGraph(project, null /* no > ArtifactFilter; prob. need one */); > assert projectNode != null; > final CollectingDependencyNodeVisitor visitor = new > CollectingDependencyNodeVisitor(); > projectNode.accept(visitor); > final Collection<? extends DependencyNode> nodes = visitor.getNodes(); > if (nodes != null && !nodes.isEmpty()) { > returnValue = new ArrayList<Artifact>(); > for (final DependencyNode node : nodes) { > if (node != null) { > final Artifact artifact = node.getArtifact(); > if (artifact != null) { > returnValue.add(artifact); > } > } > } > if (!returnValue.isEmpty()) { > Collections.reverse(returnValue); > } > } > return returnValue; > } > > } MG_01_05>An excellent test-case for maven-dependency-tree > > I think that might be the right way to do it. It's unclear to me how > Maven's internals themselves make use of this class, but it is probably > used somewhere, and it clearly hides and mediates between the Sonatype > Aether and MG_01_05>most of the Original Sonatype authors monitor this list.. > Eclipse Aether kerfuffle that occurred between 3.0.5 and 3.1.x, MG_01_05>a fair amount of confusion once IBM orphaned Eclipse to OpenSource mavens MG_01_05>The one 'positive' we 'gain' is seamless integration to Eclipse IDE.. > so this also seems like something that isn't going to be deprecated any > time soon. MG_01_05>lets hope..! > IWBNI there were a quick primer in the documentation somewhere about how > Maven loads its own guts. I know that fundamentally Maven is just a bundle > of components that get instantiated and wired together by Plexus but it > sure is confusing to try to figure out how and where something is called—as > a result when there are problems you have to go digging through, well, > obscure StackOverflow questions. :-) MG_01_05>usually if we can funnel the permutations of thought processes to one specific question an answer will be MG_01_05>shortly forthcoming for a real adventure in managing maven repositories thru Embedding I invite you to take ride on MG_01_05>the Aether train MG_01_05>http://blog.sonatype.com/2010/08/introducing-aether/ > Best, > Laird MG_01_05>Thanks for taking time to 'think this through' MG_01_05>All the Best, Martin- > > -- > http://about.me/lairdnelson