It certainly would be nice if a new common-plugins would be reused within Commons. It seems like it would allow us to provide a nice component outside the validation it would get from Log4j. VFS, Configuration, JCS?
Gary On Sun, Apr 10, 2022, 23:28 Bernd Eckenfels <e...@zusammenkunft.net> wrote: > 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 > >
