This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
It would be good to have a method, which returns the ModuleInfo for a class, so one doesn't have to iterate over all instances, eg. something like: public static ModuleInfo forClass(Class clazz) { ClassLoader cl = clazz.getClassLoader(); if (cl instanceof Util.ModuleProvider) { return ((Util.ModuleProvider) cl).getModule(); } return null; } Make sure this also works for JNLP applications! (see http://www.netbeans.org/issues/show_bug.cgi?id=157798)
Probably not an immediate priority.
Should not have been closed.
*** Bug 188606 has been marked as a duplicate of this bug. ***
Created attachment 100784 [details] Proposed patch
Please review the attached API enhancement.
Y01 Rather than static method, introduce org.openide.modules.ModuleManager class with getDefault() and other useful methods. Background for Y01: One of the most common things is to be notified whether a set of modules changed. This is tricky right now. Having a ModuleManager to add such listener to, would simplify quite a lot of code (ide.ergonomics, maven, etc.). If you implement Y01, I can add the the listening capability then. Y02 If you have ModuleManager class, you probably don't need OwnershipProvider.
Y01 - you can already call Lookup.getDefault().lookupResult(ModuleInfo.class).addLookupListener(...) What specifically are you looking for? This sounds like a much larger scope than the RFE currently calls for and I am afraid it would block an otherwise useful and simple addition.
Re. lookupResult(ModuleInfo.class).addLookupListener(...): It is not enough. You also need to add listener to each ModuleInfo and listen to PROP_ENABLED. Tedious. I don't want to complicate and block anything. I am not doing that! To rephrase my request. I am just suggesting to move the proposed static method from ModuleInfo to newly created class ModuleManager and make the method non-static.
Created attachment 100839 [details] Revised patch, with org.openide.modules.Modules Addresses Y01. (Prefer not to use "ModuleManager" since that could cause confusion with org.netbeans.ModuleManager.)
OK, thanks. API is fine. Few implementation comments which you may ignore: Y03 Modules implementation is an annonymous inner class. I'd prefer to register it as a real top level class. Y04 As we are likely to add new methods into Modules and we might benefit from making them abstract, would it not be beneficial to enumerate list of allowed subclasses in constructor? E.g. if (!"org.netbeans.core.ModulesImpl".equals(getClass().getName())) throw new ISE(); Y05 Should not the registration of the Modules implementation be done as @ServiceProvider annotation? Y06 Should not the ModuleManager (or anything else in o.n.bootstrap or core.startup) be the class that extends Modules?
Created attachment 100895 [details] Revised patch Addresses Y03/Y06; and since http://bitbucket.org/jglick/qualifiedpublic does not seem able to run on JDK 6, Y04. Y05 is impossible since ModuleManager is not a singleton as far as tests are concerned.
core-main #66adb7792a19
Integrated into 'main-golden', will be available in build *201007210001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/66adb7792a19 User: Jesse Glick <jglick@netbeans.org> Log: Issue #157828: new client method ModuleInfo.forClass avoids linear search.