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.
