Handle possible OverlappingFileLockExceptions for cache file #218
Conversation
LukaszKontowski
added
bug
| Before using this compiler plugin, make sure that you are using both [annotations](#annotations) properly. If so — the plugin can be used right away. This plugin checks whether classes marked with serializability trait are being referenced in a marked serializer, which ensures that codecs will be registered in runtime.<br><br> | ||
| Before using this compiler plugin, make sure that you are using both [annotations](#annotations) properly. If so — the plugin can be used right away. This plugin checks whether classes marked with serializability trait are being referenced in a marked serializer, which ensures that codecs will be registered in runtime. | ||
|
|
||
| **Note** - Codec Registration Checker Compiler Plugin is useful only in projects (modules) where the [@Serializer](#Serializer) annotation is used. Therefore, if you are using Akka Serialization Helper in multiple modules but in fact use `@Serializer` annotation in only one module, you might disable this plugin in all other modules except the one where `@Serializer` annotation is used.<br><br> |
There was a problem hiding this comment.
Actually... isn't there an sbt key to disable this compiler plugin? that's easier than passing --disable flag explicitly 🤔
There was a problem hiding this comment.
Yes! We have a very smart function - https://github.com/VirtusLab/akka-serialization-helper/blob/main/sbt-akka-serialization-helper/src/main/scala/org/virtuslab/ash/AkkaSerializationHelperPlugin.scala#L73 - which enables users to write a setting like below:
ashDumpPersistenceSchemaCompilerPlugin / ashCompilerPluginEnable := false
instead of
Compile / scalacOptions += "-P:dump-persistence-schema-plugin:--disable"
In fact, this applies only to --disable and --verbose options (which are available for all 3 compiler plugins). However, there are also a few scalac options that are unique for the serializability checker compiler plugin and we do not have such classy flags for them.
Looks like these sbt flags are more elegant solution - it would be nice to have such flags for all possible scalac options for our compiler plugins. And then change instructions in this GUIDE accordingly. I would create a separate issue and PR for that purpose. What is your opinion?
There was a problem hiding this comment.
Looks like these sbt flags are more elegant solution - it would be nice to have such flags for all possible scalac options for our compiler plugins.
Okay, pls open but as a nice to have feature. As for the flags for which there are already sbt keys... pls update the GUIDE accordingly now (I mean, can be on a separate PR)
There was a problem hiding this comment.
sure, separate PR for this change will come soon today
closes #217
Description added in a comment to the while loop.