Re: [DISCUSS] configuration for Reproducible Builds

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] configuration for Reproducible Builds

Enrico Olivelli
Hervé
When will you set this value? During release:prepare and modify the pom?

Enrico

Il sab 28 set 2019, 17:55 Hervé BOUTEMY <[hidden email]> ha scritto:

> Achieving Reproducible Builds require only one parameter: plugins that
> create
> zip or tar archives require a fixed timestamp for entries
>
> Putting that parameter as a pom property with a well known name and value
> format permits to share the configuration between every packaging plugin.
> This also has the advantage that child poms will inherit from parent
> value,
> and eventually override.
>
> The question is: *what property name and what value format should we keep?*
>
> For the PoC, I chose to extrapolate from a convention from Reproducible
> Builds
> project, which is very Linux-oriented: SOURCE_DATE_EPOCH environment
> variable,
> that I transformed into source-date-epoch property name, keeping the "date
> +
> %s" value
> https://reproducible-builds.org/docs/source-date-epoch/
>
>
> But I feel we can do a more user-readable solution by choosing another
> name
> and format, like "reproducible-build-timestamp" with an ISO-8601 combined
> date
> and time representation
>
>
> WDYT? Any other idea?
>
> Regards,
>
> Hervé
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] configuration for Reproducible Builds

Karl Heinz Marbaise-3
Hi Hervé,


On 29.09.19 11:19, Hervé BOUTEMY wrote:
> regarding the property name, I had an idea:
>
> why not do like we already did for  ${project.build.sourceEncoding}, ie. mimic
> a future element in pom.xml, in build?
>
> could be project.build.timestamp?


This sounds like the best idea...


This would mean to define something like this:

<properties>
   <project.build.timestamp>..</project.build.timestamp>
</properties>

But now there are coming up some questions:

* Is that the real value to be used?
* Or should it activate the mechanism ? (boolean?)

<properties>
   <project.build.timestamp.usage>true</project.build.timestamp.usage>
</properties>


* Or should we use it by default and giving the user the opportunity
   to overrite the current timestamp by fixed timestamp for building ?
   This means we would define only the real time to be used during
   building. No need for a kind of activation etc.
   So you could call Maven via:

   mvn -Dproject.build.timestamp=... package


* Or do we need a combination of the above

   First activate, define the format and the timestamp to be used.


Furthermore do we need to define a format either which could look like this:

<properties>
   <project.build.timestamp.usage>true</project.build.timestamp.usage>
   <project.build.timestamp>..</project.build.timestamp>
   <project.build.timestamp.format>ISO-8601</project.build.timestamp.format>
</properties>


Kind regards
Karl Heinz Marbaise

>
> Le samedi 28 septembre 2019, 17:55:24 CEST Hervé BOUTEMY a écrit :
>> Achieving Reproducible Builds require only one parameter: plugins that
>> create zip or tar archives require a fixed timestamp for entries
>>
>> Putting that parameter as a pom property with a well known name and value
>> format permits to share the configuration between every packaging plugin.
>> This also has the advantage that child poms will inherit from parent value,
>> and eventually override.
>>
>> The question is: *what property name and what value format should we keep?*
>>
>> For the PoC, I chose to extrapolate from a convention from Reproducible
>> Builds project, which is very Linux-oriented: SOURCE_DATE_EPOCH environment
>> variable, that I transformed into source-date-epoch property name, keeping
>> the "date + %s" value
>> https://reproducible-builds.org/docs/source-date-epoch/
>>
>>
>> But I feel we can do a more user-readable solution by choosing another name
>> and format, like "reproducible-build-timestamp" with an ISO-8601 combined
>> date and time representation
>>
>>
>> WDYT? Any other idea?
>>
>> Regards,
>>
>> Hervé
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] configuration for Reproducible Builds

Robert Scholte-8
In reply to this post by Enrico Olivelli
On Sun, 29 Sep 2019 12:41:17 +0200, Enrico Olivelli <[hidden email]>  
wrote:

> Il dom 29 set 2019, 12:16 Robert Scholte <[hidden email]> ha  
> scritto:
>
>> I would think that all project.* properties represent the pom.xml and  
>> are
>> immutable. To be more precise: the same pom.xml should effectively stay
>> the same with every build.
>> Instead this seems more related the (maven)session, right?
>>
>
> If I understand correctly the value f this property is to be committed in
> the source code.
> Some thoughts:
> - it should default to 'now' sampled at the beginning of the session
> - it can be overridden with a value writen in the pom or on a source file
> - it must be sampled and commited as final value during a 'release  
> process'
>

There is already a property with a similar name: maven.build.timestamp
We need to keep in mind when thinking of a good name: which one is used  
for what?

Reading the mail again, it looks like it is not about the timestamp of the  
build. It is more about setting the lastModified value (and maybe also  
created + opened?) of files inside the archive.
I would prefer a name that clearly reflects that.

I don't like the idea of being able to set a property that starts with  
`project.`.
Based on stack overflow people find it sometimes hard to understand, so we  
should be very clear about this:
`project.` represents project-roottag of the pom.xml, and with this you  
can read any value, but you cannot SET a value.

Is this value important for snapshots too? If not, it shouldn't be too  
hard to adjust the maven-release-plugin for setting an explicit value.

Robert

[1]  
https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Available_Variables


>
> Enrico
>
>
>
>> Robert
>>
>> On Sun, 29 Sep 2019 11:19:45 +0200, Hervé BOUTEMY  
>> <[hidden email]>
>>
>> wrote:
>>
>> > regarding the property name, I had an idea:
>> >
>> > why not do like we already did for  ${project.build.sourceEncoding},
>> ie.
>> > mimic
>> > a future element in pom.xml, in build?
>> >
>> > could be project.build.timestamp?
>> >
>> > Le samedi 28 septembre 2019, 17:55:24 CEST Hervé BOUTEMY a écrit :
>> >> Achieving Reproducible Builds require only one parameter: plugins  
>> that
>> >> create zip or tar archives require a fixed timestamp for entries
>> >>
>> >> Putting that parameter as a pom property with a well known name and
>> >> value
>> >> format permits to share the configuration between every packaging
>> >> plugin.
>> >> This also has the advantage that child poms will inherit from parent
>> >> value,
>> >> and eventually override.
>> >>
>> >> The question is: *what property name and what value format should we
>> >> keep?*
>> >>
>> >> For the PoC, I chose to extrapolate from a convention from  
>> Reproducible
>> >> Builds project, which is very Linux-oriented: SOURCE_DATE_EPOCH
>> >> environment
>> >> variable, that I transformed into source-date-epoch property name,
>> >> keeping
>> >> the "date + %s" value
>> >> https://reproducible-builds.org/docs/source-date-epoch/
>> >>
>> >>
>> >> But I feel we can do a more user-readable solution by choosing  
>> another
>> >> name
>> >> and format, like "reproducible-build-timestamp" with an ISO-8601
>> >> combined
>> >> date and time representation
>> >>
>> >>
>> >> WDYT? Any other idea?
>> >>
>> >> Regards,
>> >>
>> >> Hervé
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] configuration for Reproducible Builds

Emmanuel Bourg
In reply to this post by Enrico Olivelli
Le 28/09/2019 à 17:55, Hervé BOUTEMY a écrit :

> Putting that parameter as a pom property with a well known name and value
> format permits to share the configuration between every packaging plugin.
> This also has the advantage that child poms will inherit from parent value,
> and eventually override.

It seems a bit odd to me to tie the build timestamp to the pom. The fact
that it could be inherited is disturbing, i.e. if you forget to override
it in a subproject your build time will be wrong.


> WDYT? Any other idea?

I thought the timestamp would rather go to a separate file deployed
along the pom and capturing the build environment. What Maven needs then
is a command line parameter to force a specific build time (and/or
support for the SOURCE_DATE_EPOCH environment variable).

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]