Create production-package.zip earlier in the process #5691
Conversation
…e main classpath for usage in the IDE
| sourceSets { | ||
| main { | ||
| resources { | ||
| srcDir("src/main/generated-resources") |
There was a problem hiding this comment.
callout: Should always avoid writing to the project directory as it can result in triggering tasks to run unnecessarily.
| } | ||
| } | ||
|
|
||
| afterEvaluate { |
There was a problem hiding this comment.
callout: Avoid afterEvaluate
| @@ -8,7 +8,6 @@ | |||
| "removeComments": true | |||
| }, | |||
| "include": [ | |||
| "src/**/*", | |||
| "test/**/*" | |||
| "src/**/*" | |||
There was a problem hiding this comment.
callout: the tsc compiler isn't very smart, so what this was resulting in is the test/** sources being built twice which isn't desirable.
There was a problem hiding this comment.
We'd still need some more refactoring to get rid of this. The problem is that some integration tests fail without this. The tests aren't executed on CI, so I can also fix this afterwards.
There was a problem hiding this comment.
Just a clarification, but as in the Java integration tests?
There was a problem hiding this comment.
Yes. They depend on a JS recipe which is in test. I will try to fix that.
There was a problem hiding this comment.
Alright, so how would you feel about adding an NPM script to compile tests separate from the test and ci:test phases. Then we can wire a dependency from integrationTest to this new task. Thoughts?
There was a problem hiding this comment.
So we can take this thought a step further by using the jvm-test-suite plugin instead of the Nebula IntegTest plugin. With the jvm-test-suite plugin, we would be declaring a dependency upon the production outgoing artifacts which would result in the jar being built and more closely aligning the integration tests with what the real runtime environment would look like.
rewrite-javascript/build.gradle.kts
Outdated
| sourceSets { | ||
| main { | ||
| resources { | ||
| srcDir(createProductionPackage.destinationDirectory) | ||
| } | ||
| } | ||
| } | ||
|
|
||
| tasks.named<Jar>("sourcesJar") { | ||
| from(createProductionPackage) | ||
| exclude("production-package.zip") | ||
| } | ||
|
|
||
| tasks.named<ProcessResources>("processResources") { | ||
| dependsOn(createProductionPackage) | ||
| } |
There was a problem hiding this comment.
callout: All of this is really a hack to make the IDE work correctly. The production-package.zip is a generated resource that would normally be included into the binary jar itself. Unfortunately, since IDEA doesn't generate the jar, but rather uses the raw classes and resources, we're stuck with forcing the production-package.zip to be generated earlier in the process than would typically be necessary, including it as a main resource for IDE support, and then having to filter it out of other tasks for which we don't want the generated binary to be included for.
Overall, not ideal by any means.
There was a problem hiding this comment.
I think we can probably get rid of the hack and just require any IDE tests to specify the path to the dist dir of the project when setting up RPC. I think that is acceptable.
|
I had a couple of integration test failures on Windows, but pushed the changes here as it may be OS specific. |
What's changed?
Create the production-package.zip earlier in the process and make it available on the classpath for usage.
What's your motivation?
Improvements upon 49f19f5.
Anything in particular you'd like reviewers to focus on?
N/A
Anyone you would like to review specifically?
@knutwannheden
Have you considered any alternatives or workarounds?
N/A
Any additional context
N/A
Checklist