Skip to content

Refactor to use FileTime API #199

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 15, 2022

Conversation

jorsol
Copy link
Contributor

@jorsol jorsol commented Feb 9, 2022

Closes #198

This still preserves backward compatibility with Java 7.

@jorsol jorsol requested a review from michael-o February 12, 2022 11:09
@michael-o
Copy link
Member

What about tests? Are they implicitly tested?

@jorsol
Copy link
Contributor Author

jorsol commented Feb 13, 2022

What about tests? Are they implicitly tested?

Ok, I thought that it was implicitly tested, but it looks that is not, I will add some tests for this and make sure that everything works correctly. Thanks for your input.

@jorsol jorsol force-pushed the 198-filetime-api branch 2 times, most recently from 65d60a4 to 1b89f96 Compare February 14, 2022 16:33
@jorsol
Copy link
Contributor Author

jorsol commented Feb 14, 2022

This should be good to go, I added a test that checks the last modification time of every entry in the zip file in all available Time Zones (although probably with just a couple of them should be enough actually).

@olamy
Copy link
Member

olamy commented Feb 14, 2022

do we really need this noisy bot?

@hboutemy
Copy link
Member

hboutemy commented Feb 15, 2022

what about the @InlineMe suggestion: it seems a good idea to prepare about future removal, isn't it?

@jorsol
Copy link
Contributor Author

jorsol commented Feb 15, 2022

what about the @InlineMe suggestion: it seems a good idea to prepare about future removal, isn't it?

That will require adding com.google.errorprone:error_prone_annotations:2.11.0 dependency, and the use of it it's just as a hint for IDEs, it's probably a good idea, but I don't like to add a dependency for no good reason, so if you like it I will add it.

@olamy
Copy link
Member

olamy commented Feb 15, 2022

what about the @InlineMe suggestion: it seems a good idea to prepare about future removal, isn't it?

That will require adding com.google.errorprone:error_prone_annotations:2.11.0 dependency, and the use of it it's just as a hint for IDEs, it's probably a good idea, but I don't like to add a dependency for no good reason, so if you like it I will add it.

personally I don't think this worth adding a new dependency

@hboutemy
Copy link
Member

sure, not worth an additional dependency: thanks for evaluating

Signed-off-by: Jorge Solórzano <[email protected]>
@jorsol jorsol requested a review from hboutemy February 28, 2022 20:01
@hboutemy hboutemy merged commit a4a6b07 into codehaus-plexus:master Mar 15, 2022
@jorsol jorsol deleted the 198-filetime-api branch March 15, 2022 09:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor to use FileTime API
5 participants