I see no reason for this restriction other than consistency. And that is a weak reason. All other aspects - usability, co-location to @DataObject.Registration, no need for @Registrations, @NamespaceRegistrations and @ExtensionRegistrations - speak in favor of flexible target.

Btw. is not it a bit too late for a TCR? That might have come as a result of comment #12. What I am supposed to do with a TCR I don't agree with now? Call a meeting, revert all the code!?

Moreover I am not going to go through all the NetBeans sources and rewrite them again to place the annotations to package-info.java. I'd be willing to do it after comment #10, but not later.

(In reply to comment #1)
> no reason for this restriction other than consistency. And that is a weak
> reason.

I think consistency is a rather strong reason. The other reason, and the reason all other annotations which are not bound to a Java object (e.g. @OptionsPanelController.ContainerRegistration) specify @Target(PACKAGE), is that it is misleading to have an annotation on an element which is not actually related to the handling of that annotation.

> is not it a bit too late for a TCR? That might have come as a result of
> comment #12.

Sorry, but reviews are there so changes can be reviewed. There are a lot of API reviews going on at once and there is barely time to read them all before feature freeze.

> What I am supposed to do with a TCR I don't agree with now? Call a
> meeting, revert all the code!?

No need to revert all the code, just fix it; or assign to me to fix it; or find some other opinions; or call a meeting to discuss.

> I am not going to go through all the NetBeans sources and rewrite them
> again to place the annotations to package-info.java.

Then assign to me to do so.

Let's do it like this: bug 191777 is finished. This is new review, you are proposing a change, I am a reviewer. I vote no. I'll try to find next three reviewers to express a vote.

Need three reviewers...

Related to bug #207219 comment #15 (JG11): registration processors should be written to reject annotations on non-PACKAGE targets when the Element is not being used by the layer entry except perhaps as a source of an arbitrary name. In other words, all registering annotation usages should be classifiable as one of

1. Purely static data, on a package-info.java.

2. An object assignable to an API supertype - on a concrete class with a no-arg ctor, or a static @NonNull no-arg method, or (if supported by XMLFileSystem) a static final @NonNull field.

3. A non-package element meeting processor-specific structural constraints, such as @ProjectServiceProvider, or context-sensitive @ActionRegistration.

where #2 should be favored over #3 in general.

No other opinions gathered, no action on part of assignee before feature freeze, so I guess we are stuck with the inconsistent/confused design.