At this point, I'd be most willing to start up a repo and codebase for this only if it would be useful for Commons, too. In this scenario, I can begin by porting over the relevant code from log4j to form a starting point for the library (mainly an API, and annotation processor, and default implementation for API), and then we can continue defining out the desired API and implement any alternative backends for the API. From the sounds of it, ideally, the plugins API would have a default dependency-free implementation (the one I'd port from log4j) along with options to swap that out with a more sophisticated DI library like Spring, Guice, Weld, whatever, which would really only be relevant to the application that's defining plugins in the first place. Similarly, the API for obtaining a tree of configuration nodes should be pluggable so that libraries like Configuration can be used as a backend or custom ones based on Jackson for supporting several different structured file formats. While the library can provide some minimal implementations for the configuration and DI aspects, I can appreciate why some apps would prefer to use a different library for that (e.g., to support aspect-oriented programming, interceptors, decorators, etc).
On Mon, Apr 11, 2022 at 6:06 AM Gary Gregory <garydgreg...@gmail.com> wrote: > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
