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.

Bug 17501 - Implement "bridge" modules
Summary: Implement "bridge" modules
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
Depends on:
Blocks: 17773 18781
  Show dependency tree
Reported: 2001-11-10 00:23 UTC by honglin
Modified: 2008-12-23 13:45 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description honglin 2001-11-10 00:23:52 UTC
Disable C, C++ and Fortran Support module, will also disable C, C++ 
and Fortran Editor Support module & Forte Developer C/C++/Fortran
Support module.
But when re-enable it back, the other two modules won't be enabled
Doesn't even give out a reminder message. People may disable the 
first module by mistake, and then enable it back, but they may not
remember to enable the other two. 
It will be good to pop up a reminder message.

Per IFDEF Developer, it is a Netbean bug.
Comment 1 Jesse Glick 2001-11-10 11:48:11 UTC
Makes some sense although the question is open-ended which modules you
should remind the user about. If there are modules the user truly does
not care about, it will be annoying to have constant reminders about

There was a proposal recently on nbdev (Martin Matula, Fri.) to have
some modules be "greedily enabled" (his scenario #1) whenever they can
be. I think there is some merit to it--though I doubt the situation
you describe here fits into it exactly. The editor support bridge
module, definitely; but it ought not be used for any module providing
substantial additional functionality, only for "bridges" which tie
together basic functionality of already enabled modules.

For the "Forte Developer ..." module in your case, it seems dangerous
to have it be automatically reenabled. You can however place it in the
same display category as the base CPP module, making it quite visible
to users that it is available for reenablement.

Will not be changed for NB 3.3, will consider for 3.4.
Comment 2 Jesse Glick 2001-12-18 15:00:08 UTC
More descriptive summary.
Comment 3 Jesse Glick 2002-01-23 08:24:13 UTC
Started in branch module_deps_jan_2002.
Comment 4 Jesse Glick 2002-01-23 19:04:55 UTC
Seems to be working well enough in that branch. Need to clean up the
build system to understand modules/eager/ directory, otherwise looks
OK. Behavior and UI is as follows:

1. If a module is found in the modules/eager/ directory, it is
considered "eager". Compare modules/autoload/. This information is
stored in the module XML file: <param name="eager">true</param>

1a. Modules which used to be normal modules which are now made to be
eager can be upgraded from old user directories in such a way that the
old module information is now marked as being eager.

2. No action, from the GUI or code, may explicitly enable or disable
it, nor is its enablement state persisted. The module system controls
the enablement state internally. Similarly to autoload modules.

3. When some regular modules are turned on, and some eager modules
then can be turned on, they are automatically turned on.

4. Disabling a regular module will disable any eager modules dependent
on it, without prompting the user, i.e. it is quiet.

5. When the Modules node is sorted by category (default), all eager
modules appear in a special subnode "Bridges", immediately before
"Libraries". They have an "Enabled" property but it is read-only.

Should be reasonably straightforward. I plan to make some standard NB
modules eager:

- apisupport+ant

- i18n+form

- *+editor (various syntax coloring helper modules)
Comment 5 Jesse Glick 2002-01-24 12:04:22 UTC
Marking as an IFDEF-relevant issue.
Comment 6 Jesse Glick 2002-01-24 12:26:23 UTC
API impact: none, should be considered core feature not officially
guaranteed by APIs. It is enabled only by placement of the module in a
certain folder and does not require any modifications of the module JAR.
Comment 7 _ lkramolis 2002-01-24 17:26:16 UTC
Jesse, it is great, you implemented this. I have little enhancement. I
think, it is not good to avoid user to disable some module.

I would like to suggest to still have possibility to enable eager
module. Table displays UI of suggested behaviour:

Enabled property ||
of eager module  || Module enabled       | Module disabled
Enabled property || User has chance to   | User has chance to
is read-write    || disable eager module.| enable eager module.
Enabled property || imposible            | Dependencies failed.
is read-only     || state                | (When dependencies will be
                                         | fulfilled, then module
                                         | return to previous state.

I think, if such behaviour implemented, then each module could be
classified as eager module.
Comment 8 Jesse Glick 2002-01-24 20:16:18 UTC
Sorry, I don't think I understand your table.

The reason I decided to omit any GUI for disabling an eager module is
that it rather simplifies things internally. Otherwise you have to
decide how long it is supposed to stay disabled if some other things
change. It can get very complicated. The implemented solution is
relatively simple (= testable). So I don't think what you suggest is a
"little enhancement" at all, it is a quite different system, probably
dealing mostly with UI code in the Modules node rather than with the
module installer itself.

The eager attribute should only be used for modules which provide no
exciting user functionality in and of themselves: they only bridge
together other modules. This way there is no reason why a user would
want the module off. If you have form and i18n enabled, why would you
want to turn off form+i18n? It is an implementation detail that it is
even a separate module at all.

For modules like "XML tree editing" etc. that provide noticeable and
optional functionality on top of e.g. "XML core", these should not be
marked eager. The user should decide whether it is to be turned on or off.
Comment 9 _ lkramolis 2002-01-25 08:20:42 UTC
I tried to say, that 'Enabled' property must not be read-only. And
when this property is not read-only, this could be used for common

  - All modules are on.
  - User will disable XML Core and then XML Tree, XML Text and XML
Tools are also disabled, because of they depend on XML Core.
  - Now, when I enable XML Core, then XML Tree, XML Text and XML Tools
will be automatically enabled, because they was previously disabled by
module, not by user.

  - XML Core and XML Text and enabled; XML Tree and XML Tools are
  - User will disable XML Core and then XML Text is also disabled,
because of it depends on XML Core.
  - Now, when I enable XML Core, then XML Text will be automatically
enabled, because it was previously disabled by module, not by user.
And XML Tree and XML Tools stay disabled, because it was previously
disabled by user.

I think that implementation could not be hard - probably one new
property, which describes who disabled module - user or failed module

When I am thinking about it, my table was not really correct.
Read-only Enabled property is not good thing, because I would not be
able to enabled XML Tools (when XML Core disabled) - so current state
(XML Core is enabled because of XML Tools depend on it) is good.
Comment 10 Jesse Glick 2002-01-25 10:51:31 UTC
What you are asking for is definitely a different thing than bridge
modules. Please open a separate RFE, I will try to implement it, but I
don't have time for it now (in the current branch). I do not suggest
bridge modules be used for the XML modules except for XML Text. It
makes no sense for XML Tree or XML Tools, for example.

Your suggestion makes more sense now; it is a job for a higher UI
layer than the module system per se, more for the Modules node: if
disabling A prompted the user in a dialog to also disable B since B
depends on A, then if later on A is enabled via the module node, the
user will be prompted to also enable B (if B still exists). Nothing of
the sort will happen if the enablement is controlled by other means,
for example session switching, etc.

Of course, an alternate approach is to display just the module
category by default in the Modules node, so that novice users will
just enable/disable "XML" (meaning a cluster of modules), whereas more
advanced users could choose to turn on only the core but not tools.
This convinces me that the approach for what you are describing is
more of a UI concern, and should probably get nbui involved.
Comment 11 Jaroslav Tulach 2002-01-28 09:57:22 UTC
Issue 17776 has been deprecated in favor of issue 18781
Comment 12 Jesse Glick 2002-01-28 12:28:54 UTC
Work complete in branch incl. tests, pending merge.
Comment 14 Jan Zajicek 2002-03-22 10:48:55 UTC
functionality verified in 3.4 dev builds