-
-
Notifications
You must be signed in to change notification settings - Fork 545
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 type: Thin jar with POM #208
Comments
The idea is good. I think that I will come with proposes. |
The simplest to start with would be to add a new key to MANIFEST: |
@janhoy If you don't started already to write some code, I am ready to try to create a POC. |
Not started, feel free to give it a shot! |
Is this ready ? |
@sashank |
After I played a little bit with this concept, my opinion is that it doesn't put enough value on table. I found few projects that try to use the same concept (more or less): but these projects didn't convince me about utility of this concept. It's relative easy to implement this concept in PF4J but I want to see the advantages before I add this feature. |
It's so easy to get a thin jar that only contains th plugin code, you just only put these two maven plugin into you pom file and then run maven command <plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
<manifestEntries>
<Plugin-Id>${plugin.id}</Plugin-Id>
<Plugin-Version>${plugin.version}</Plugin-Version>
<Plugin-Provider>${plugin.provider}</Plugin-Provider>
<Plugin-Class>${plugin.class}</Plugin-Class>
<Plugin-Dependencies>${plugin.dependencies}</Plugin-Dependencies>
</manifestEntries>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<annotationProcessors>
<annotationProcessor>org.pf4j.processor.ExtensionAnnotationProcessor</annotationProcessor>
</annotationProcessors>
</configuration>
</plugin>
|
I'm aware that delayed download has its problems, and we should not assume that all users of pf4j are able or willing to have their application connect to the internet for downloading dependencies. They may have security policies that prevent that etc. However, pf4j-core could very well support the new plugin format, and simply require that the That leaves the resolving and downloading part to either pf4j-update or some command-line tool folks can run after copying the jar into plugins folder, e.g. The benefits I see with such a new plugin type are
Of course you make valid points that it must be unambiguous what maven repo to use, and downloads must be checksum validated, but I think that's part of the maven-resolver library already. |
I think some implementations of this project can help you.😀 |
@JiaRG |
Having plugins based on Maven artificats is that in a large organizations, it makes easy to manage the plugins in a centralized location. Individual members does not need to download and keep plugins in multiple versions. But when from Maven, just changing the version number fetches the new version. |
I will try to keep thinking about this feature and maybe in the end we will have POC. |
This is an early proposal for a third plugin type. Currently pf4j supports two types: Fat/shade/one-jar and ZIP with lib folder.
The new plugin type would be a thin jar with only plugin code, and a list of dependencies in the form of Maven coordinates (e.g. a
pom.xml
file or a gradle file or simply a list of coordinates). Pf4j would, once plugin type is identified, resolve dependencies from Maven repos and download the jar dependencies to amyplugin-1.0.0.lib
folder next to the plugin itself. A corresponding PluginLoader will then add this lib folder to the class loader.Identification of this plugin type could be through a special name suffix (
*.pf4j
), or some hint in plugin descriptor/manifest. The dependency resolution and download could either happen during installation (pf4j-update) or in run-time at plugin load phase; this should be configurable. For dependency resolution we can use the maven-resolver library.Alternative: If we choose to do this in pf4j-update only, another option could be to download into lib folder and then re-package everything as a
.zip
plugin which would then be installed into plugins root. This would not need any changes in core at all, but a disadvantage is that core project will not understand this plugin type natively.The text was updated successfully, but these errors were encountered: