Define modules top-down to avoid constraints?

[Mandy Chung]

Alan,

The refinement looks reasonable.  As you observe, the module config 
files have a common set of exclude rules to prevent a module from 
pulling in classes such as javax.management.*, java.util.logging.*.
>   http://cr.openjdk.java.net/~alanb/jigsaw-tools/webrev.00/ 

Module.java
   The processRootsAndReferences() method now first adds the root 
classes to the module,  follows all references transitively and adds the 
referenced classes to the module if not assigned and then adds content 
classes and their references to the module.  Does that mean that we need 
to keep the exclude rules in the base.config and possibly other *.config?

I was thinking to experiment with the top-down approach but in a 
different sequence that we first assign the content classes to the 
modules.  So all modules have a list of classes to start with.  Then do 
the processRootsAndReferences() one module at a time and the content 
classes and the root classes are used as the root set for transversing 
the references transitively.

Have you experimented this approach?

DependencyConfig.java
  - No change was made.  You can revert to the original copy.

> I find that my list of parameters takes several lines so we might 
> think about allowing multiple modules to be configured in the same file.
In another tool I wrote some time ago, it takes one config file that 
specifies all modules and their properties.  Each property will have the 
module name as the prefix.  For example,
    base.allow = ...
    base.exclude = ...
    base.roots = ....
    client.allow = ...
    client.roots = ....

If there are many fine-grained modules, the config file would contain 
lots of lines that make it not easy to browse.   One config file for 
each module also gives us the flexibility to play with the ordering in 
the command line instead of modifying the global config file.

Perhaps we can consider having a config file to import the 
module-specific config file. e.g.
    base.import = base.config
    client.import = client.config

The import property takes a pathname of a config file.  What do you think?

Mandy