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
them.

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.

More descriptive summary.

Started in branch module_deps_jan_2002.

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)

Marking as an IFDEF-relevant issue.

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.

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.

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.

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
modules.

E.g.
  - 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
disabled.
  - 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
dependency.

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.

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.

Issue 17776 has been deprecated in favor of issue 18781

Work complete in branch incl. tests, pending merge.

Implemented.

http://core.netbeans.org/source/browse/core/Attic/moddeps-todo.txt?rev=1.2&content-type=text/x-cvsweb-markup

functionality verified in 3.4 dev builds