Define modules top-down to avoid constraints?

[Alan Bateman]

Mandy Chung wrote:
> :
> 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?
Yes, any configuration where we define roots will potentially require 
exclude rules to prevent the dependency analysis following references 
into areas that we don't want. However, I think the number of 
configurations where we'll need to do this is reduced a lot with the 
current proposal. I've no doubt we'll need to refine this a few more times.
>
> 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?
Yes, I tried this approach but it increases the number of dependencies. 
For example in sun.nio.cs we want the mandatory charsets and their 
dependencies to be in base rather than in the "charsets" module.
>
>
> DependencyConfig.java
>  - No change was made.  You can revert to the original copy.
It's just the normalization script catching trailing blanks.

>
>> 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?
Alternatively, using the "module" to switch context, eg:

######
module = jndi
contents = \
    javax.naming.* \
    com.sun.naming.* \
    com.sun.jndi.toolkit.ctx.* \
    com.sun.jndi.toolkit.dir.* \
    com.sun.jndi.toolkit.url.*
exclude = javax.naming.ldap.*

########
module = jndi-ldap
contents = \
    javax.naming.ldap.* \
    com.sun.jndi.ldap.* \
    com.sun.jndi.url.ldap.* \
    com.sun.jndi.url.ldaps.*

I don't have a strong opinion except that this alternative forces all 
configuration for a module to be in one place.

So are you okay if I push these changes and the module config files?

-Alan.