[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)