[jira] [Comment Edited] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp
[
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16949296#comment-16949296
]
Michael Osipov edited comment on MSHARED-837 at 10/11/19 9:05 AM:
--
As for the style: The ISO definition provides two styles basic and extended.
Basic can drop {{-}} and {{:}} delimiters while extended retains them. All
components date, time, offset but be either basic or extended format. You are
not allowed to mix them. Just using {{X}} with the extended style would allow
{{2019-10-11T10:56:00+02}} (valid), {{2019-10-11T10:56:00+0200}} (invalid) and
{{2019-10-11T10:56:00+02}} (valid). In basic format this would be
{{20191011T105600+02}} (valid), {{20191011T105600+0200}} (valid) and
{{20191011T105600+02:00}} (invalid).
This is due to the lenient and telescoping nature of SDF. See also
[here|https://stackoverflow.com/q/13088140/696632]. So you can only use the
extended format with this implementation and stick to {{XXX}} and all is fine.
I don't think that just changing code and updating test would have really
helped because I wanted you to understand what I object here since you didn't
understand how telescoping in SDF works. Principal understanding is more
important than pure code. I will change my branch accordingly with the tests.
was (Author: michael-o):
As for the style: The ISO definition provides two styles basic and extended.
Basic can drop {{-}} and {{::}} delimiters while extended retains them. All
components date, time, offset but be either basic or extended format. You are
not allowed to mix them. Just using {{X}} with the extended style would allow
{{2019-10-11T10:56:00+02}} (valid), {{2019-10-11T10:56:00+0200}} (invalid) and
{{2019-10-11T10:56:00+02}} (valid). In basic format this would be
{{20191011T105600+02}} (valid), {{20191011T105600+0200}} (valid) and
{{20191011T105600+02:00}} (invalid).
This is due to the lenient and telescoping nature of SDF. See also
[here|https://stackoverflow.com/q/13088140/696632]. So you can only use the
extended format with this implementation and stick to {{XXX}} and all is fine.
I don't think that just changing code and updating test would have really
helped because I wanted you just to understand what I object here since you
didn't understand how telescoping in SDF works. Principal understanding is more
important that pure code. I will change my branch accordingly with the tests.
> add an API to configure Reproducible Builds with outputTimestamp
>
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.1
>
>
> creating an archive in a Reproducible Builds way requires to configure
> archiver with an output timestamp: see
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because
> Plexus Date injection uses local timezone, then is not reproducible: see
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and
> provide an API to parse this String to a Date, before calling
> plexus-archiver's configureReproducible
> https://github.com/codehaus-plexus/plexus-archiver/pull/121
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp
[
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16948227#comment-16948227
]
Herve Boutemy edited comment on MSHARED-837 at 10/10/19 6:07 AM:
-
no, I didn't have any time until now: you know, it's my free time
I just read the code, did not have time to run it to discover the impact
for
https://github.com/apache/maven-archiver/commit/2f45473f180cbd1fdc2b828095e2f0e57d077a0e,
you transform X to XXX without proving anything about the impact: I don't know
why XXX is better than X, nor what it means
for
https://github.com/apache/maven-archiver/commit/9e7cc4daf109b8970ae6517ac6d4c132ec942b14
, you add a new dependency and tell me that it is better because it fails a
unit test, that makes me think it removes some supported formats for setting a
timestamp
I don't see why I would not simply rely on JDK's DateFormat X: it works, is
easy to use, easy to understand for users.
If you want, I remove the comment on ISO, since you tell it's not ISO: I don't
care if it's not ISO
was (Author: hboutemy):
no, I didn't have time until now: you know, it's my free time
for
https://github.com/apache/maven-archiver/commit/2f45473f180cbd1fdc2b828095e2f0e57d077a0e,
you transform X to XXX without proving anything about the impact: I don't know
why XXX is better than X, nor what it means
for
https://github.com/apache/maven-archiver/commit/9e7cc4daf109b8970ae6517ac6d4c132ec942b14
, you add a new dependency and tell me that it is better because it fails a
unit test, that makes me think it removes some supported formats for setting a
timestamp
I don't see why I would not simply rely on JDK's DateFormat X: it works, is
easy to use, easy to understand for users.
If you want, I remove the comment on ISO, since you tell it's not ISO: I don't
care if it's not ISO
> add an API to configure Reproducible Builds with outputTimestamp
>
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.1
>
>
> creating an archive in a Reproducible Builds way requires to configure
> archiver with an output timestamp: see
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because
> Plexus Date injection uses local timezone, then is not reproducible: see
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and
> provide an API to parse this String to a Date, before calling
> plexus-archiver's configureReproducible
> https://github.com/codehaus-plexus/plexus-archiver/pull/121
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp
[
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16948227#comment-16948227
]
Herve Boutemy edited comment on MSHARED-837 at 10/10/19 5:59 AM:
-
no, I didn't have time until now: you know, it's my free time
for
https://github.com/apache/maven-archiver/commit/2f45473f180cbd1fdc2b828095e2f0e57d077a0e,
you transform X to XXX without proving anything about the impact: I don't know
why XXX is better than X, nor what it means
for
https://github.com/apache/maven-archiver/commit/9e7cc4daf109b8970ae6517ac6d4c132ec942b14
, you add a new dependency and tell me that it is better because it fails a
unit test, that makes me think it removes some supported formats for setting a
timestamp
I don't see why I would not simply rely on JDK's DateFormat X: it works, is
easy to use, easy to understand for users.
If you want, I remove the comment on ISO, since you tell it's not ISO: I don't
care if it's not ISO
was (Author: hboutemy):
no, I didn't have time until now: you know, it's my free time
for
https://github.com/apache/maven-archiver/commit/2f45473f180cbd1fdc2b828095e2f0e57d077a0e,
you transform X to XXX without proving anything about the impact: I don't know
why XXX is better than X, nor what it means
for
https://github.com/apache/maven-archiver/commit/9e7cc4daf109b8970ae6517ac6d4c132ec942b14
, you add a new dependency and tell me that it is better because it fails a
unit test, that makes me think it removes some supported formats for setting a
timestamp
I don't see why I would not simply rely on JDK's DateFormat X: it works, is
easy to use, easy to understand for users.
> add an API to configure Reproducible Builds with outputTimestamp
>
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.1
>
>
> creating an archive in a Reproducible Builds way requires to configure
> archiver with an output timestamp: see
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because
> Plexus Date injection uses local timezone, then is not reproducible: see
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and
> provide an API to parse this String to a Date, before calling
> plexus-archiver's configureReproducible
> https://github.com/codehaus-plexus/plexus-archiver/pull/121
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
