Priority is changed to P4 (normal).

Hopefully will be solved by new ExPropertyEditor for Services.

Automated change of version from Other to Dev.

Version: 'Dev' -> 3.2

#8683 is almost done. ServiceTypeEditor allows setting of super class - that
solves this issue.

*** This issue has been marked as a duplicate of 8683 ***

I don't understand why this is a duplicate. Having better ServiceType editors is
not the point. JavaNode should surely not be creating its Executor property to
permit AppletExecutor (when extending JApplet etc.) but not Install as Module
(Lite)! The executor alone knows whether it is applicable to some data object. I
consider this to still be a valid request--in fact it is becoming more important
as we get flooded with service types (so making P3 for dev version). An average
user trying to switch to Applet Execution would get lost scrolling through
different flavors of RMI deployment.

Target milestone -> 3.3

Reassigned to services.

Target milestone -> 3.3.1.

*** Issue 19331 has been marked as a duplicate of this issue. ***

In my opinion resolved by ServiceTypeEditor. See
http://www.netbeans.org/download/apis/org/openide/explorer/doc-files/api.html#core_editors_custom_parameters

I don't agree it is solved by ServiceTypeEditor, at least it is not
obvious how - the module containing the property has no knowledge of
the specifics of all possible service type values.

Please provide a specific example of how the Java module should ensure
that its list of executors includes only executors applicable to Java
sources. Also suggest how Ian's original request - provide
AppletExecutor only on real applets - should be satisfied. I don't
think it is possible. You could require that all Java-oriented
executors go into Services/Executor/java/ (though this style prevents
a single service from being used in multiple categories), but that
still does not help with AppletExecutor.

Furthermore a service type such an executor normally sanity-checks its
incoming arguments and just throws IOException or something arbitrary
if it is applied to something odd. It would be much more natural for a
programmer of that service type to just remove such code and convert
it into an isApplicableTo(...) method, rather than try to find the
correct folder to place the .settings into etc.; not to mention
convincing the owner of the module supplying the data object to change
the property editor, which involves synchronized changes to that
module and all modules providing services for it.

dev@openide?

Set target milestone to TBD

Set target milestone to TBD

I agree method isApplicableTo could be convenient. 

This enhancement is very old and I have a feeling it does not apply as
much to our current efforts for following reasons:

1. ServiceType is being replaced by Lookup
2. We would like to separate different parts of openide and
implementing this request would probably mean to do add isApplicableTo
(DataObject) method, which would make the separation even harder.
3. This issue could be influenced by the projects design, not sure how.

So I do not know, I suggest not to fix it at all. But if there is
stong will to do it, reopen it...

Re. #1 - that does not really matter, even if you don't subclass
ServiceType the same considerations still apply - you have a pool of
services and you want to find which ones are relevant. What *would*
partially obviate the need for this change is if services were found
using JNDI, or using folder-constrained service type editors - for
example, if a JavaDataObject when looking for an executor searches
only in the context Services/Executor/Java/ then other modules can
influence the choice accordingly. This is still not great though - cf.
my previous example about AppletExecutor, and some services would need
to installed in duplicate in several JNDI areas.

Re. #2 - perhaps. However Executor, CompilerType, and DebuggerType
already have clear dependencies on org.openide.loaders in their public
method signatures, and we can hardly get rid of that without some
nasty bytecode tricks. isApplicableTo could accept Object rather than
DataObject, I suppose, to give us a head start.

Re. #3 - yes, it definitely could. A lot of other stuff probably will
be too, of course, e.g. CompilerSupport.getCompilerType(DataObject).

verified,closed