Notes from discussion on module definitions and tools

[Alan Bateman]

Mandy and I had a discussion last week on the tools and the other 
changes that we need to do as we prepare for the build to generate 
modules. Here's my notes from that discussion (Mandy, correct me if I've 
got anything wrong).

We agreed that the module definitions need to be simple and easy to 
maintain.

With the current tool, we can allocate classes to modules based by 
matching on package/class names or we can specify roots and have the 
tool attempt to compute the transitive closure (or do combinations of). 
Following dependencies is very useful for analysis purposes but is 
fragile in that it requires hard-to-maintain filters to prevent the tool 
pulling in classes that we don't want. We therefore propose to use 
simple matching in the definitions (with the possible exception of boot 
or base modules that are defined by other means).

One implication of simple module definitions is that we will need to 
look at a number of areas in the repository and split the packages or 
move classes to more appropriate places. To give one example, the http 
protocol handler supports the spnego authentication scheme that could 
move into a sub-package to make it easy to assign to the 
"security-kerberos" module. We'll likely conscript others to help with 
this work.

On tooling, we decided to create several "simple" tools, each doing one 
job well rather than building a Swiss Army knife. The tools that we 
discussed are:

1. The class analyzer that we use for analysis, possibly including 
generating class lists for boot/base modules.

2. A relatively simple tool to assign classes to modules defined by 
patterns. The modules definitions can be in a single file and ordering 
is only important where the patterns overlap. It should be relatively 
quick to run in the build and will output the class lists, dependencies, 
summary, and one file with the module dependencies.

3. A simple tool that compares module dependencies against a 
"checked-in" file. The tool fails if there if there is a dependency that 
isn't listed in the checked-in version. An open issue is optional 
dependencies where finer-grain checking would be required to detect a 
dependency that has changed into a "hard" dependency.

That's it!