1

I'm looking for a (supported) mvn based command, which will give me a list of all the GroupID:ArtifactID:Version (GAV) for all artifacts that running a mvn package command would produce.

For a single module Maven project, with no parent pom, this is trivial: you can look inside the pom.

For a single module Maven project, with a parent pom, you could use help:effective-pom and it will present a pom file with the <version> element present.

For a multi module Maven project (reactor), you could actually do the same (didn't think so, learned so just now by trying it out). This will allow parsing the file for (multiple) <project> elements.

Anything else to consider?

The overall goal of this, is to be able to feed a downstream Continuous Delivery (http://go.cd/) stage/step/job with information on what version of it's upstream dependencies should be used.

Fredrik Wendt
  • 988
  • 1
  • 10
  • 17
  • a single maven module can actually produce multiple artifacts, if you count qualifier (like *-source, *-tests, *-javadocs). and with ugly invocations of the maven jar plugin im sure i could rig it to even produce multiple GAVs. i think the only "safe" way is run "mvn install" and see what ends up being put into the local repo – radai May 08 '16 at 04:37
  • Using the maven-jar-plugin i have great doubts that you create jar for different groupId:artifactId:version cause the maven-jar-plugin attaches/replaces the artifacts of the main project which is defined by it's pom which can have only a single g:a:v ... – khmarbaise May 08 '16 at 11:38

1 Answers1

1

In general you can't produce a list before the build has run...The problem is that based on the pom model not all artifacts are described, cause some plugins can produce supplemental artifacts (maven-assembly-plugin, maven-shade-plugin, maven-jar-plugin via test-jar etc.)

What you can make is to get a list of produced artifacts after a build has run..(installed). The question of yours inspired me to implement an EventSpy which produces such list at the end of the build...which looks like this:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.423 s
[INFO] Finished at: 2016-05-08T13:22:10+02:00
[INFO] Final Memory: 24M/310M
[INFO] ------------------------------------------------------------------------
[INFO] --             Maven Artifact Collector Summary                       --
[INFO] ------------------------------------------------------------------------
[INFO] test.maven.plugin.profiler:parse-pom:0.1.0-SNAPSHOT:jar
[INFO] test.maven.plugin.profiler:parse-pom:0.1.0-SNAPSHOT:pom
[INFO] test.maven.plugin.profiler:parse-pom:0.1.0-SNAPSHOT:jar:jar-with-dependencies

What i can do is to enhance that and write a file which contains the information (in more or less any format)...At the moment it's just a PoC...May be you can give some more information or create issues or PR's and request what might be needed...may be this is also interesting for others...

Furthermore your downstream part must have those artifacts within a repository cache available (either on a file system or via a repository manager or docker data container)...

khmarbaise
  • 92,914
  • 28
  • 189
  • 235
  • I have a home brewn Maven repository (written in Python currently) which allows one repo to be a child of many parents. For each step in a chain of build steps, I create a repo when the step starts, pretty much: `curl http://repo-manager/repo/child-build-step/1/run/1 -d parent=parent-build-step/1/run/2` which makes all artifacts in parent-build-step/1/run/2 available for the current build of child-build-step. – Fredrik Wendt Jul 27 '16 at 09:15
  • With "my" solution, you can always work with version-less dependencies, and simply pull latest from the repo you have access to. You will only get access to the builds in your pipeline tree/ancestry. You may get a similar solution with one "physical" and one "virtual" repo per build step. My experiences from Nexus 2 simply has been so crappy (enterprise level, ~200 GB or new artifacts to permanently store per month) that I find no reason to waste my time on it more. Nexus 3 doesn't come with official Maven repo support. Artifactory would work, but API requires buying a license. – Fredrik Wendt Jul 27 '16 at 14:17
  • First Nexus 2 and 3 have cleanup tasks for SNAPSHOT's (I'm working with size larger than 1 TiB etc. No problem). Furthermore Nexus 3 has support for Maven repo out of the box... And what do you mean by versionless deps ? – khmarbaise Jul 27 '16 at 14:46
  • We kept a strict set of 10 SNAPSHOTs around. The 200 GB were not SNAPSHOTs and we stored over 4 TiB when I left. The snapshots accounted for a rather fix size and rotated nicely, using our own cleaning scripts. Versionless dependencies are when poms/build.gradle dependencies' version values are overwritten each build by the CI/CD system. They pick the correct version based on the pipelining of your build steps. Put changeset ID and pom file in the binary if you want traceability (or tag/commit history on non-develop branch, or separate repo). – Fredrik Wendt Jul 27 '16 at 21:53
  • Ah Ok. So you only need a strategy to delete the released artifacts which are not tagged ? – khmarbaise Jul 28 '16 at 06:44