> On Apr 12, 2022, at 6:56 PM, Thomas <t...@online.de> wrote: > > > On 11.04.2022 00:00, Ralph Goers wrote: >> See below >> >>> On Apr 8, 2022, at 9:23 AM, Peter Verhas<pe...@verhas.com> wrote: >>> >>> Thanks Ralph for the detailed explanation. I appreciate it and now I see >>> the points. >> I’ve removed the parts that I don’t think need any more discussion. >> >>> - How will it be a “plugin" project and not another dependency injection >>> framework? >> This is a great question. I think the main difference is with examples like >> Log4j >> and Apache Flume, and even Apache Maven. All wire components together via >> user provided configuration, not code. Dependency injection could certainly >> be >> part of the plugin framework but that would be for implementors of plugins, >> not the users using them. Users of Maven don’t know that Plexus is used under >> the covers and neither should users of a commons-plugins implementation. >> >>> - What will distinguish it from module systems, like OSGi and what will >>> stop it from becoming another OSGi by the years as new features get added >>> to the library. >> OSGi is complicated. Implementing plugins should not be. Just as I described >> using ServiceLoader to locate plugins, plugins should also be accessible in >> OSGi bundles. Users should be required to do as little as possible to adapt >> the >> plugin system to the environment it is running in*but plugins shouldn’t know >> or care anything about how they are located and loaded.* Plugins are also to >> the >> application or framework that will be using them. They essentially define >> what >> the valid plugin types are and where they can be used. > > This is impossible. The bare minimum, any system or artifact has to do, to be > recognized as a plugin, is advertising itself as one. That would be true, > even if your service locator is crawling through every class of the > classloader it can get hold of to determine, whether it is a candidate to > consider. > > - OSGI does this by parsing the MANIFEST and OSGI-INF > > - Spring uses a combination of XML and crawling annotations and packages > > Every other CDI framework does it similar to these two, most of them heavily > reliying on XML- or property based configuration too. With one notable > exception: the dreaded ServiceLoader mechanism, which fixes this during > compile time in the module-info, if you use JPMS, else mapping it in > META-INF/services with simple plain text files, that require no parsing other > then getting the line breaks right - no reflection / premature loading > required. (Which btw, I think is the slickest solution so far, as it does > make service discovery very cheap for small systems, with few class path > entries. Complication is inevitably the result of large classpaths, that > require plugin arbitration to resolve ambiguities and filtering) > > So no: at the very least, a plugin has to know, by what plugin system it is > going to be loaded. And - a different hyperbole: because of this, apache > commons has started to introduce the attributes required by OSGi into the > MANIFESTs of many of its components, just to bridge the gap, and to aleviate > the need to for OSGi-Users to introduce wrappers. > > For me, this will be all well and fine, as long as none of the current or > future apache commons artefacts will become unusable unless I also put > commons-plugin or some arcane configuration parser into the class path.
I never said a plugin shouldn’t know it is a plugin. Providing the manifest entries required to make a component usable in an OSGi environment doesn’t mean the Plugin has to know it is being used in a an OSGi environment. Likewise, providing a module-info.java doesn’t mean the plugin will be used as part of a module on a module path. Using Log4j as an example once again, its Plugins know that they are a Filter, Appender, Lookup, Layout, or whatever. But they have no knowledge of how they were loaded. They DO know that they are being used by Log4j for a specific purpose and what contract they have to implement for that, but that is exactly what plugins are for. So I guess Log4j is doing the impossible? Ralph
