Skip to content

Conversation

tjni
Copy link
Contributor

@tjni tjni commented Sep 11, 2018

Instead of caching by the executable, cache by the Java version so that the task remains cacheable if the path to the executable changes.

Resolves #6694.

Signed-off-by: Theodore Ni [email protected]

I attempted to write a test for this but could not figure out a way to emulate a changing Java path that returns the same Java version. I did not find a similar test for the Java compile or test tasks that could be used as a template.

Contributor Checklist

  • Review Contribution Guidelines
  • Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
  • Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
  • Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
  • Provide unit tests (under <subproject>/src/test) to verify logic
  • Update User Guide, DSL Reference, and Javadoc for public-facing changes
  • Ensure that tests pass locally: ./gradlew <changed-subproject>:check

Gradle Core Team Checklist

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation
  • Recognize contributor in release notes

@tjni
Copy link
Contributor Author

tjni commented Sep 17, 2018

Hi everyone! Would it be possible to get an update? If this change looks good, I'd love for it to be in a nightly version soon so I can pull it into my company's build. If there are other things to consider, I can either help resolve them or can look for temporary workarounds in my build in the meantime. Thank you!

@tjni
Copy link
Contributor Author

tjni commented Nov 14, 2018

Whoops, I forgot about this as I switched teams at my company, but a former teammate reminded me about our need for this so wanted to check back in for an update. Is this something we can merge in the current form?

@wolfs
Copy link
Member

wolfs commented Nov 14, 2018

@tjni Thank you for the PR. No, we cannot merge it in the current form since test coverage is missing. There should be a test which checks that the task is out of date when the Java version changes.

@tjni
Copy link
Contributor Author

tjni commented Nov 30, 2018

Thanks for the pointers on Slack, @wolfs. I updated the PR with a few integration tests. Let me know if any changes are needed.

I took the opportunity to update the test that requires two different JDK 7 installations to look for two different JDK 8 installations and verified that they pass on my own machine. I'll need help to configure the CI build machines to satisfy that precondition if they do not already.

Instead of caching by the executable, cache by the Java version so that
the task remains cacheable if the path to the executable changes.

Signed-off-by: Theodore Ni <[email protected]>
@devishree90
Copy link
Contributor

Hi @wolfs , Is this PR available in nightly build yet? I would love to pull this into our company's build and test it out.

@big-guy big-guy added this to the 5.2 RC1 milestone Dec 12, 2018
@devishree90
Copy link
Contributor

@big-guy - Is this PR available in nightly build?

@big-guy big-guy merged commit 4ff6903 into gradle:master Jan 16, 2019
@big-guy
Copy link
Member

big-guy commented Jan 16, 2019

@tjni @devishree90 this will be in 5.2. You should be able to see this in a nightly tomorrow

@devishree90
Copy link
Contributor

Thank you @big-guy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Should JavaExec task track the Java version?

7 participants