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.
Continue to load the core from the same startup classloader as now, but in the module classloaders before handing down a request for core classes or resources, check to see if the module has declared an explicit dependency on the core (as a quasi-module) and refuse the classloader delegation otherwise. Something similar could be done for packages used by the core, such as JavaHelp, i.e. require users of these classes to declare a package dependency on them. UI components of the core could be implemented as a separate module depending on the main core, to make it easier to substitute a different UI for the application.
It may in fact be desirable to increase separation further, e.g. by treating help as a module, the execution or compilation engines, etc.
Created branch javahelp_api_jan_2002 to work on splitting off JavaHelp stuff at least. Plan on making a core/help module. Should at least handle parsing and manipulation of JavaHelp help sets and links. Tips of the day should also be housed elsewhere. Probably there ought to be a general UI module core/ui that provides a variety of UI niceties like most of the menus, welcome screen, etc. - anything not related to use as an IDE. This can define an extension area for tips of the day, which could then be physically moved to the usersguide. TBD.
In progress.
Tracking JavaHelp separation in its own issue now.
Provides-requires semantics needed for some of these, probably.
Reassigning to you to help work out exactly what is still not covered by other things, maybe find people to work on them, and file tasks as needed and make this depend on them - like to keep this a purely tracking issue. Candidates we have talked about: - split off a UI module from core, handling general application display stuff, like the welcome screen, setup wizard, maybe import wizard, most menus, most of the Options dialog, Editing workspace, ...; make a fixed module (classpath) but replaceable just using -Dfixedmodules=... at build time - split off an IDE-UI module from core: Build menu, mount wizard, Processes node and maybe whole Runtime tab, Running workspace, CompilerType/DebuggerType/Executor UI, ...; fixed classpath module - split off compilation engine (OpenIDE-Module-Provides: org.openide.compiler.CompilationEngine) incl. Next/Prev Error actions and Stop Compile action; autoload module, automatic dependency from old modules, newer should use -Requires: ... - split off execution engine (OpenIDE-Module-Provides: org.openide.execution.ExecutionEngine) incl. Execution Options; autoload as for compilation engine - split off terminal emulator and output window code; may be feasible to make it an autoload if there were some abstract class InputOutput.Provider handling what the methods in TopManager now do, which could be in lookup and OpenIDE-Module-Provides - not sure if window system can be moved anywhere, that is tough Am I missing anything? Forgot issue #18273, permitting us to move out all the beaninfo.
Hrebejku, can you create the subissues, you are the owner of the platform ;-)
increased prio to P1, must-have for 3.4
I looked into i18n dependency reported as part of #19622 (a class extends beaninfo/editors/StringEditor). Should be editors really in core. Is not beaninfo package a candidate for a module? This issue blocks #19622 (a positive feedback cycle).
There should be no need to directly extend core beaninfos. dstrupl should know more. Making beaninfo into a module may be hard because of the way Introspector finds classes. I think it needs to be in the same classloader as the beans.
Introspector uses (amoung others) also Thread.getContextClassLoader. It seems possible to convince the system to load beaninfos using SystemClassLoader (together with ThreadGroup.enumerate)...
I've thought about contextClassLoader, but it's tricky. systemClassLoader changes dynamically, so you would need to reset the contextClassLoader periodically. ThreadGroup.enumerate will give you all *current* threads but you cannot listen for newly created ones. If it can be made to work reliably, setting contextClassLoader to systemClassLoader would probably be useful for a number of libraries; people sort of expect it to "just work", I think.
BTW see the end of NbInstaller.java for hints on how to (1) auto-add dependencies for older modules; (2) refuse classes on classpath to modules without a suitable dependency. Both things should be helpful for separating classes from core modules. #2 would not be necessary at all for core modules which can be made into autoloads, e.g. execution, where core-execution.jar has OpenIDE-Module-Provides: org.openide.execution.ExecutionEngine and modules wishing to use execution must declare OpenIDE-Module-Requires: org.openide.execution.ExecutionEngine.
Re: contextClassLoader. Each new thread reuses the contextClassLoader from its parent. So it seems necessary to set the system classloader for the main thread, all others will inherit it. Plus reset for all threads in the ThreadGroup when systemCL changes.
Filing separate issue re. contextClassLoader.
Dependencies added
Adding new dependencies
Removing the 3.4_MILESTONE_4 keyword. This issue is a overall core platformization effort issue. It should contain (and it contains) all bugs related to the platformization of core no matter in which release they will be solved. For the 3.4_MILESTONE_4 please see the issue 23399. (Notice: Some of the bugs in the dependency tree are related to more complex changes scheduled into next releases. None of these subbugs has any implact on users of the NetBeans IDE)
What about introduce a new keyword (PLATFORM?) instead of adding all related issues here?
Well, the effort is specifically a task within the core group, and it makes little sense for other modules. Also using IZ dependencies lets us track progress in plans files pretty easily, I guess.
reassigned to Jesse who will be the driver for these efforts
Have been working on it.
I think P1 is overkill for this. I am obviously not going to create the platform out of thin air by tomorrow morning. :-) P2 is fine.
Remaining tasks cannot all be solved in the 4.0 timeframe.
Yarda's been doing the work on this recently. What are your plans? Is this "done"?
I have no special plans except fixing some of the still opened issue this one depends on.
This can probably be closed as FIXED for 5.0 I guess.
I thought about closing it, but the truth is that org-netbeans-core.jar is still pretty big and should be split into smaller pieces. Still there are some tasks this depends on and are not fixed. But if you think this can be closed, do it.
I think the subtasks capture remaining things well enough. Otherwise we could just have this open forever; I'm sure there will always be more things to clean up.