Decebal Suiu

PF4J 4 roadmap

20

I think that is time to talk about PF4J 4.x roadmap. PF4J is maintained under the [Semantic Versioning](https://semver.org) guidelines, so in a new major version (4.0 in our case) we...

Extract the pluginId and pluginVersion from file name

3

The idea is that now, you are forced to put information about the plugin id and plugin version in `MANIFEST.MF` or `plugin.properties` (see current implementations for `PluginDescriptorFinder`). I think that...

Add support for package export for a plugin

2

The idea is to add a new attribute in `PluginDescriptor`, with the name `Plugin-Export` or other good name, and to use that attribute in `PluginClassLoader`. The plugin class loader will...

Relax the concept of extension point

3

These changes will solve some of the issues discussed in #358. It contains: - relax the type of `Extension#points` field (see https://github.com/pf4j/pf4j/issues/289#issuecomment-556436265) - `ExtensionAnnotationProcessor` checks that an extension implements the...

List all extension points and extensions for a plugin

3

I think that it's nice to have a possibility to list all extension points and extensions that come with a plugin. It's nice to have a kind of plugin's documentation...

Who is using PF4J?

16

I would like to know what applications or who are using PF4J. Thanks!

`PluginDependency`'s versionSupport does not seem to be enforced anywhere? If someone upgrades a plugin but forgets to upgrade one of its dependencies, the upgraded plugin should not start? More information...

Do we need demo_gradle module?

6

I prefer to eliminate `demo_gradle` module, to "merge" this module (build scripts and the kotlin part) with `demo` module. The code in demo_gradle is redundant in my opinion.