When I was working on the previous iteration of the DI API, I had a BeanProcessor which generated different metadata for different annotation scenarios. It wasn’t too complex compared to the existing annotation processor, though I ended up sticking with the existing processor for now since that detail can be more flexibly changed over time. Perhaps the PluginService API should at least abstract PluginEntry to an interface for different plugin indexing scenarios. That could make it easier to index additional metadata for different plugin types that we already have like pattern converter keys. — Matt Sicker
> On May 30, 2022, at 15:41, Volkan Yazıcı <[email protected]> wrote: > > On Mon, May 30, 2022 at 6:52 PM Ralph Goers <[email protected]> > wrote: > >>> On May 30, 2022, at 2:01 AM, Volkan Yazıcı <[email protected]> wrote: >>> Following up on the responses, I will ask another question: In 3.x, can't >>> we deprecate either key or name and stick to only one? >> >> Why? What problem does this solve? >> >>> For instance, I am >>> in favor of keeping only `name`, adding a compile-time check to validate >>> its content, and cloning it in a `key` field (marked as to-be-removed in >>> future) for backward compatibility. The bottom line is, I think if we >> _can_ >>> live with one, we should. >> >> This is a typical Plugin definition. >> >> @Plugin(name = "Failover", category = Core.CATEGORY_NAME, elementType = >> Appender.ELEMENT_TYPE, printObject = true) >> >> So you want to remove the elementType? Note that “name” is used as the >> key to store the plugin into its Category Map. The elementType is usually >> what is in the “name" attribute but some Plugins, such as Route, don’t >> have an elementType. In those cases the name attribute of the entry is set >> to the plugin’s name attribute. PluginRegistry creates a PluginType which >> includes the name attribute. This is used all over the place for various >> reasons. >> So I don’t see how either key or name can be removed since they are used >> for completely different purposes. >> > > I did not propose anywhere to make a change on or remove `elementType`, I > think we have a misunderstanding. My point is simple, `key` can be used > anywhere `name` is used right now. Am I mistaken with this assessment? Is > there any usage of `name` where if it is replaced by the contents of `key` > the functionality gets broken? > > >>> Yes, but it completes an important refactoring Matt has been tackling: >>> plugin simplification. The frontend (user-facing) part of this story is >>> implemented; `@Configurable` and `@Plugin` are two separate concerns. >>> Though the backend is still the same: the entire `@Plugin` metadata model >>> contains properties of `@Configurable`. >> >> Maybe so, but Matt didn’t actually remove anything. IMO breaking up >> PluginEntry >> wouldn’t solve anything and would, in fact, make the code more complicated. >> > > I simply don't understand why we store every plugin as if it is something > to be read from a file-based configuration. If that is so, let's revert > Matt's changes and make sure every plugin must be configurable. If not, > let's reflect that in the code. `PluginEntry` shouldn't care about the > concerns of configurations. It is the configuration logic that needs to > figure out whether a particular `PluginEntry` implements > `ConfigurablePluginEntry` interface or not and acts accordingly.
