what is the usecase?

the general problem I see is the unknowns. How can you be sure that the service really applies to all project types?

The use case is a ProjectOpenHook which checks for example that the project is broken and shows an alert.

The ProjectOpenHook presents in all project lookups and checks availability of other service (in this case ProjectProblemProvider) in the Lookup. When it's not available it does nothing if its available is shows an alert.

IMHO each project type owner should take a decision about using the problem reporting api or not. Eg. in maven projects we have our own way of badging and showing problems. If you add the new stuff across the board, and some 3rd party plugin will start using it (either across the board or specifically for maven projects) and maven projects still use the old custom way, we get 2 UIs doing about the same thing differently, at the same time..

Having non-project based registrations feels like a more stable (even if limiting) setup, especially for project type owners.

Use case:
A ProjectOpenHook provides generic UI action (like displaying notification) depending on presence of another service in the Lookup. So it should be registered in all project lookups.
Currently there are two possibilities how to achieve it:

1st) Don't register the POH and let clients to do it. Which moves some non trivial task from API writer to API client. The registration requires editing of the layer.xml as the @ProjectServiceProvider cannot be used by the API client as it needs to annotate the service implementation in API provider code - not acceptable.

2nd) Not using the POH and trying to active the same behavior in the API for example by ProjectInconAnnotator which can be registered globally.

(In reply to comment #4)
> Use case:
> A ProjectOpenHook provides generic UI action (like displaying notification)
> depending on presence of another service in the Lookup. So it should be
> registered in all project lookups.

can't it be registered along with the service it's about to watch?

I'm still worried about services being registered for all project types even though it's not applicable to all, giving non applicable ones a CPU penalty.

> Currently there are two possibilities how to achieve it:
> 
> 1st) Don't register the POH and let clients to do it. Which moves some non
> trivial task from API writer to API client. The registration requires editing
> of the layer.xml as the @ProjectServiceProvider cannot be used by the API
> client as it needs to annotate the service implementation in API provider code
> - not acceptable.
> 
> 2nd) Not using the POH and trying to active the same behavior in the API for
> example by ProjectInconAnnotator which can be registered globally.

cannot the client code create a custom POH instance, register it via annotations and have 2 methods called through the API, one for open, one for close. If the API class instance it to be alive through the lifetime of the POH, then opened() would create an instance of API class and closed() would dispose it.

>can't it be registered along with the service it's about to watch?
This is the 1st possibility. Unfortunately it's non trivial.

>cannot the client code create a custom POH instance, register it via
>annotations and have 2 methods called through the API, one for open, one for
>close.
Yes it will work but it forces the API client to do some additional work which can be done by the API itself.
What I am afraid is that some project types forgot to do it other project types forgot something else and the UI will be not uniform.

However I have another idea, solve it by AnnotationProcessor. By default no UI (action, POH) will be included. The UI support will be added into the project by a single Annotation (no need to register every service by hand).
The annotation will look like:

@Retention(RetentionPolicy.SOURCE)
@Target({ElementType.TYPE})
@interface ProjectProblemUI {
      String projectId;
      ResolveAction resolveAction default {...};
      ProjectProblemAlert default {...}

       @Retention(RetentionPolicy.SOURCE)
       @Target({})       
       @interface ResolveAction {
             int position default 8000;
        }
  
        @Retention(RetentionPolicy.SOURCE)
        @Target({})       
        @interface ProjectProblemAlert {
               ProjectProblemsProvider.Severity[] severity default {PPP.Severity.Error}
         }
}

So the API client will just do something like:

@ProjectProblemUI {MyProject.PROJECT_ID}
public class MyProject implements Project {
....
}

and AnnotationProcessor will do the rest for him.

that looks more than good to me.

I will work on it after vacation.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss