-
Notifications
You must be signed in to change notification settings - Fork 317
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
New plugin API #9002
New plugin API #9002
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #9002 +/- ##
=========================================
Coverage 68.02% 68.02%
Complexity 1158 1158
=========================================
Files 241 241
Lines 7691 7691
Branches 867 867
=========================================
Hits 5232 5232
Misses 2103 2103
Partials 356 356
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
7ccaa75
to
aced2fd
Compare
BTW, one thing that came to my mind: If writing plugins now requires a Gradle plugin, we'd also need to publish that plugin in order to allow third party authors to create ORT plugins. |
aced2fd
to
33d52b2
Compare
It only requires the KSP plugin, no custom plugin. Also, the boilerplate code could still be written by hand. |
33d52b2
to
ce7206a
Compare
ce7206a
to
6be1869
Compare
6be1869
to
14b7b43
Compare
4382861
to
bbb8dec
Compare
* Create a service instance for communicating with the given [server], optionally using a pre-built OkHttp | ||
* [client]. | ||
*/ | ||
fun create(server: Server, client: OkHttpClient? = null): OsvService = create(server.url, client) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, does this removal make the following implementations easier? Because if not, I'd prefer to keep it, and later on refactor it differently, to have functions with the following signatures (and do the same for ClearlyDefinedService
):
fun create(server: Server = Server.PRODUCTION, client: OkHttpClient? = null): OsvService
fun create(url: String, client: OkHttpClient? = null): OsvService
Because to me it makes more sense to use the URL constructor only in cases where you want a non-default URL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it's not used anywhere and I don't think the OSV advisor which is the only consumer of the library would ever use it. However, the important part is happening in the next commit and moving the URL value to a constant could happen without removing the enum. It just appeared to me that removing unused code along the way would be a good idea.
1deef45
to
1009025
Compare
1009025
to
1d16944
Compare
I believe in |
Signed-off-by: Martin Nonnenmacher <[email protected]>
Convert `Server.PRODUCTION` to a compile constant and remove the unused `STAGING` constant to simplify code. Signed-off-by: Martin Nonnenmacher <[email protected]>
Add a new plugin API with the following features: * Plugins have a `PluginDescriptor` which holds the metadata of the plugin. Besides the name this also holds a list of the supported plugin configuration options and their types. This can be used by the CLI and other tools like the ORT server to show the supported options to the user. * Boilerplate code like the plugin factory implementation which includes creating the configuration object from the plain options and secrets maps can be generated by a Kotlin symbol processor. To mark plugin classes for the symbol processor, the new `@OrtPlugin` annotation is introduced. * Plugin configuration classes must use only properties with `String`, `Int`, `Long`, `Boolean`, `Secret`, or `List<String>` type. To simplify the migration, the new Plugin API is created completely separate from the old API in a new `:plugins:api` module. Signed-off-by: Martin Nonnenmacher <[email protected]>
Migrate the Advisor API and all plugins to the new plugin API. This allows to simplify the code in several places, as the plugin factories and service loader classes do not have to be created by hand anymore. Signed-off-by: Martin Nonnenmacher <[email protected]>
Introduce an intermediary `PluginSpec` model that is used as input for the code generation and move the code to create a `PluginSpec` to the new class `PluginSpecFactory`. This provides a better separation of concerns and makes it easier to generate other output files based on the `PluginSpec`. Signed-off-by: Martin Nonnenmacher <[email protected]>
Generate a JSON representation of the plugin spec which can be used as input for other tools, for example, to generate documentation. Signed-off-by: Martin Nonnenmacher <[email protected]>
Move the KSP compiler to a separate project to better separate the plugin API from the compiler plugin. Signed-off-by: Martin Nonnenmacher <[email protected]>
Rename `ort-plugins-conventions` to `ort-plugin-parent-conventions` to make it clearer that it is used for parent projects of plugin projects. This avoids confusion when a new convention for plugin projects is introduced in the next commit. Signed-off-by: Martin Nonnenmacher <[email protected]>
Introduce the new `ort-plugin-conventions` plugin to simplify the configuration of plugin projects. Signed-off-by: Martin Nonnenmacher <[email protected]>
Signed-off-by: Martin Nonnenmacher <[email protected]>
Make clear that the config argument is optional. Signed-off-by: Martin Nonnenmacher <[email protected]>
1d16944
to
7455d2e
Compare
If this gets approved and tests pass I would merge it right after tomorrow's release. Then we can do more testing and adjustments, and maybe also migrate other plugins before the release next week. |
A new plugin API that has a model for plugin options and uses Kotlin symbol processing to reduce the amount of handwritten boilerplate code. See the commit messages and especially the new
plugins/api/README.md
file for details.