Generate html files at build time (keeps HTML) #457
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Same as #453 but this one keeps the html files (and doesn't delete them in the
clean
task) although I don't really see why they should be kept since:However, in both cases, this requires the servlet to have write permission on their folder.
I can suppose this can be useful for jigsaw, and maybe as deployed war (on tomcat/jetty...), but this reveals bug #451
Checking whether regeneration is required using the timestamp doesn't really make sense in a git repo as the timestamps of the commit are not kept&restored from the commit date IIRC. But on a deployed app using the timestamp makes sense.
Also, eg. on tag cssval-20250226, the generated files were not in line with the template. Maintaining template & generated files synchronized is extra work while having them generated ensures that they match the template.
IMHO, the benefit of keeping the HTML files would be that one can see how a change in the template impacts the generated HTML.
You may merge this PR or the previous one #453 , as you prefer, but I think it may be better to remove the generated html and keep them generated at build time + 1st load in the case the deployed app doesn't ship them. That's not much extra work and actually permits to ensure that the generation works before deployment, instead of discovering after deployment that there is a generation issue.