Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
launching scalafmt trouble: Could not initialize class scala.meta.package$ #943
OS: macOS Sierra 10.12.4 (16E195)
Based on instructions on http://scalameta.org/scalafmt/
Expected that it'd run and not throw exceptions.
It worked on another machine of mine and there's not much difference from this one.
Running in local user:
Trying to install system-wide
Can you try the following?
This error started appearing yesterday in our CI and on my colleague's laptop. Maybe it's somehow related to the bintray downtime on Tuesday causing cache to go bad. I'm unable to reproduce locally on my machine with a clean cache.
@olafurpg My colleague is in the UK, while everyone else is in NY (no one else is having this issue). He has a theory that maybe some CDN points still have an old, broken dependency. Where is your colleague located (if you don't mind me asking)?
@ScalaWilliamTeralytics may I ask where are you located?
From France / Paris, I'm seeing newer things on Central for
As a workaround, forcing the version of the bumped dependency solves the issue for me:
referenced this issue
May 25, 2017
I may have tracked down the error. Do you have a resolver to sonatype snapshots or repositories @pjrt ? I recall that I forgot to bump up the version in metaconfig to 0.3.3 so I publishSigned it as 0.3.2 first. Once I realized my mistake, I bumped the version number to 0.3.3 and published again. It could be that you are resolving jars from that accidental publishSigned on 0.3.2, which is worrying if true. I thought Maven Central would always go first.
I have re-publishSigned metaconfig 0.3.2. Can you try to wipe your cache and try again.
I guess the answer to that is no: https://ci.appveyor.com/project/olafurpg/scalafmt/build/134
It seems metaconfig-core 0.3.2, which scalafmt 0.7 depends on, got updated on May 23rd. I have no idea how that happened, I thought Maven Central artifacts could not change after publish. Maybe I forgot to close the staging release and that's what we have been using.
I published metaconfig 0.4.0 which should be identical to 0.3.2. I will follow up with a scalafmt v1.0.0-RC1 release that depends on metaconfig 0.4.
added a commit
May 27, 2017
Good question @ScalaWilliamTeralytics
I have updated the metaconfig build to use https://github.com/dwijnand/sbt-dynver. That should prevent me from forgetting to update the version in build.sbt.
The 0.7.0-RC1 release had been working fine for over a month, but it appears it was depending on a non-final/mutable release of metaconfig-core 0.3.2. When I was publishing metaconfig-core 0.3.3 I forgot to bump up the version number in build.sbt so I published it as 0.3.2, overwriting the old release.
I have no idea why sonatype allowed me to overwrite the 0.3.2 release, it's very discerning. I have opened an issue on Sonatype https://issues.sonatype.org/browse/OSSRH-31815