Hi Matt, This is quite timely since I've spent the past week researching frameworks to modularize a monolithic application at my day job into separate components/plugins. Everything I've looked at so far is larger and more complicated than I need (e.g. OSGi, Spring, etc) so I was seriously considering writing my own, perhaps based on select components from the Plexus project [1]. I would be interested in this project if it could do the following: - provide a standardized plugin packaging format; - provide standardized configuration mechanisms; - handle plugin discovery and enumeration; - handle service discovery, enumeration, and dependency injection; - handle class loading and resolution of plugin dependencies (e.g. a plugin that depends on a different version of commons-lang than another plugin); and - provide plugin lifecycle methods.
It would also be great if the project was compatible with different frameworks. For example, if the dependency injection functionality could be swapped out for Spring if needed. I haven't totally completed my research so I'm not sure if there is actually an existing framework out there that satisfies the above requirements. If not, I would be willing to help out to get this implemented, regardless of whether it ends up in commons or not. One more thought: I think it would be equally important (if not more so) to define the non-goals of this potential project as the goals. Do you have an idea of what those would be? Regards, Matt J [1] https://codehaus-plexus.github.io/ On Sun, Apr 3, 2022 at 6:24 AM Gary Gregory <garydgreg...@gmail.com> wrote: > > Should this be in Commons Configuration? > > Gary > > On Sat, Apr 2, 2022, 15:33 Matt Sicker <boa...@gmail.com> wrote: > > > Hi all, I’ve got a proposal for a new Commons component that I’d like to > > get feedback on. Essentially, I’d like to propose the creation of a Commons > > Plugins component inspired by the plugin system developed for Log4j 3.x > > [0]. This library would be a lightweight dependency injection and > > configuration library where developers create pluggable classes that can be > > referenced through plugin names via the configuration file (or > > configuration source in general). In contrast with more typical dependency > > injection frameworks like Spring and Guice, this library is for > > applications where pluggable implementations of things is desired. > > Developing a plugin system on top of DI frameworks is not a very > > standardized domain, and each project ends up reinventing this from scratch > > over time. > > > > Some existing material on how the Log4j plugin and configuration system > > works that I’d adapt from to form the basis for this component include: > > - > > https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc > > < > > https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc > > > > > - > > https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc > > < > > https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc > > > > > > > The general goal of this library is to make it so that applications can > > provide better configuration DSLs for their plugin components. As both a > > developer and user, I absolutely despise configuring complex applications > > with properties files, and YAML variants of properties aren’t that much > > better. If there was a common plugin library we could reuse, then perhaps > > more applications would support a better configuration system. This could > > also provide a nice place for tooling integration similar to how JUnit is > > supported by IDEs and other tools. > > > > What do you think? Should this start in the Sandbox? Is anyone interested > > in working on or using this? > > > > [0]: https://github.com/apache/logging-log4j2/tree/master/log4j-plugins < > > https://github.com/apache/logging-log4j2/tree/master/log4j-plugins> > > > > — > > Matt Sicker > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
