Raising priority after discussions in VCS iteam as it blocks smooth transition
between upcoming and current CVS modules.

Behavior is as designed. But A should not be enabled if some of the modules it
depends on are regular (not autoload) modules which are disabled.

A depends on B and on other modules which are all enabled. However, I still
think this is a bug because:
1) B (as an autoload module) should NOT be enabled because no regular/autoload
enabled module depends on it

2) A (as an eager module) should NOT load modules, just check their enableness.
The contract for eager modules as I understand it is: Load eager module if, and
only if, all modules that it depends on are all enabled.

As it is now, there is no way to get rid of visual artefacts from the autoload
module VCS core (module B in this case).

No, eager modules *can* enable autoload modules; sometimes they have to. The
contract is:

1. Turn on all regular enabled modules if possible, enabling autoloads as needed.

2. Then, enable all eager modules which can be enabled only by enabling autoloads.

So changing back to enhancement, since AFAIK the system is behaving as designed
acc. to contract above, which has not changed since the introduction of eager
and autoload modules. May provide some option to make "less eager" modules that
would not enable even autoloads, though I doubt I will have time for it. The
root of the problem is that eager modules can declare dependencies for two
separate reasons: modules they need in order to function (as normal module
dependencies), vs. modules they are of no use without (i.e. the things they are
bridging). Currently there is no way to differentiate these uses; it would
require a partial redesign of the module system to do so.

Generally autoload modules (e.g. vcscore in this case) should avoid producing
visual artifacts; they should be libraries only, and not have XML layers except
to register internal services.

Your solution should probably be to split vcscore into an API/library component
(an autoload) plus a GUI component, which should be a regular module... or an
autoload providing a token which is required by VCS profiles etc. This would
still mean that vcscore and the bridge would be enabled when not otherwise in
use, but at least there would be no obvious impact on the user.

I understand your point that there is no distinction between 'required' and
'trigger' autoload modules. 
I thererefore propose this enhancement:
Add a property to module manifest (e.g. OpenIDE-Module-Trigger) to allow eager
modules to explicitly state modules that turn them on.

Yes, that's probably how I would solve it. Again, though, I don't think I have
time to do it, so please find a workaround if it's only for this one case.

How does this block issue #54150, which seems to be about FS API support for
vcslite? I think that was a mistake?

It's OK. Initialy we though that FS API would be enough. Later on issue #54150
become umbrella issue for additional requests that appeared (see dependecy tree).

Suggested solution: keep javacorebridge eager, and continue to depend on
javacore, but do not depend directly on vcscore. Rather, -Require some token
which is -Provide'd only by particular VCS impls like CVS. Now assuming javacore
is enabled, the bridge (and vcscore) should be enabled if and only if some
concrete VCS impl module is enabled.

I cannot get it to work. How can javacorebridge not directly depend on vcscore
and still use classes from it? If I remove cvscore from
OpenIDE-Module-Module-Dependencies it cannot load classes from vcscore and
cannot be enabled.

OK, if you need classes from vcscore then the provide/require trick cannot be used.

So, I guess you need to refactor your modules better. Split up vcscore into a
pure library and a GUI piece. Make the bridge depend only on the library
portion. Make the GUI piece autoload, and use prov/req to require its existence
from each concrete VCS impl module. Will still cause vcscore-API + bridge to be
enabled unnecessarily, but at least there will be significant visible effect to
the user.

Why can we not just implement new type of module that would be eager but would 
not enable any autoload?  
 
Call it eager-autoload type and you do not need to change the Modules/*.xml. 
Just use: 
 
<param name="autoload">true</param> 
<param name="eager">true</param> 
 
it is compatible, probably simple change and life of people building on top of 
NetBeans will be simplified. It is really needed as this is not the first time 
I hear request like this. Having solution based on eager-autoload would be 
more acceptable then telling people to split modules into parts... 
 

To jtulach:

1. Making something both "eager" and "autoload" sounds quite odd to me in terms
of naming. You want an eager module; you just want to control its behavior more.

2. The proposed module type would not work well, I think. The module may use
some totally unrelated autoload modules as libraries, quite legitimately, and if
it needs to turn them on then it should turn them on. The trigger module
suggestion was closer to what is actually wanted.

So, are there more ideas on how to solve that? I do not believe refacoring
vcscore would be an effective solution, really... 

A crude workaround: in installer for cvslite, call
Repository.default.defaultFileSystem.findResource("Modules/org-netbeans-modules-vcscore-javacorebridge.xml").delete().
That will make a _hidden file in the user dir that will prevent vcscore from
being enabled (if the others are disabled normally). Problems:

1. May not take effect until restart.

2. Not easily reverted by the user - only by deleting the _hidden file.

Currently, we need the following (CVSlite will be in standard build):
1. If user installs (enables) VCSgeneric, disable CVSlite. We do this by
listening on ModuleManager
2. If user enables CVSlite (back), disable all old modules. We check for this in
ModuleInstall.validate()
The user must be allowed to switch between old and new anytime. I am not sure if
your workaround would work in such scenario.

I just tried this: javacorebridge depends on vcscore and provides a token that
vcscore requires. This setup does not work (vcscore complains that no module
provides the token). Is it a bug or a feature? I mean, these modules can both be
enabled or both disabled so I suppose this should work.

OutputStream os = 
Repository.default.defaultFileSystem.findResource("Modules/org-netbeans-modules-vcscore-javacorebridge.xml").getOutputStream(); 
os.write("the content of the XML file when you disable the module by hand"); 
This is fully revertible and should work without any problems. 
 
As for the javacorebridge, maybe it would be easiest to just make vcscore 
depend on java. 

Re. "We do this by listening on ModuleManager" - no! Listen on
Lookup.default.lookup(ModuleInfo.class) please.

Re. "vcscore complains that no module provides the token" - does not work yet;
see issue #34699, and note that this behavior can be simulated using
ModuleAutoDeps. Anyway it is not what you want here.

Re. "the content of the XML file when you disable the module by hand" -
currently you *can't* disable it by hand since it is eager. I guess you mean to
make it a disabled regular module. This is sort of OK but

- will still require a restart to take effect, I think

- can be reverted by the user, though not completely transparently; they would
have to explicitly turn this module back on if they reenabled vcscore

Re. "just make vcscore depend on java" - not a serious option I think. Would
break usage for e.g. native IDEs.

Jarda's trick with xml files works well so I am able to remove dependency on
core. Two issues still remain though:
1) How to get javacorebridge automatically from autoupdate when user gets
vcscore (AFAIK it can be worked around by adding a requires-provides dependency
between vcsgeneric and javacorebridge)
2) How to disable javacorebridge and vcscore (the original issue discussed here)

The proposed solution to #1 would also solve #2, right? Just make javacorebridge
an autoload in that case.

Adding refactoring on cc. I work on new tiny module refactoring/vcs (issue ),
which needs to be enabled when vcscore and refactoring modules are enabled. From
discussion above it looks like this is similar use case to javacorebridge. I
plan to use the same solution for it.

I forget to mention, that refactoring/vcs module is covered by issue 55881.

I checked with RE and they confirmed that 'provides-requires' dependency is
checked and works with AUC. So in javacorebridge/vcscore case the setup will be
like this:
1) vcscore is autoload
2) javacorebridge is autoload, depends on vcscore and java, provides 'jcb-token'
3) vcsgeneric is regular, depends on vcscore, requires 'jcb-token'

If you disable vcsgeneric, both javacorebridge and vcscore should be disabled too.
We need similar setup for refactoring bridge.

Old request; not clear that there is any current usecase for it.