Add Maven Toolchains Declaration (#276) #282
Conversation
|
I would very much appreciate if @dmitry-shibanov or someone else from the maintainers could chime in here and tell me what I have to do in order to get this merged. Thanks in advance. |
|
@dmitry-shibanov can you help here? That would be very helpful! |
|
@marko-zivic-93 can you maybe review/ merge this? |
|
The failing validation checks were caused by connection timeouts during installation. Not by anything in this PR. |
|
@Okeanos could you point us to a sample workflow run that uses the new functionality? That would help me understand what we're adding here. I saw the YAML snippet you added for the docs, but I'm also curious how the toolchain gets consumed in later steps. |
|
You can take a look here: https://github.com/eclipse-platform/eclipse.platform/blob/master/.github/workflows/build.yml currently we maintain a hand written toolchains.xml and need to pass that to the maven command see: with an automatic one like proposed here, it would be just a matter of calling |
|
@brcrista I setup a minimal project with pipelines that are hopefully self-descriptive here: https://github.com/Okeanos/setup-java-example/actions It appears that Gradle benefits less from this PR on GitHub Actions than anticipated from Gradle#14903 even for e.g. Gradle 7.3 which did not support Maven Toolchains detection. Some jobs, such as the Java 8 and 11 are supposed to fail (technically, even for Gradle but it has auto-detection that works on GitHub Actions and for some reason matrix builds behave different from what I expected) because no valid JDK was found/supposed to be available/configured and the toolchains requirements in the I also found and fixed a bug in my implementation and improved the tests as well. Asking for in-depth examples was a good idea ❤️ . Additionally, I discovered that the If you have any further questions or need better examples (for an arbitrary value of "better") please let me know. |
|
Just got the pipeline notifications … gonna fix the formatting issues etc. Could have sworn I ran that formatting etc. after checking with the readme/contribution guidelines. Sorry about that :( |
|
As an aside and something that was not yet fully addressed I believe in either the PR or the issue: we can make the toolchains generation optional/opt-in and properly document that in the readme. This would ensure there are absolutely no breaking changes for existing users with working solutions and reduce the maintenance/support headache you rightfully pointed out – if they ever get around to upgrading (and reading about the changes in the update) they can still decide to switch. New users will hopefully see the notes and decide for themselves what they like best. Any thoughts? Personally I am fine with either. |
|
There are some CI failures. Running |
Along with review fixes I did some additional changes pertaining to this:
|
|
@Okeanos mayn many thanks this looks really great! |
I've been thinking about this and haven't come to a decision yet ... I'm leaning towards doing it though. Since the intent is to avoid a potential breaking change, we would have to set it to |
Take your time – I am in no rush and just happy this is considered for integration. Waiting another few days and fixing any outstanding issues in the meanwhile is not a problem for me and I'll gladly try to incorporate any changes you would like to have made. |
|
👍 for |
|
Could you please sync with the main branch ? |
As far as I can currently tell the branch builds on top of the current main branch. The GitHub UI also says "This branch is 1 commit ahead of actions:main." the one commit being my commit introducing this feature. If you introduce any new commits to main before this is merged I'll incorporate those changes of course. |
|
@brcrista @dmitry-shibanov I'll be switching to |
Ok, so I consider defaulting I think we can just remove the @dmitry-shibanov are you planning to merge #368 first? It seems like this PR will need some reaction work to add all Java versions to the Maven toolchain file. |
In that case I'll wait for #368 to be merged and make the necessary changes for that alongside removing the |
|
@brcrista @dmitry-shibanov I updated the PR for setup-java to support Toolchains now that #368 (install multiple JDKs at once) has been merged. Based on the previous findings:
Compared to the previous iteration I did some additional changes for better compatibility with exiting setup options:
If there is anything else you would like me to change, let me know and I'll have a look. |
__tests__/toolchains.test.ts
Outdated
| import io = require('@actions/io'); | ||
| import fs = require('fs'); | ||
| import path = require('path'); |
There was a problem hiding this comment.
Could you change this to the import * as ... syntax? That avoids some subtle gotchas
There was a problem hiding this comment.
Doing that will throw "Cannot redefine property" errors because of the spyOSHomedir = jest.spyOn(os, 'homedir') in the test setup. Interestingly it works for core (where we do the same thing).
I am not well versed enough in either TypeScript or Jest to propose a better alternative. Any suggestions?
There was a problem hiding this comment.
I went ahead and fixed this for all except os for now.
There was a problem hiding this comment.
A couple minor comments, but nothing blocking merge. @dmitry-shibanov could you or one of your teammates take a look also?
* Add (optional) Maven Toolchains Declaration after JDK is installed * Extract common/shared Maven constants Resolves #276
|
Thank you @Okeanos ! |
|
Very great, when will it be release? 👍 |
Description:
Related issue:
#276
Check list:
I also used my fork + branch on a private repository's pipeline to verify a valid toolchains declaration is created for the specified JDK and used by a Maven based build job.
Technically, using
${env.JAVA_HOME}inside thetoolchains.xmlfile is possible, however, this will get interesting with #44 very fast. Not to mention that e.g. version and vendor are not exposed as variables anyway.