I have made significant progress in splitting the UIs from core. However,
the collective change that results is far too large to review. So I am
going to create a number of smaller changes to core and then move the UIs
in 3 major jumps.
Basically:
Splitting the UIs off made the shared integration testing more difficult
under the old approach and demanded a new approach. Under the new approach
core will
- Define a class "TestData". This instances will:
- Have a unique name.
- Contain the command line arguments,
- A consumer of a "Path" object that will construct any necessary
test files.
- A consumer of "ValidatorData", a new class that contains tests on
the results of execution.
- An optional Exception instance that is the expected exception when
one is expected.
- Define a class "ValidatorData" which comprises:
- The Output object of the RAT run.
- The "Path" that was the root of the RAT run.
- Define a class Reporter.Output that will be the result of a
Reporter.execute() call. This object will be serializable (not Java
Serializable implementation) but able to read/write state to/from a
directory, and will comprise:
- The XML output document from the report (before any transforms are
applied)
- The ClaimStatistic from the execution. This is a structure that
tracks how many of each errors were discovered during the run.
- The ReportConfiguration that was used for the run.
With these classes (and some modifications to support them) UIs will be
able to retrieve the required tests, execute construct calls to their
implementation and validate that the results are as expected.
Splitting the UIs also means that we want to create a core test jar that
contains all the dependencies. This will require a special packaging of
the core test jar to achieve this change.
Each UI will be implemented as a parent POM and potentially multiple child
modules. The reason for this is to support the CLI first strategy. The
recommended strategy for UI development is to map the CLI options into the
UI and then generate the code to support the UI. For example, under Maven,
there need to be 2 modules: tools and plugin (or mojo). Tools contains the
code to wrap the CLI Options with a translator to convert the names from
kebab style (for example "input-exclude") into the maven style
("inputExclude"). The tools also
- generate code as the base class for the Maven mojos
- generate test code
- provide support classes for the above 2 items.
Since the Maven UI requires the output from the tools to generate the code
for the UI they can not be in the same module.
This structure makes it easier to ensure that we have proper separation
between the UI and the core components.
*My proposed course*
I have the Maven module separation complete on the current feature branch.
But it is too large. So I propose to make the non-breaking changes to core
in a number of smaller PRs in the next few days.
I will reset and rework the feature branch to ensure that the changes only
reflect the requirement to move the UI classes out of core and the
restructuring of the build appropriately.
I will update the feature branch with PRs containing smaller changes. I
expect these change to consist of:
1. Extraction of CLI interface into a separate module. (tests will
probably fail)
2. Fixes to CLI tests.
3. Extraction of Maven interface into separate module (tests will fail)
4. Fixes to Maven tests.
5. Extraction of Ant interface into separate modules (tests will fail)
6. Fixes to Ant tests.
Note that the Ant work has not been started yet while the CLI and Maven
work is mostly done.
Hopefully, this will allows everyone to follow along and will not yield PRs
with 100's of files.
Claude
--
LinkedIn: http://www.linkedin.com/in/claudewarren
