-
Notifications
You must be signed in to change notification settings - Fork 101
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
Update Scala to 2.12.18 #277
Conversation
@headius we may consider splitting polyglots? We just had 0.5.0 (due "revive" when we changed to Maven 3.9.5 + JSR330 + more) and now due Scala upgrade we'd need 0.6.0 (to follow semantic versioning)... Any ideas? (or Ruby is just fine to get 0.6.0 as next)? |
I updated the PR description. Before a release, I'd like to explore, if we can bump to Scala 2.13. |
+1, go for it (and ping me if we are good for release), and see what @headius have to say, but I think they will be fine with 0.6.0 |
Great. I'll do further changes in another PR. This one is IMHO good to merge. Maybe, we can make a |
I'd merge and just do 0.6.0, am not a fan of "preview/M/alphas" 😄 Let's wait @headius response, but I think he will be fine with 0.6.0 as well. |
@lefou one question re Java8: do you insist on building polyglot with Java8 or having CI run test only? As I just realized we could split the build just like MIMA does:
Like here: Just asking, as "going back" with takari-lifecycle as seen with GPG signing, may bring or cause other issues as well, so I'd really really "move forward" with it, not "backward". This will require some changes, but IMHO is worth the cause... |
I definitively don't insist to build with Java 8! I'm all for moving forward. I just insists in having an functional integration test that covers the Java 8 runtime. We claim to support it, so we should ensure it. As polyglot-scala has a working integration-test setup, which helps to cover essential use cases (and which helped me a lot in updating Scala support btw), it would be a great loss to not run them. In previous discussions, I was under the impression, that testing on Java 8 - while building with a newer Java version - requires some special setup. As I'm not the guy who wanted to implement it, and I can't delegate this work to anybody else, I suggested to keep building with Java 8. If someone is implementing it however, I really appreciate it. |
That means, we will have a |
Use whatever versions you want! Just make sure they go up instead of down! |
This PR updates from Scala 2.12 to 2.13. With the update to Scala 2.13.12, which is the latest available Scala 2.x version, `polyglot-scala` should also support Java 21. I suggest to have this PR and PR #277 (which updates from Scala 2.11 to 2.12) not in the same release, to give users of `polyglot-scala` a chance to migrate their builds step by step. But TBH, I have no clue how many users we still have. Along this update, I bumped various dependencies, migrated some Scala syntax and fixed deprecated or removed API call sites. I also fixed some issues with left-open file resources.
Due to some security vulnerabilities in Scala 2.11 compiler, I switched
polyglot-scala
to Scala 2.12, which is the last version, for which there is a release ofcom.twitter:util-eval
, which we use to compile and evaluate thepom.scala
files.Unfortunately,
util-eval
throws runtime exceptions when used as-is, which is mostly due to internal changes in the Scala compiler. Sinceutil-eval
doesn't work with Scala 2.12 and was even removed upstream for quite some time, I vendored the single fileEval.scala
and applied some small refactorings to make it work. The imported file was licensed under the Apache Licence, version 2, which is identical to this project license.Due to the version bump from Scala 2.11 to 2.12, I'd consider this pull request a breaking change. The next release number for polyglot(-scala) should be therefore
0.6.0
(if we apply early semantic versioning).I think it's worth investigating, whether we can follow up with a bump to Scala 2.13. I haven't tested it yet, due to some dependencies not available. But it looks like
com.googlecode.kiama
has moved to https://github.com/inkytonik/kiama, so there should be no blockers. But theEval
might break again due to expected compiler changes.