[
https://issues.apache.org/jira/browse/LUCENE-9868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17309245#comment-17309245
]
Dawid Weiss commented on LUCENE-9868:
-------------------------------------
bq. I think hashing could be extremely difficult to debug, if something goes
wrong. It could be frustrating to not know why the hash changed.
I'm thinking typical stuff we've seen before in the past such as non-idempotent
regeneration because of hashmap ordering and stuff like that.
I think you'd still know what went wrong because the failure would happen on
check (before you commit)? And then you can regenerate and see the diff in
inverse...
This said, the benefit of actually having a job doing the regeneration would be
twofold - to detect accidental changes AND to make sure these tasks are
up-to-date and actually run from time to time (so that URLs don't become stale,
etc.). Remember we already have a task to verify the contents of the local
working tree is "clean"... so that job could just run this command:
{code}
gradlew regenerate -x jflexUAX29URLEmailTokenizerImpl checkWorkingCopyClean
{code}
and this would both regenerate AND verify nothing's been changed. I excluded
the jflex killer task above. This is an exceptional task that may require other
handling.
> Verify checksums on generated files
> -----------------------------------
>
> Key: LUCENE-9868
> URL: https://issues.apache.org/jira/browse/LUCENE-9868
> Project: Lucene - Core
> Issue Type: Sub-task
> Reporter: Dawid Weiss
> Assignee: Dawid Weiss
> Priority: Minor
>
> This would prevent accidental changes to generated resources/ files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
