You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Delany <de...@gmail.com> on 2022/02/08 10:04:33 UTC
martifact won't inherit project.build.outputTimestamp
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.outputTimestamp>
Thanks,
Delany
Re: martifact won't inherit project.build.outputTimestamp
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <he...@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 <he...@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: martifact won't inherit project.build.outputTimestamp
Posted by Delany <de...@gmail.com>.
Thanks I'll send PR.
Since you ask, I think Maven should allow silencing any warning for any
plugin, but that's for another day.
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"
If I set referenceRepo to <referenceRepo></referenceRepo> it still
complains "could not find repository with id = central"
If I set referenceRepo to a custom repository and it predictably can't
download the .buildinfo file, it gives a NPE
What should I do?
I checked out maven source code (which doesn't use maven-artifact-plugin).
I added the plugin buildinfo goal, rebuilt, and did a comparison. It says
[INFO] --- maven-artifact-plugin:3.2.0:compare (default-cli) @ apache-maven
---
[WARNING] SCM source tag in buildinfo source.scm.tag=maven-3.8.3 does not
permit rebuilders reproducible source checkout
[INFO] Saved aggregate info on build to
/git/maven/apache-maven/target/apache-maven-3.8.4-SNAPSHOT.buildinfo
[INFO] Aggregate buildinfo copied to
/git/maven/target/maven-3.8.4-SNAPSHOT.buildinfo
[INFO] Checking against reference build from central-mirror...
[INFO] Reference buildinfo file found, copied to
/git/maven/target/reference/apache-maven-3.8.4-SNAPSHOT.buildinfo
[INFO] Reproducible Build output summary: 32 files ok
[INFO] Reproducible Build output comparison saved to
/git/maven/apache-maven/target/apache-maven-3.8.4-SNAPSHOT.buildcompare
[INFO] Aggregate buildcompare copied to
/git/maven/target/maven-3.8.4-SNAPSHOT.buildcompare
Is there really an "apache-maven-3.8.4-SNAPSHOT.buildinfo" available at
Central?
Regards,
Delany
On Thu, 10 Feb 2022 at 04:46, Hervé BOUTEMY <he...@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#L158>
>
> 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 <he...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: martifact won't inherit project.build.outputTimestamp
Posted by Hervé BOUTEMY <he...@free.fr>.
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
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 <he...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: martifact won't inherit project.build.outputTimestamp
Posted by Delany <de...@gmail.com>.
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.
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'.
If you make this warning configurable then a more in-depth explanation
could be included in that documentation.
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?
Thanks,
Delany
On Wed, 9 Feb 2022 at 09:25, Hervé BOUTEMY <he...@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.outpu
> > tTimestamp>
> >
> > Thanks,
> > Delany
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: martifact won't inherit project.build.outputTimestamp
Posted by Hervé BOUTEMY <he...@free.fr>.
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.outpu
> tTimestamp>
>
> Thanks,
> Delany
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org