-
Notifications
You must be signed in to change notification settings - Fork 41
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
Strip build dependent comments in Play compilers generated files #183
Strip build dependent comments in Play compilers generated files #183
Conversation
7036a02
to
0a0728a
Compare
0a0728a
to
0b4e761
Compare
@@ -121,7 +124,7 @@ GET /newroute ${controllers()}.Application.index() | |||
|
|||
and: | |||
assertContentsHaveChangedSince(scalaRoutesFileSnapshot, getScalaRoutesFile()) | |||
assertContentsHaveChangedSince(javaRoutesFileSnapshot, getJavaRoutesFile()) | |||
assertModificationTimeHasChangedSince(javaRoutesFileSnapshot, getJavaRoutesFile()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing the @(DATE) with post-processing actually makes the content identical
Based on the reproducer at the bottom of #109 (comment) but running diff ./target/scala-2.13/twirl/main/views/html/ ./build/src/play/twirl/views/html/ I can see that the gradle Play plugin still adds the date and the source is absolute: /*
-- GENERATED --
DATE: 2023-03-30T17:31:29.276683
SOURCE: /tmp/gradle-test/play-scala-seed/app/views/main.scala.html
HASH: 71c20c7304dce5c18dc291baf1465b5039e08938
MATRIX: 987->260|1111->291|1138->292|1218->397|1254->406|1289->414|1315->419|1404->481|1419->487|1482->528|1570->589|1585->595|1646->634|1709->759|1746->769|1774->776|1809->784|1850->798|1865->804|1926->844
LINES: 26->7|31->8|32->9|35->12|36->13|36->13|36->13|37->14|37->14|37->14|38->15|38->15|38->15|42->20|43->21|43->21|45->23|45->23|45->23|45->23
-- GENERATED --
*/ Using sbt the date is removed and the path is relative: /*
-- GENERATED --
SOURCE: app/views/main.scala.html
HASH: 52352176f1a784d96e62964e439264b508b87d6f
MATRIX: 987->260|1111->291|1138->292|1218->397|1254->406|1289->414|1315->419|1404->481|1419->487|1482->528|1570->589|1585->595|1646->634|1709->759|1746->769|1774->776|1809->784|1850->798|1865->804|1926->844
LINES: 26->7|31->8|32->9|35->12|36->13|36->13|36->13|37->14|37->14|37->14|38->15|38->15|38->15|42->20|43->21|43->21|45->23|45->23|45->23|45->23
-- GENERATED --
*/ So yeah I guess you have to apply the same post processing to twirl templates like you do for the routes files. |
Hmm. I was wondering why the playframework/src/main/java/org/gradle/playframework/tools/internal/twirl/TwirlCompilerFactory.java Line 25 in 2fff17d
You should upgrade to 1.5.1, I am pretty sure at least the DATE is gone, and then we could see if that also fixes the path problem. |
Alright, the impact is different in that case as an HTML file wouldn't be used as an input of a compilation task. Is it a realistic use case to have the |
The twirl compiler is producing scala files. It works more or less the same like the routescompiler. The routescompiler generates mulitiple scala and java files from a You should upgrade to twirl 1.5.1, independent of this problem btw. |
The above snippets are not from html files but from scala files. |
That makes sense, I'll update the PR ASAP then. Thanks @mkurz 👍 |
@@ -22,7 +22,7 @@ public static VersionedTwirlCompilerAdapter createAdapter(PlayPlatform playPlatf | |||
return new TwirlCompilerAdapterV13X("1.3.13", scalaCompatibilityVersion, playTwirlAdapter); | |||
case PLAY_2_7_X: | |||
default: | |||
return new TwirlCompilerAdapterV13X("1.4.2", scalaCompatibilityVersion, playTwirlAdapter); | |||
return new TwirlCompilerAdapterV13X("1.5.1", scalaCompatibilityVersion, playTwirlAdapter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that there is no breaking change to address
playframework/twirl@1.5.1...1.4.2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there were breaking changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just some nits, but looks great!
@@ -259,4 +262,18 @@ $ROUTES_COMPILE_TASK_NAME { | |||
new File(destinationDir, getReverseRoutesFileName('', '')).text.contains("extra.package") | |||
new File(destinationDir, getScalaRoutesFileName('', '')).text.contains("extra.package") | |||
} | |||
|
|||
def "post-process generated comments"() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
def "post-process generated comments"() { | |
def "post-processed generated comments contain path and timestamp replacements"() { |
String sourceReplacementString = getSourceReplacementString(spec.getSources(), spec.getProjectDir()); | ||
|
||
try (Stream<Path> stream = Files.find(spec.getDestinationDir().toPath(), Integer.MAX_VALUE, (filePath, fileAttr) -> fileAttr.isRegularFile())) { | ||
stream.forEach(routeFile -> process(routeFile, sourceReplacementString)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the process
function already catches the IOException
. what else can throw it in this block?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Files.find
does
import java.nio.file.Path; | ||
import java.util.stream.Stream; | ||
|
||
class DefaultRoutesPostProcessor implements Serializable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a javadoc to clarify what exactly this class does and what it is processing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this
@@ -105,7 +107,7 @@ public ConfigurableFileCollection getRoutesCompilerClasspath() { | |||
@TaskAction | |||
@SuppressWarnings("Convert2Lambda") | |||
void compile() { | |||
RoutesCompileSpec spec = new DefaultRoutesCompileSpec(getSource().getFiles(), getOutputDirectory().get().getAsFile(), isJavaProject(), getNamespaceReverseRouter().get(), getGenerateReverseRoutes().get(), getInjectedRoutesGenerator().get(), getAdditionalImports().get()); | |||
RoutesCompileSpec spec = new DefaultRoutesCompileSpec(getSource().getFiles(), getOutputDirectory().get().getAsFile(), isJavaProject(), getNamespaceReverseRouter().get(), getGenerateReverseRoutes().get(), getInjectedRoutesGenerator().get(), getAdditionalImports().get(), getProjectDir()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's OK to either call getProject().getProjectDir()
here or instead inject ProjectLayout
and use that here.
* @return The project directory. | ||
*/ | ||
@Internal | ||
public File getProjectDir() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of exposing a new property here, I would either call getProject().getProjectDir()
above or change this to:
@Inject
protected abstract ProjectLayout getProjectLayout()
And use project layout above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I directly called getProject().getProjectDir()
👍
// /* | ||
// -- GENERATED -- | ||
// DATE: Mon Apr 03 10:27:51 CEST 2023 | ||
// SOURCE: /private/var/folders/79/xmc9yr493y75ptry2_nrx3r00000gn/T/junit4995996226044083355/app/views/test.scala.html |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this look like on Windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, let me check this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only usage I'm aware of is this one, which is still safe to use after the PR.
private void process(Path generatedFile, String sourceReplacementString) { | ||
try { | ||
String content = new String(Files.readAllBytes(generatedFile), StandardCharsets.UTF_8); | ||
String regexSource = String.format(PATTERN_MATCHER, "SOURCE"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of using a regex here, would it be simpler to do something like:
For each line...
- Look for GENERATED_TAG, we're in a generated section.
- If we're in a generated section, does the line start with DATE or SOURCE?
- If DATE, throw away the line.
- If SOURCE, throw away the line and replace it with a new line
- else, keep the line
- Look for the GENERATED_TAG again, keep all lines after this once we see it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I adjusted the implementation in that sense 👍
// This post processor fixes build / project dependent comments (DATE and SOURCE) from the RoutesCompiler generated files: | ||
// @GENERATOR:play-routes-compiler | ||
// @(DATE): Mon Apr 03 10:27:51 CEST 2023 | ||
// @(SOURCE):/private/var/folders/79/xmc9yr493y75ptry2_nrx3r00000gn/T/junit4995996226044083355/conf/routes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: multi-line comments usually use the /**
syntax.
Is 16-18 an example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I adjusted the Javadoc comments 👍
fixes #109
The generated files by the Route and Twirl compilers contain an absolute path (and a timestamp with older
playframework
versions) which leads to build cache misses.The relativization in the framework assumes that the current working directory is the project directory which is not the case when using the Worker API (
$HOME/.gradle/workers
).This PR removes the
DATE
comment and relativize the absolute path afterSOURCE
comment by post-processing the generated files.