Le jeudi 10 février 2022, 14:35:58 CET Delany a écrit : > Thanks I'll send PR. thank you for helping
> Since you ask, I think Maven should allow silencing any warning for any > plugin, but that's for another day. sure :) > > I'm not able to compare builds. I run `mvn clean install`, and `mvn clean > package artifact:compare` and I get an error "could not find repository > with id = central" ok, you're not in the easy setup: I suppose that you have a setting.xml that defines a mirror for central you'll need to "mvn clean package artifact:compare -Dreference.repo=xxx" with a value of repository that works for you I suppose the goal can be improved to support installed artifacts even if no remote repository is available: this is an edge case that I personally never needed, and of course, I'm coding the features I need first... ... > Is there really an "apache-maven-3.8.4-SNAPSHOT.buildinfo" available at > Central? no need for buildinfo to be stored anywhere: it's an internal temporary detail during the comparison process then no need to add artifact plugin to your pom.xml: you just need to call artifact:compare on CLI when checking current build against a previous reference build (focus on buildinfo in early days of my work on Reproducible Builds has been found as finally a wrong idea: artifact:compare is the important goal, that does its job without needing anything to be published to repositories) > > Regards, good feedback, thank you Regards, Hervé > Delany > > On Thu, 10 Feb 2022 at 04:46, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > > Le mercredi 9 février 2022, 09:31:00 CET Delany a écrit : > > > Hi Herve, > > > > > > I see you already check that the project.parent was part of the reactor > > > > and > > > > > you don't issue the warning if it is. > > > An edge case is the -rf switch. Even though you have the opportunity to > > > change files, the sense is that it is the same build being resumed, so I > > > would also not warn in this case. > > > > PRs welcome > > and eventually an evaluation of "is this purely theory or really a use > > case > > I'll face?" aspect: I honestly don't see why I would do a reproducibility > > check with "-pr", or if it while making precisely one module reproducible, > > the > > message is not ideal but not really harmful > > > > > The word parent can have two meanings here so rather avoid it in the > > > message. If the project.parent is not part of the build, then can you > > > > warn > > > > > 'outputTimestamp is inherited from groupId:artifactId but it is not > > > included in the build'. > > > > message is coded here > > https://github.com/apache/maven-artifact-plugin/blob/ > > master/src/main/java/org/apache/maven/plugins/artifact/buildinfo/ > > AbstractBuildinfoMojo.java#L158 > > <https://github.com/apache/maven-artifact-plugin/blob/master/src/main/java > > /org/apache/maven/plugins/artifact/buildinfo/AbstractBuildinfoMojo.java#L1 > > 58> > > > > gives at runtime: > > > > [WARNING] project.build.outputTimestamp property should not be inherited > > but > > defined in parent POM from reactor /home/me/project/pom.xml > > > > please propose rephrasing > > > > > If you make this warning configurable then a more in-depth explanation > > > could be included in that documentation. > > > > what do you think should be configurable? > > > > > BTW the build commands you gave suggest that artifact:compare will use > > > > the > > > > > local Maven repository as its reference repo. Isn't this a more sensible > > > default? > > > > I gave commands to locally test during SNAPSHOT development, to detect and > > fix > > if there are issues: then yes, in that case, comparison is done between 2 > > local builds, that's why the first command need to be install > > > > If it's about a release that has been published (eventually by someone > > else), > > "of course" you should do the first "install" run but only the second > > "package > > artifact:compare", and you'll see that by default it compares against > > central > > Just try to rebuild an artifact that was published by someone else = the > > ultimate goal, to check that you can rebuild what you are downloading > > > > and FYI, the Reproducible Central project is about rebuilding and checking > > such artifacts from central: > > https://github.com/jvm-repo-rebuild/reproducible-central > > > > Regards, > > > > Hervé > > > > > Thanks, > > > Delany > > > > > > On Wed, 9 Feb 2022 at 09:25, Hervé BOUTEMY <herve.bout...@free.fr> > > > > wrote: > > > > Hi Delany, > > > > > > > > Good question: let's see if we can improve the message that I added in > > > > MARTIFACT-28 [1] > > > > > > > > First, remember that it's all about Reproducible Builds [2]. > > > > As described in the MARTIFACT-28 issue, inheriting the parent pom > > > > release > > > > > > timestamp technically works (it gives a reproducible value to your > > > > current > > > > > > build), but does not match the current release/build timestamp: you > > > > probably > > > > prefer to have a timestamp defined in your reactor > > > > = that is the message that we need to make as clear as possible > > > > > > > > Don't hesitate to propose an updated message that fits inclusion in a > > > > plugin > > > > output... > > > > > > > > > > > > Notice that I'm surprised of your choice to set the outputTimestamp to > > > > $ > > > > > > {maven.build.timestamp}, given this value is not reproducible (if you > > > > build 2 > > > > time the same code, you'll get 2 different values), choosing this > > > > value > > > > defeats > > > > the whole purpose of the configuration. > > > > Remember, it's all about Reproducible Builds, and your objective is to > > > > run > > > > > > the > > > > build 2 times and check you get the same binary output: > > > > > > > > mvn clean install > > > > mvn clean package artifact:compare > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > [1] https://issues.apache.org/jira/browse/MARTIFACT-28 > > > > > > > > [2] > > > > https://maven.apache.org/guides/mini/guide-reproducible-builds.html > > > > > > Le mardi 8 février 2022, 11:04:33 CET Delany a écrit : > > > > > Hi. Why does maven-artifact-plugin complain > > > > > > > > > > [WARNING] project.build.outputTimestamp property should not be > > > > > > > > inherited > > > > > > > > > but defined in parent POM from reactor > > > > > > > > > > I never had a plugin complain about utilizing inheritance. Why does > > > > it > > > > > > care? > > > > > > > > > When I add the line to the project the warning disappears > > > > <project.build.outputTimestamp>${maven.build.timestamp}</project.build.out > > > > > > pu> > > > > > > > > > tTimestamp> > > > > > > > > > > Thanks, > > > > > Delany > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
