Sounds like https://svn.apache.org/repos/asf/commons/sandbox/ can be a ready to start place even if I still think incubator is the real place for such a project since it will quickly overpass commons standard case with a lot of modules if it gets a community and adopted (for integrations).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 11 avr. 2022 à 20:47, Matt Sicker <boa...@gmail.com> a écrit : > 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 > >
