Hi, Am 06.12.25 um 11:02 schrieb Claude Warren:
This issue has come to the fore for me because the Maven tooling tests require Junit5 patterns with annotations. This means that the full layout of the test cases have to be defined before the code compiles. This is in direct conflict with the current strategy of building test cases by adding minor functionality to existing tests. The new solution requires that the test cases be generated as code and then compiled.
Is this due to the generator approach we took in 0.17?Can you push your feature branches so that one can see the issues you ran into?
<snip>
I would like to restructure this to:
- rat-core: the core code without UI.
- Test code to provide tools to build and test UI and to generate
documentation.
- This code contains the apache commons cli option generation and
list of functionality. The UIs will utilize this information to generate
their UI to support the core functionality.
- packaged as a jar, test-jar, source-jar, test-source-jar
- rat-test.jar contains test code and code to assist in generating UI
test code.
- rat-plugin: (perhaps renamed to rat-maven) the Maven UI.
- Probably 2 parts: a sub-module to generate specific Maven test code
from the UI test data, and a UI module that generates the maven
plugin and
tests it using the tools from the first sub-module.
I always thought that naming it "-plugin" would be some sort of convention in the Maven sphere. Thus I'd prefer to stick with the old naming as RAT is a Maven plugin.
- Uses rat.jar and rat-test.jar.
- packaged as Maven plugin jar, test-jar, source-jar, test-source-jar
- rat-tasks (perhaps renamed to rat-ant) the Ant UI. May require 2
sub-modules like Maven.
- packaged as an Ant task library jar, test-jar, source-jar,
test-source.jar
- rat-cli: The rat command line UI. Extracted from current rat-core.
- packaged as an executable jar, test-jar, source-jar,
test-source.jar, and tar file containing executable jar and scripts to
easily run it.
- rat-site: project to specifically generate the rat web site.
- packaged as a source-jar, test-source.jar
- Used to generate the site.
- May have scripts to help with deployment.
As the CREADUR webpage lives in a separate repository I'd prefer a solution that each submodule generates its site-data by itself and the resulting files can be copied over to the creadur-site-repository. Thus I'd prefer not to have a specific rat-site submodule.
The more modular RAT becomes the easier it should be to generate documentation/webpages.
Would we remain with a mono repo approach for all RAT-modules? I'm just wondering how a release would look like ... if I got you correctly we would have a multi-submodule-structure which makes it quite complex to work with RAT .... is it possible to flatten the structure so that it becomes:
=RAT --> apache-rat-plugin (generates the Maven plugin) --> apache-rat-plugin-test (generate specific Maven test code) instead of =RAT --> apache-rat-plugin --> apache-rat-plugin-test (generate specific Maven test code) --> apache-rat-plugin-core (generates the Maven plugin) Cheers, Phil
OpenPGP_signature.asc
Description: OpenPGP digital signature
