Anything is possible. My thought was to structure the cli, maven, and ant as we would like to see any 3rd party UI developed.
The generator approach is, I think, correct for us as we want to be able to say to UI developers: here are the tests that you need to run, here are the parameters you need to generate and your result must produce these results. The issue is some UIs depend on Junit5 annotations to execute tests. These require that you have a bunch of a priori knowledge at coding time. I will put a feature branch together. But first I am going to look at a pair of issues. On Sat, Dec 6, 2025 at 12:58 PM P. Ottlinger <[email protected]> wrote: > 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 > -- LinkedIn: http://www.linkedin.com/in/claudewarren
