You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@creadur.apache.org by Claude Warren <cl...@apache.org> on 2025/12/06 10:02:03 UTC
[RAT] Project restructure
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.
I am proposing that we restructure RAT in an attempt to reduce the
complexity of the build and the size of the resulting jar as well as
supporting Junit5 style tests in the UIs that can be driven by test data
and algorithms from the the core.
Currently RAT has 6 modules: rat, rat-core, rat-plugin, rat-tasks,
rat-testdat, and rat-tools.
- rat: builds the final packaging.
- rat-core: the core code and CLI UI.
- rat-plugin: the Maven UI.
- rat-tasks: the Ant UI.
- rat-testdata: the test data to ensure that tests are consistent.
- rat-tools: tools to help generate documentation and UIs.
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.
- 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.
For the time being all projects would share the same version number. We
can discuss different cadences later.
The Maven and Ant UI may be able to use something like Velocity to generate
some testing source without creating custom tools. The rat-core tooling
will try to emphasize and support this.
Using this structure should make the build simpler as we will be able use
earlier packages to generate the code in later testing.
This should provide us a clean separation of the various UIs.
This should reduce the size of the deployed jar regardless of the UI that
is being used.
If there is no objection I would like to start a feature branch to do this
work on.
Anybody who is interested in building a UI or maintaining one of the
current UIs is welcome to work on the feature branch.
This will mean extra work as we will have to keep the feature branch
reasonably aligned with the fixes.
Please comment.
Claude
Re: [RAT] Project restructure
Posted by Claude Warren <cl...@xenei.com>.
The feature branch has the basic outline of the structure and functional
CLI. The Maven code is structured but not functional, I am having problems
getting the Maven test code to function as some of the Mojo functions are
not being set correctly. In addition there are several other issues:
1. The shaded poms should be created in the UI projects not in the core
as is currently done. This is a minor issue.
2. The ANT code needs to be migrated and then we can remove the test
data package and tools package. The tools code is redistributed into the
separate UI projects.
3. The site documentation needs updated and we need to rework the
aggregation slightly.
The end result of this change is:
1. Good examples of how to build a new UI.
2. Good code isolation.
3. UI hosts (Ant, Maven) are not included in the main packaging.
4. UI can evolve faster than the core so that the UI can be released
separately if desired.
On Mon, Dec 15, 2025 at 5:35 PM Claude Warren <cl...@xenei.com> wrote:
> I put a feature branch together for the restructure [1]. It is
> incomplete. The core compiles and the core tests are produced as a jar
> with dependencies specified so they can be used in further tests.
>
>
> - The core Client code has been moved to apache-rat-cli along with
> some of the tools code for the cli.
> - The testdata module has been moved into the core test jar and the
> module removed.
> - The Some code was moved from tools to core but there needs to be a
> cleanup to resolve issues with different UIs. They should not be leaking
> into core.
> - A ui package was added to core to contain the UI support code
> - the plugin module was split and the module renamed a plugin-parent
> with the implementation retaining the older name. There is also now a
> plugin-tools module which will contains any code that is required to
> generate code for the plugin module. The plugin module will be updated to
> the latest v3 maven and the testing library modified to use Junit5. Much
> of the support for this has already occured in the core and core test
> modules.
> - The ant library has not been touched but should be restructured
> along the lines of the maven module with a tools and impl submodules.
>
> I will continue to work on pushing this forward when not working on 0.18
> release code.
>
> Claude
>
>
>
>
> [1] https://github.com/apache/creadur-rat/tree/feature/restructure
>
> On Sat, Dec 6, 2025 at 2:41 PM Claude Warren <cl...@xenei.com> wrote:
>
>> 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 <po...@apache.org>
>> 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
>>
>
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
--
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [RAT] Project restructure
Posted by Claude Warren <cl...@xenei.com>.
I put a feature branch together for the restructure [1]. It is
incomplete. The core compiles and the core tests are produced as a jar
with dependencies specified so they can be used in further tests.
- The core Client code has been moved to apache-rat-cli along with some
of the tools code for the cli.
- The testdata module has been moved into the core test jar and the
module removed.
- The Some code was moved from tools to core but there needs to be a
cleanup to resolve issues with different UIs. They should not be leaking
into core.
- A ui package was added to core to contain the UI support code
- the plugin module was split and the module renamed a plugin-parent
with the implementation retaining the older name. There is also now a
plugin-tools module which will contains any code that is required to
generate code for the plugin module. The plugin module will be updated to
the latest v3 maven and the testing library modified to use Junit5. Much
of the support for this has already occured in the core and core test
modules.
- The ant library has not been touched but should be restructured along
the lines of the maven module with a tools and impl submodules.
I will continue to work on pushing this forward when not working on 0.18
release code.
Claude
[1] https://github.com/apache/creadur-rat/tree/feature/restructure
On Sat, Dec 6, 2025 at 2:41 PM Claude Warren <cl...@xenei.com> wrote:
> 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 <po...@apache.org>
> 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
>
--
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [RAT] Project restructure
Posted by "P. Ottlinger" <po...@apache.org>.
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