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
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.
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
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
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:
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.
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
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,
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.