maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laird Nelson <>
Subject Re: Topologically sorted list of Artifacts for use by a plugin?
Date Sun, 05 Jan 2014 00:11:02 GMT
On Fri, Jan 3, 2014 at 6:17 PM, Martin Gainty <> 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 (
>  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
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—but
buried in an obscure StackOverflow comment tangentially related to the
maven-dependency-plugin I found a reference to this class:
If I understand it right, then code like the following should do the
(untested, but you get the general idea):

public class Artifacts {

  private final DependencyGraphBuilder dependencyGraphBuilder;

  public Artifacts(final DependencyGraphBuilder dependencyGraphBuilder) {
    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
    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) {
      if (!returnValue.isEmpty()) {
    return returnValue;


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 Eclipse Aether kerfuffle that occurred between 3.0.5 and 3.1.x,
so this also seems like something that isn't going to be deprecated any
time soon.

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.  :-)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message