Re: last review of Reproducible Builds proposal

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

Re: last review of Reproducible Builds proposal

Michael Osipov-2
Am 2019-10-05 um 23:15 schrieb Emmanuel Bourg:

> Le 05/10/2019 à 19:52, Hervé BOUTEMY a écrit :
>> based on the feedback I got, I updated the proposal:
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
>>
>> The archives entries timestamp is now configured with project.build.outputTimestamp property, in ISO-8601 format
>> <project>
>>    <properties>
>>      <project.build.outputTimestamp>2019-10-02T08:04:00Z</project.build.outputTimestamp>
>>    </properties>
>> </project>
>
> You may want to specify explicitly that the timestamp must be formatted
> with the UTC timezone (as in your example).

No, if you have a decent format, like ISO 8601, it is regardless of the
timezone offset because it is properly parsed to.

Michael


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

Reply | Threaded
Open this post in threaded view
|

Re: last review of Reproducible Builds proposal

Hervé BOUTEMY
Le dimanche 6 octobre 2019, 16:41:27 CEST Emmanuel Bourg a écrit :
> Le 06/10/2019 à 09:43, Hervé BOUTEMY a écrit :
> > Notice that you can also express a timezone (as digits), as seen in the
> > unit tests.
> I know but that's not desirable, otherwise the formatted timestamp would
> depend on the timezone of the developer
no, it does not add any dependency on developer configuration:
2019-10-05T18:37:42Z == 2019-10-05T20:37:42+02:00 == 2019-10-05T16:37:42-02:00

> and that would harm the
> reproducibility of the pom (I assume the timestamp is added
> automatically to the pom during the build, is that right?).
when will this value be written in the pom.xml is independant: currently, in
my PoC, I wrote the values by hand. In the future, it will probably be updated
by maven-release-plugin, and we'll have to choose if the timestamp is written
in Z or if it is written in local timezone with its offset: both ways of
expressing the timestamp are valid and will give reproducible result

>
> >> Would it be possible to prevent this property from being inherited?
> >
> > AFAIK no.
> > And I find that default inheritance from parent to child is a nice
> > feature.
>
> Why do you think this is a nice feature? I can only see the downside of
> child projects having a timestamp clamped in the past and leaving the
> developers clueless about the reason. This would be especially bad if a
> widely used parent pom like org.sonatype.oss:oss-parent or
> org.apache:apache had it.
once again, war files taken apart for web servers, who looks at timestamp in
zip files?

>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> 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: last review of Reproducible Builds proposal

Mark Derricutt
In reply to this post by Michael Osipov-2

On 6 Oct 2019, at 9:14, Hervé BOUTEMY wrote:

if anybody cares about the exact value: but
who really looks at the timestamp of entries in release zips/jars/tar.gz
honestly?

I've actually done so in the past trying to find differences between two versions of a jar for repair reasons.

VERY infrequent tho - if you're wanting to generate a delta-patch between two jars/zips then I guess it might also be handy (altho you might be better off going direct for checksumdifferences there ).


"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc (546 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: last review of Reproducible Builds proposal

Enrico Olivelli
In reply to this post by Michael Osipov-2
Il ven 11 ott 2019, 08:31 Christofer Dutz <[hidden email]> ha
scritto:

> Just a small question. I have been following this thread with great
> interest.
>
> I think this is going to be a big thing when it makes the changes
> available to the main maven system.
>
> So as far as I understand the core part will be a fixed timestamp which
> will then be used throughout the build by multiple pluggins.
>
> So if I provide the same timestamp the result should be binary identical.
>
> Would it be possible to have this timestamp written/updated in the pom as
> part of the release:prepare step?
>

Yep, this was one of my questions at the beginning of this thread.
I see value in this proposal

Enrico




> Sort of setting it to some constant (ie REPODUCEABLE_BUILD_TIMESTAMP)
> simply takes the current time but if there is a concrete value, it uses
> that instead?
>
> Hope im not asking anything obvious. To me it looked as if the timestamp
> has to be manipulated manually.
>
> Chris
>
> Holen Sie sich Outlook für Android<https://aka.ms/ghei36>
> ________________________________
> From: Emmanuel Bourg <[hidden email]>
> Sent: Thursday, October 10, 2019 11:50:34 PM
> To: [hidden email] <[hidden email]>
> Subject: Re: last review of Reproducible Builds proposal
>
> Le 10/10/2019 à 19:28, Hervé BOUTEMY a écrit :
>
> > the only little mis-interpretation is that it is a pure build
> information,
> > then I don't see why this property would appear in a consumer POM
>
> Thank you for the clarification, that makes perfectly sense. And I now
> see the benefit of using a property that can be inherited. In a multi
> modules project it's only necessary to define the timestamp once in the
> root pom. Parent poms deployed to Maven Central will never include a
> timestamp and there is no risk of affecting other projects deriving from
> the pom.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>