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

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to