I also don’t think it is a good idea for other reasons: 1. The annotations you are reeferencing a s replacements for the current ones seem to be a stretch. For example it isn’t clear to me why @Qualifier has anything to do with @PluginAttribute. It just seems far more confusing. 2. You would still have to support the existing annotations for compatibility. You will notice that even though there is a new module the annotations used by existing plugins still exist in core. 3. It will make it harder to convert plugins to run in 3.0. Right now the changes are very minor.
Ralph > On Oct 8, 2019, at 1:26 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > IIUC this will require a dependency on a Java EE jar? For that reason alone, > no. > > Ralph > >> On Oct 8, 2019, at 1:23 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> That sounds good Matt, I say go for it. >> >> Gary >> >> On Tue, Oct 8, 2019, 16:08 Matt Sicker <boa...@gmail.com> wrote: >> >>> I've been doing some experiments with the plugin system for 3.x >>> lately, and I've recently pushed some changes toward that end. One of >>> the insights I gained from it was that some of our plugin annotations >>> were redundant (result: @PluginBuilderFactory merged into >>> @PluginFactory; @PluginBuilderAttribute deprecated for merging into >>> @PluginAttribute). After making those changes, I realized that @Plugin >>> and @PluginFactory didn't necessarily need to be separate annotations, >>> though I hadn't written any code to try that out yet. However, I did >>> realize over time that I was essentially reinventing a mini dependency >>> injection framework (hence the historical references to Spring and >>> Java EE concepts in the code or comments). In that regard, I >>> identified that all the current plugin annotations can be categorized >>> as follows: >>> >>> * @Plugin - essentially identifies an injectable class and its name. >>> * @PluginAliases - alternative names for annotated elements >>> * @PluginFactory - marks the injection point for a plugin >>> * @PluginElement, @PluginNode, @PluginConfiguration - all type-based >>> dependency injection corresponding to other plugins (seems to apply >>> regardless of the element name as well) >>> * @PluginAttribute, @PluginValue, etc. - all name-based configuration >>> injection >>> >>> What I'd like to propose is a vast simplification of this system to >>> reuse the javax.inject API [1] since we've already split out >>> log4j-plugins into its own dependency. As you can see, it's a fairly >>> small package, though we could potentially reuse the API without the >>> package names, too. A general conversion of API usage would work like >>> such: >>> >>> * @Plugin name can be replaced by @Named annotation >>> * Aliases can still be specified by a separate annotation >>> * @PluginElement can be a specific @Scope annotation and generally >>> rely on @Inject >>> * @PluginFactory can be replaced by @Inject >>> * Builder<T> can be replaced by Provider<T> >>> * @PluginAttribute can be replaced by @Named @Inject of simple types >>> as well as maybe @Qualifier in general >>> >>> I can work on a PoC for this, though I wanted to see if this idea was >>> acceptable here. I don't want to introduce a full blown dependency >>> injection framework like Guice/Spring/CDI/etc. since all we need is a >>> way to bind configurations to a specific object graph, though the ad >>> hoc nature of plugins in the past has made some things harder to keep >>> a stable API for, and I think this could help improve that situation. >>> >>> By going with the standardized annotations, we might also be able to >>> take advantage of other tooling for generating static representations >>> of a configuration for AOT compilation in microservices or other neat >>> things. >>> >>> [1]: >>> https://docs.oracle.com/javaee/7/api/javax/inject/package-summary.html >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >>> >
