> Date: Fri, 3 Jan 2014 14:03:22 -0800 > Subject: Topologically sorted list of Artifacts for use by a plugin? > From: ljnel...@gmail.com > To: users@maven.apache.org > > Hello; in Maven 3.0.5 and 3.1.x, what is the preferred way, given a > MavenProject representing the current pom.xml/project, to obtain a list of > its resolved dependency Artifacts in test scope that has been topologically > sorted such that the Artifact at the head of the list has the fewest > dependencies and the artifact at the tail of the list has the most? > > I asked this question many moons ago ( > http://maven.40175.n5.nabble.com/Topologically-sorting-dependencies-tp3384898p3387803.html) > and after no answers, came up with what felt like an awful hack to produce > what I wanted, whose code I pasted in that message. > > If you follow the link, you'll see that I used the ProjectSorter class, > which is what Maven's reactor uses when processing a multi-module > project--which gives me exactly the order I wanted--but seems like overkill > and like misusing a tool, and maybe isn't the Right Way given all the new > Aether stuff and whatnot. Nevertheless, it is still how Maven's reactor > works, so...who knows. > > Anyway, I started there and "worked backwards"--needed a List of > MavenProjects to feed to it, so ended up using the MavenProjectBuilder, as > you can see in the link. > > That class has since been deprecated and moved to the compat layer, though, > and its replacement (another class named DefaultMavenProjectBuilder) has > removed the convenience method that I was using. I'd like to update my > plugin to avoid depending on this deprecated subsystem. > > So then: suppose I'm writing a Maven plugin that needs to fetch a > particular well-known classpath resource from all artifacts available in > test scope, and needs that list to be in topological order (starting with > an artifact that has the fewest dependencies and ending with the artifact > that has the most). What is the preferred mechanism for doing this these > days? Is it still by way of the ProjectSorter hammer? Or is there a more > elegant way to do it? > > (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.) MG>so I would say you are definitely on the right track MG>so ....ProjectSorter.java..... MG>public List getDependents( String id ) { return dag.getParentLabels( id ); } MG>will get you the required count of dependents you want MG> MG>so processing each child module strategy might implement something like: MG>"include in my reactor a known subset of selected artifacts" which would be implemented by.. MG>mvn reactor:make-dependents -Dmake.folders=childModule1 MG>(from features of maven-reactor-plugin) MG>http://maven.apache.org/plugins/maven-reactor-plugin/examples.html MG> MG>so a way of assessing all of the modules by executing each module ..one at a time MG> MG>for dir in /tmp/* MG>do MG> dir=${dir%*/} MG> mvn reactor:make-dependents -Dmake.folders=${dir##*/} MG>done MG> MG>*may* work as a Q&D test-harness to exercise each of your child modules MG>any reason for topological sorting of dependencies?
> Best, > Happy 2014, > Laird MG>Happy 2014 Laird, MG>Martin > -- > http://about.me/lairdnelson
