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.
Just move it into netbeans/modules/autoload rather than netbeans/modules, update any build scripts referencing it, and you are done.
The org-netbeans-modules-registry-1-*.jar is autoload now. But what about org-netbeans-core-registry-1-*.jar? Should it be eager module or what? Nobody depends explicitly on this one and so it cannot be autoload.
Btw. Tim is using Registry API in new property sheets which are part of the openide.jar. Is there any potential problem? That lib/openide.jar depends on modules/.../registry.jar?
I definitely don't recommend using the Registry API from propsheet code, which is supposed to be more or less independent of other things! Tim please consider using the JDK 1.4 Preferences API, and David maybe we could make a bridge from Prefs to Registry (but this does not need to happen immediately as the default Prefs storage will work OK for now). IMHO anything in platform which could be used as a standalone library should be using only the Preferences API, for maximum independence.
Hrm... Well, the use case is pretty trivial - persisting a list of strings for names of expando-sets the user has closed, and possibly a preferred sort order. I definitely want to kill the (incomprehensibly public - perhaps because propsheet was originally intended to be used as a bean?) PropertySheetSettings class rather than add to it. I can do the Class.forName shuffle to try to read the settings, and if that's not possible, just punt - the closed sets will persist for the session, which is good enough, IMO. I presume it's okay to depend on Lookup, since I'm already depending on org.openide.util code?
Re. PropertySheetSettings being public - that was intentional, so that the Options window could provide a GUI for them. Re. using Class.forName and reflection etc. - I don't see the point. Seems simpler and better to use the Preferences API; then it would also really work when used as a standalone lib.
I tried to make core/registry eager, but now the openide/registry is always loaded because c/r has dependency on o/r. Is that OK? Eager module depending on autoload module should not cause loading of autoload module. Only dependency from regular module should load autoload module. Btw. the only documentation about eager module I found was in upgrade guide. There is nothing in Module package JavaDoc. As for the Prefs bridge: I filed issue 34114.
No, core/registry should not be eager, it should be autoload too, and provide some token that users of openide/registry should require. Cf. e.g. openide/execution vs. core/execution.
My gut feeling is that the registry is something anybody using the platform will want; wouldn't it make more sense in lib/ than as a module? Also, re the propsheet usage, will the preferences API allow me to differentiate between different applications built on NetBeans running on the same machine?
"will the preferences API allow me to differentiate between different applications built on NetBeans running on the same machine?" - there should not be any problem with this. Both applications will run in its own JVM, both will have its own PreferencesFactory and it will bridge to Registry API which will be based on the SystemFS which is again different in diff apps. The default PreferencesFactory impl is (on Windows) based on the the Windows Registry what means that both your apps would share the same registry ("...Specifically, system preferences are stored under HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs and user preferences are stored under HKEY_CURRENT_USER\Software\JavaSoft\Prefs..."). You should rather prefix the context with the app name?
IMHO the prop sheet should not need to know what app it is in. It is just a GUI component. When you customize some display aspects of Gnome components, e.g., you just customize them - it is not done on a per-app basis. My recommendation is to just use the Prefs API in the simplest possible way and not worry about unless and until there is a concrete reason to do otherwise.
Created attachment 10602 [details] build script patch
Jesse, it does not work. Attached is diff with patched build scripts. I tested it following way: I pasted openide-looks.jar into modules folder. Looks depends on the registry. The result is following problems: - looks modules says "The module Registry would also need to be installed." - openide/registry says "None of the modules providing the capability org.netbeans.modules.registry.RootContextFactory could be installed." - core/regsitry says "The module Registry would also need to be installed." It is probably caused by the fact that core/registry has implementation dependency on openide/registry? Looks like a problem in module system. Btw. the "problems" property of module is of type array of String or something like that and because of that it has pretty strange customizer. Probably knonw issue.
You misunderstood. openide/registry *cannot* require the token, since that would be tantamount to depending on core/registry, which would be cyclic. openide/looks rather has to require the token. Again, compare e.g. openide/execution, core/execution, java.
Aha, I did not know that requiring a token is tantamount to module dependency. I thought about it as a soft dependency, a dependency which will cause loading of autoload module, but nothing more. What's the value of having module dependency on a token-providing-module when I do know its public API? All what I can assume about the token-providing-module is that it registers an implementation of my interfaces in the lookup or in a place I defined. And so it seems to me logic that openide/registry say it requires token "RootContextFactory" because it is interface which is defined in the openide/registry and which must be implemented by some module. If nobody provides the token the openide/registry should not be enabled, because it will not work anyway. What I do not like much on what you suggest to me is: - openide/registry can be enabled even when its implementation module does not exist what can result only into failure. - require token must be specified basically by all modules which has module dependency on openide/registry. (in practice just one module is needed, but which module should it be?)
Sorry about the slow response. "Aha, I did not know that requiring a token is tantamount to module dependency." - yes, more or less, except that (1) you do not know the name of the module you depend on statically, (2) there may be more than one provider in which case you only need one enabled (but the module system will attempt to load them all if it can); (3) no "classpath" implications. "I thought about it as a soft dependency, a dependency which will cause loading of autoload module, but nothing more." - no, it has to additionally enforce that the provider is loaded "first". "What's the value of having module dependency on a token-providing-module when I do know its public API?" - so you can use classes from its API. You cannot statically refer to classes in a module you have only a token dep on, since the dep expresses a dynamic relationship (could be satisfied by any module with that token, without the API classes). "All what I can assume about the token-providing-module is that it registers an implementation of my interfaces in the lookup or in a place I defined. And so it seems to me logic that openide/registry say it requires token "RootContextFactory" because it is interface which is defined in the openide/registry and which must be implemented by some module. If nobody provides the token the openide/registry should not be enabled, because it will not work anyway." - the classes will still be there; but yes the static factory methods will not have an impl. In this case openide/registry is not generally useful without an impl loaded. In other cases (e.g. openide/compiler) it may be fine to refer to the module's classes (e.g. by providing CompilerCookie) without having an impl (e.g. of CompilationEngine) available. It depends. "What I do not like much on what you suggest to me is: - openide/registry can be enabled even when its implementation module does not exist what can result only into failure. - require token must be specified basically by all modules which has module dependency on openide/registry." - right. But there is currently no other mechanism in the module system to handle this kind of case, so sorry. See issue #34699.
-> P3, not critical for PromoD. this module is not included in the standard IDE build
Won't be fixed in a short term because there is a no reason to maintain Registry API now. WONTFIX
David, in case you weren't watching, this issue was recently closed as WONTFIX. You might care about it.
Hello, thanks for the reminder. I don't care about this since in the webstart version we ignore the autoload flag anyway. Maybe all the registry bugs should have been changed to Component: contrib and assigned to me? We use different bug tracking system (in fact several) so I am being bashed from different sources than issuezilla if there is any problem ;-) Thanks and best regards, David