feat: delete files containing git properties #360
Conversation
|
@msuozzo ping for review |
pkg/archive/jar.go
Outdated
| // [here](https://github.com/git-commit-id/git-commit-id-maven-plugin/blob/95d616fc7e16018deff3f17e2d03a4b217e55294/src/main/java/pl/project13/maven/git/GitCommitIdMojo.java#L454). | ||
| // By default, these file are created in ${project.build.outputDirectory} and are hence at the root of the jar. | ||
| // We assume that the file name is 'git' as this is the default value for the plugin. | ||
| // However, the plugin allows customizing the file name. |
There was a problem hiding this comment.
good detail. have you seen anyone customize this in the wild?
There was a problem hiding this comment.
Yes, I saw it here. They customize the file path but not the file name. This project is part of Reproducible Central dataset so it was included in my analysis.
There was a problem hiding this comment.
oh wow so they actually allow configuring the path and file to be anything.
one option would be to go snooping for the pom.xml file, parse it, look for this config block, and determine where we'd expect to find the metadata (that is, assuming the configuration can't be injected with e.g. a packaging flag or env var that doesn't end up in the pom). it's overkill but i'm concerned that this being mutable makes this a trickier stabilizer to get to be accurate and/or precise.
thoughts? [not requesting anything be implemented yet]
There was a problem hiding this comment.
We could try doing so. Our parser should look for plugins whose artifact ID is git-commit-id-maven-plugin in all **/*/pom.xml. This could be declared under plugins or under profiles.plugins. profiles activate a subset of plugins based on the flags provided to the command. Once we do that, we can check its configuration. There is also a go library to parse POMs but does not seem very active. But a simple XML parser could also do the job.
|
It seems that there is a convention to group import declarations. However, |
|
By the way, we will also have to declare the new stabilizers we write under |
weird. wouldn't worry too much about it as long as gofmt isn't actively complaining
potentially? alternatively, we might add a separate JAR-specific top-level constant that we also expose in the set of all stabilizers in the CLI. Since it's not specific to the zip format but rather the JAR format, it might be worth keeping them separate. |
👍
Cool. We can take this up in a separate PR. |
Reference: git-commit-id/git-commit-id-maven-plugin#825
The files
git.jsonandgit. propertiesare generated by https://github.com/git-commit-id/git-commit-id-maven-plugin. We delete these files in the jar file to stabilize. We assume default configuration that the files are either calledgit.jsonorgit.properties.