Hello, I don’t think plug-ins is something which fits well in the scope of commons, as it does tie into a broader ecosystem/platform normally. but I could be wrong.
Btw: Commons VFS has a plug-in system, mostly for providers. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Ralph Goers <ralph.go...@dslextreme.com> Gesendet: Monday, April 11, 2022 12:00:12 AM An: Commons Developers List <dev@commons.apache.org> Betreff: Re: New component proposal: commons-plugins 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. > - What applications using plugins are the examples for different solutions? > (Log4j is a good example to show that there is a need, you also explained > patiently why it is not a simple ServiceLoader, but it is only one way to > solve it. Other applications may approach the issue differently. Maven, > Attlassian products, other build tools, JUnit 5 and so on.) We’ve already mentioned Log4j. Apache Flume also sort of supports plugins, which I previously mentioned. The main ones are Sinks, Channels, and Sources. In the Flume configuration Sinks provided by Flume can be referenced by their “simple” name because they are manually registered in the code. User provided components have to provide the whole fully qualified class name to be located. In addition, Flume components must locate their own configuration. This limits the format the configuration can take. For example, Flume currently uses properties but I would like to support JSON and YAML Due to the way property support was implemented it is difficult to support either of those without impacting users who have built custom components. This is where using injection does help. The plugins would be insensitive to the configuration format so making changes would just require changing how the configuration binds to the plugin system. > - Based on the gathered knowledge on the previous point, what is the high > level architecture of a plugin system the library will support and what > services will it provide? I think that is TBD. Although we have suggested starting from Log4j’s code, that isn’t a requirement. I would suggest that some experimental code be placed in a project and then whoever is interested can collaborate and debate the pros and cons. That is exactly how Log4j 2 got started. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
