On Tue, 7 Dec 2021 19:06:17 GMT, John Neffenger wrote:
>> Thanks, CSR now Finalized
>
>> Thanks, CSR now Finalized
>
> Just a minor note: the CSR uses the adjective "extended" in three places for
> the DOS date and time field, but that field is actu
On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger wrote:
>>> I'm testing it now. So far, it's working great!
>>>
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z`
>>> triggers an extended header with the wrong time:
>
On Thu, 2 Dec 2021 15:35:40 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andre
On Wed, 1 Dec 2021 21:50:46 GMT, Andrew Leonard wrote:
> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?
I know, nit picky, right? 😄 I'll take no offense if you ignore it. The thing
is, everyone else implementing this feature gave that specific instant a wide
margin. (S
On Wed, 1 Dec 2021 18:02:05 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andre
On Wed, 1 Dec 2021 18:02:05 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andre
On Tue, 30 Nov 2021 21:56:51 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Tue, 30 Nov 2021 21:56:51 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Tue, 30 Nov 2021 19:37:23 GMT, Andrew Leonard wrote:
> Whichever we use, we have to use e.setTimeLocal(), so can't see what the
> difference is?
Okay, here's a brief command-line example before posting the code example. In
my experience, most people trying to set up a common, project-wide b
On Tue, 30 Nov 2021 18:57:55 GMT, Andrew Leonard wrote:
> I'm also adding --date validation of 1980->2099
I am only now catching up with you on that issue. 😄 I wrote a very short
program that illustrates that problem (and all the other ones) very clearly for
anyone to see. I'll post it shortl
On Tue, 30 Nov 2021 18:52:56 GMT, Andrew Leonard wrote:
> Both basically truncate the timezone.
There's a difference. The first option saves a DOS date and time that depends
on the time zone of the build machine due to the ISO 8601 string returned by
default from the `git` and `date` commands,
On Tue, 30 Nov 2021 12:00:59 GMT, Andrew Leonard wrote:
> So what you suggest sounds reasonable, although it would be a "behaviour
> change" in that whereas now if the date is between 1980->2106 only a xdostime
> is stored, we would now always be storing the additional "mtime" field ...
No, so
On Tue, 30 Nov 2021 08:31:54 GMT, John Neffenger wrote:
> Would you be willing to consider a minor change to your implementation?
Just to be clear, this change should let us postpone any additions to the
`ZipEntry` API for another day, if at all, and maybe even get this pull requ
On Mon, 29 Nov 2021 19:27:57 GMT, Andrew Leonard wrote:
>>> @AlanBateman yes, see above comment, thanks
>>
>> This is a significant change to the ZipEntry API that will require
>> discussion and agreement. Can you start a discussion on core-libs-dev about
>> the topic? You could start with a s
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Thu, 25 Nov 2021 10:55:45 GMT, Andrew Leonard wrote:
> Please consider providing a more general option, say `--date`, which takes an
> [ISO 8601 date/time
> string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME).
The `jar`
On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Fri, 19 Nov 2021 16:52:36 GMT, Andrew Leonard wrote:
> Add a new --source-date (epoch milliseconds) option to jar and
> jmod to allow specification of time to use for created/updated jar/jmod
> entries. This then allows the ability to make the content deterministic.
>
> Signed-off-by: Andr
18 matches
Mail list logo
