Closed freeze-dolphin closed 3 years ago
IntelliJ cannot resolve the overloaded constructor ScalaPlugin, because there is no no-args constructor in the ScalaPlugin class. The super constructor that you're suppoed to use takes a ScalaPluginDescription as a parameter. But I can create an extra overload without any parameters and publish a new version in an ~hour or so.
You're raising valid concerns that setting a version should only be done in one place, so if I really wanted to get away from the plugin.yml I'd have to create a maven plugin (and an sbt plugin, because the majority of the scala community seems to be using sbt) that can do the replacement for you. This would be something for the longer term. I did have plans to improve the plugin loading code anyway in order to better support loading third-party libraries, so this will be another reason to re-implement it.
For sbt there is the sbt-buildinfo plugin that allow to access this info in Scala. And for maven there is the maven-jar-plugin that allow to access them in ressource files.
Two way of doing it. You can keep both constructors to satisfy everyone ^^
For sbt there is the sbt-buildinfo plugin that allow to access this info in Scala. And for maven there is the maven-jar-plugin that allow to access them in ressource files.
Thanks for the suggestions! I will investigate when I find the time.
Edit: That sbt-plugin seems quite good already! No need to do anything about that, but I don't consider the proposed solution for maven to be good enough; Scala source files are not resource files, so I'd need to find (or create) a maven plugin which makes these variables from the pom available to the source code.
ScalaPlugin now has a protected zero-argument constructor: https://github.com/Jannyboy11/ScalaPluginLoader/commit/936789016281316266f008d84f75a94a27c2624e#diff-5dd16ec5651002cc63bae4d06a081a3f89e3e2cdc7de0bd6e8fd8c1239914cf4R72 The Scala3Example plugin now uses this feature.
I won't close this issue yet as there are more details here about how to move forward to a plugin.yml-free future, but I might create a new issue for that.
Closed in favour of https://github.com/Jannyboy11/ScalaPluginLoader/issues/9
Between anno-style description and file description, I may prefer the latter. So I wrote a 'plugin.yml' and put it in the /src/main/resources/ folder.
Codes
Problems
IntelliJ says that 'Cannot resolve overloaded constructor
ScalaPlugin
'What's more
My reason for using 'plugin.yml' is that maven can replace "${project.version}" in it but using anno-style desc cannot.
Changing version tag every updates is really a pain, you know changing the version for a maven project need to modify its pom.xml, so while using anno-style desc, you need to do it both in codes and pom.xml
And usually I would forget to do it!
So if replacing "${project.version}" in scala codes can be possible, then I would surely prefer the anno-style :)