Add a dedicated @CKEditorPlugin annotation

Wow, this is *great*! It seems like the correlation between the directory name and the annotation is arbitrary, right? Of course it makes sense that they would be the same thing (i.e. @CKEditorPlugin lives in lib/Drupal/ckeditor/CKEditorPlugin), I'm just curious if you could make them different (though I don't think that would be recommended).

So yay! Eliminating 2 nested directories. I'd love to see this pattern applied to all modules.

However, I still don't think this reduces the importance of eliminating the "Drupal/[module_name]" nested directories in #1971198: [policy] Drupal and PSR-0/PSR-4 Class Loading. Combined with this approach we could end up with simply glorious module structures like this:

core/modules/[module_name]/lib/[PluginName]/[Plugin].php

With NO redundancy and NO unnecessary nesting. Ah... a man can dream.

Anyway, considering this particular issue. This 100% gets my vote as a conceptual approach to naming plugin directories.

Agreed on all counts. :)

Anyway, still excited to see this pattern applied everywhere in which it makes sense, especially modules that only provide a few plugin types. This situation is even more helpful because it eliminates confusing terminology between "Drupal plugins" and "CKEditor plugins", which are very different things, but implementation-wise are combined together.

This comes at the price of having to define a custom discovery on top of annotationDiscovery...
Do we expect all plugin types to have to ship their own discovery classes ? (and if not, why would it make sense for CKEditor plugins specifically ?)

Also, the .../[owner]/[plugintype]/MyPlugin.php is kind of long when stacked on top of the PSR-0 prefixes, but it guarantees against name clashes between plugin types defined by different systems (e.g. Views might not be the only one that wants to define 'handler' plugins).
It also provides easier human discoverability IMO. When evaluating a contrib module and trying to figure out which plugins it provides for which systems, and figuring those out vs other classes provided by the module (event listeners, plugin managers, straight classes...), having a Plugins directory next to a Listeners directory in at the top of /lib/Drupal/[module] is helpful IMO.

In short: PSR-0 makes excruciating folder paths, but *some* structure below the dumb psr prefix is precious, I'm not sure flattening things there is the right approach ?

I hate the nested folder structure as much as anyone probably, but…

I agree with yched that protecting against name clashes is a must-have.

E.g. for edit.module, it seems this is failing/clashing with ckeditor.module:
I probably misinterpreted that, but people who know/understand this better than I do, please do take a look at that issue.
UPDATE: ignore this example, I indeed misinterpreted this.

Editor name conflict. Maybe the editor modules Editor class can be PropertyEditor instead (based on the class description)?

(See #1987140-6: Add a dedicated @InPlaceEditor plugin annotation.)

Since this screams of bikeshed (and has little to do with CKEditor specifically), let's discuss shortening in a dedicated topic: #1987298: Shorten directory structure and PSR-0 namespacing for plugins.

I don't know if this qualifies as irony, but I personally find it hilarious that the bikeshed issue got in before this was RTBC. :)

A worthy diversion, IMO.

Applied patch and tested manually. Everything still working correctly. Our individual plugins are being found and work like before. Code looks good to my review.

Committed 9b6caf5 and pushed to 8.x. Thanks!

Thanks @alexpott! I'm working on the companions to this one:

#1987140: Add a dedicated @InPlaceEditor plugin annotation
#1992744: Add a dedicated @Editor plugin annotation