Create Maven "lockfile" using built-in from maven.... It supports a dot, graphml and tgf output format. (And soon JSON!)

[pombredanne]

• See also https://github.com/search?q=maven+dependency+tree&type=repositories
• Note that the mvn dependency:tree command would typically process all pom.xml in the codebase at once, and would generate one tree for each each pom.xml
• a good set of args to run the command would be : mvn dependency:tree -DoutputFile=maven-dependency-tree.lock -DoutputType=graphml and optionally with-Dmaven.test.skip=true and -DskipTests to skip tests, or various other options (such as scope) to filter the tree. See https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html
• See also https://github.com/jfrog/maven-dep-tree

Note that Maven now has a JSON format!

• https://github.com/apache/maven-dependency-plugin/pull/325
• then https://github.com/apache/maven-dependency-plugin/pull/391

[monperrus]

https://github.com/chains-project/maven-lockfile should work well here, we can help with integration.

[pombredanne]

@monperrus Thanks. This would be great.

[LogFlames]

@pombredanne I'm starting to work on this implementation and wanted to ask about how you prefer to handle modules?

maven-lockfile behaves the same as mvn dependency:tree in regards to processing all pom.xml in the codebase (that are linked as modules) and generates one lockfile per pom file. Since the check if a lockfile already exists (and enforces the --force flag) is done in the Go code, I wonder how you prefer this be solved?

My suggestions are:

1. We check only the main lockfile.json in the root of the project. This might accidentally overwrite lockfiles in modules without warning and without requiring the --force flag.
2. We check for lockfiles.json in all folders of the project. This might accidentally require the --force flag even though nothing would get overwritten.
3. Use a maven plugin to list all poms belonging to the project. This would create an accurate --force flag, not pollute the Go code, but requires another plugin be installed by the user.
4. We parse the pom.xml in Go and check all module folders. This would make the footprint of the Go code much larger.

What do you think? Of course open to other suggestions/solutions!

[LogFlames]

Using the KISS principle I created a PR for option 1 to get it rolling. Happy to implement other option if preferred!

[LogFlames]

@pombredanne have you had time to look at this? wdyt of the options above?