RAT-573: Make RAT safe for parallel Maven builds by gnodet · Pull Request #704 · apache/creadur-rat

gnodet · 2026-07-26T20:09:48Z

Summary

Make the RAT Maven plugin safe for parallel builds (mvn -T4) by fixing four concurrency issues:

DefaultLog (ThreadLocal) — Replace the shared static Log instance with a ThreadLocal<Log> so each Maven reactor thread gets its own logger. Without this, thread A's DefaultLog.setInstance(makeLog()) overwrites thread B's logger, causing log output to be mislabeled or lost.
DeprecationReporter (ThreadLocal) — Same pattern: replace the shared static Consumer<Option> consumer with a ThreadLocal. The generated BaseRatMojo constructor calls setDeprecationReporter() per-module, creating the same overwrite race as DefaultLog.
OptionCollection.parseCommands() (synchronized) — Add synchronized because this method uses shared mutable state that is not thread-safe:
- Arg enum's OptionGroup.selected field is mutated by DefaultParser.parse()
- Converters.FILE_CONVERTER.workingDirectory is overwritten during argument processing
When two threads parse concurrently, thread A's --input-exclude setting gets overwritten by thread B's parse, causing exclusions to be silently skipped. The synchronized serializes only the config parsing phase — actual file scanning and license checking still runs in parallel.
SPDXMatcherFactory (ThreadLocal per-thread factory) — The singleton INSTANCE shares lastMatch/checked state and a static MATCHER_MAP across threads. When two threads scan different documents concurrently, both see both sets of SPDX IDs.
- MATCHER_MAP moved from static to instance field — each factory has its own matcher registry
- SpdxBuilder now uses a ThreadLocal<SPDXMatcherFactory> so each Maven reactor thread gets its own factory with isolated match state
- INSTANCE kept for backward compatibility (single-threaded use / tests)

Testing

New RAT-573 integration test: multi-module project (3 modules + parent) run with -T4, each module containing a src.apt file that must be excluded via **/src.apt pattern
Before the fix: ~10% failure rate under -T4 (exclusion silently skipped → RAT reports unlicensed files)
After the fix: 12/12 passes locally

Known remaining statics (out of scope)

MatcherBuilderTracker — tracks custom matchers via static state

These are more deeply embedded and would require more invasive changes.

Test plan

Full mvn clean install passes locally
RAT-573 integration test passes with -T4
RAT-268 integration test passes (restored to original single-threaded form)
CI matrix passes (all 12 platform/JDK combos)

🤖 Generated with Claude Code

… Maven builds Replace the plain static fields in DefaultLog and DeprecationReporter with ThreadLocal storage so that each thread (e.g. parallel Maven reactor threads using `mvn -T`) gets its own logger and deprecation reporter instance. Previously, every Mojo constructor overwrote the JVM-wide DefaultLog.instance singleton, causing log messages to be silently routed to the wrong module's logger during parallel builds. The same race condition affected DeprecationReporter.consumer. The public API (getInstance/setInstance, getLogReporter/setLogReporter) is preserved so all existing callers continue to work unchanged. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

ottlinger · 2026-07-26T21:16:32Z

@gnodet Thanks for your contribution! There seems to be another known issue in RAT preventing multithreaded parsing of ignore files (filed as RAT-553).

@Claudenw do you see any sideeffects with your current restructurings or should we merge this PR with a changelog?

ottlinger

LGTM, I've added a changelog and ran the branch locally. @Claudenw feel free to merge if you are okay as well.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Claudenw

This is a great start on an issue that has been in the back of my mind. However, these changes will not make RAT thread safe for multi threaded Maven.

There is a class called the MatcherBuilderTracker that also contains statics. This class tracks any matchers that have been declared. Basically you can write your own matcher for some special condition and add it to the run. Those are tracked in as static variable in the MatcherBuilderTracker and are loaded from the configuration file declaration.

The SPDXMatcher factory has a static instance of the matcher factory. The structure is used to ensure that the SPDX matchers checks are clustered. Calling one matcher check causes all the matcher checks to run at once. This is because all the matchers use the same regular expression pattern and it is far more efficient to run the match check once across the file and extract the SPDX id and then verify that its accepted rather than run the expression find for each SPDX id that is accepted.

There may also be issues with reading files, but as I recall that was just an idea that we could speed up the processing by using multiple threads to check the files in parallel.

I would suggest that you change the definition of RAT-573 to make it read that it will make RAT safe for parallel builds, and address the other issues as well.

Finally, there is a massive change coming wherein we split the UIs off into their own projects. This will not be impacted by the changes I see here. However, it does move the conversion from RAT command line options to Maven options into a Maven specific section and Maven will need to track the mappings. I don't think there are any statics in the prototype code, but I will keep an eye out.

Thank you for this contribution. It is greatly appreciated.

…el builds OptionCollection.parseCommands() uses shared mutable state: the Arg enum's OptionGroup instances (whose 'selected' field is mutated by DefaultParser.parse()) and Converters.FILE_CONVERTER (whose workingDirectory field is set during argument processing). When multiple Maven reactor threads call parseCommands() concurrently (e.g. mvn -T4), they corrupt each other's parse state. This causes options like --input-exclude to be silently skipped, resulting in files being incorrectly reported as having unapproved licenses. Making the method synchronized serializes only the configuration parsing phase; the actual file scanning and license checking still runs in parallel. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…gration test Restore RAT-268 to its original single-threaded form as requested by maintainer (integration tests named RAT-XXX are tied to specific Jira tickets and should not be modified for unrelated purposes). Add a new RAT-573 integration test that exercises the rat plugin under parallel Maven builds (-T4) with a multi-module project containing excluded files (src.apt). This directly tests the thread-safety fixes in DefaultLog, DeprecationReporter, and OptionCollection.parseCommands. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

gnodet · 2026-07-27T08:37:09Z

Thank you for the thorough review @Claudenw!

I've addressed both points:

RAT-268 restored — reverted to original single-threaded form. Created a dedicated RAT-573 integration test that runs with -T4 to exercise the thread-safety fixes.
Broader scope acknowledged — I've updated the PR description to document the remaining statics that would need attention for full thread-safety (SPDXMatcherFactory.INSTANCE, MatcherBuilderTracker, StandardCollection's builders). These are more deeply embedded and would require more invasive changes, so I've scoped this PR to the three most impactful fixes that resolve the reported parallel build failures:
- DefaultLog → ThreadLocal
- DeprecationReporter → ThreadLocal
- OptionCollection.parseCommands() → synchronized

The synchronized on parseCommands() was the key fix — it prevents concurrent DefaultParser.parse() calls from corrupting each other's OptionGroup.selected state and Converters.FILE_CONVERTER.workingDirectory, which was the root cause of exclusions being silently skipped under -T4.

Happy to update the RAT-573 Jira description if you'd like it reframed as "make RAT safe for parallel builds" rather than just the DefaultLog issue.

Claudenw · 2026-07-28T06:58:02Z

@gnodet , again thank you for your work on parallelizing RAT.

I think that the SPDX Matcher needs attention to make this functionally complete.

Issue:
Currently if two threads are running and each detect different SPDX ids they will both report that they have seen both Ids.

Analysis:
The SPDX matcher factory is created as a static INSTANCE in the SPDXMatcherFactory class. The factory has a lastMatch set variable that tracks the SPDX Ids that were seen in the scan of the last file.

The SPDXMatcherFactory creates instances of the SPDXMatcher class. Each of those instances point contain a reference to the factory. When they are triggered they insert their ID into the lastMatch set.

When the matcher is executed it calls the check method in the SPDXMatcherFactory. the SPDXMatcherFactory check verifies that the document has not be scanned and then scans for ALL defined matchers and places them into the lastMatch. If the SPDXMatcherFactory has already checked no action is taken.

When the matcher is queried to see if it has found a match it checks to see if its ID is in the SPDXMatcherFactory.lastMach .

There is a MATCHER_MAP static var in the SPDXMatcherFactory that could probably become a local variable.

The data that the Matcher is updating is contained in the SPDXMatcherFactory (probably a bad name at this point).

The SPDXBuilder is called when the configuration specifies an SPDX matcher is needed. The Builder calls to the SPDXMatcherFactory to create the matcher.

Potential Solution:

You have made the creation of the configuration synchronized. During the creation of the configuration we use the factory instance to create SPDX matchers.

If the SPDXMatcherFactory were made thread local to the SPDXBuilder, and the static variables in the SPDXMatcherFactory we mitigated I think this would solve the problem.

Question:
Are you willing to take on this change as part of your PR.

SPDXMatcherFactory.INSTANCE is a shared singleton whose lastMatch/checked state and static MATCHER_MAP are corrupted when two threads scan different documents concurrently: both threads see both sets of SPDX IDs. Changes: - MATCHER_MAP: moved from static to instance field so each factory instance maintains its own matcher registry - Constructor: changed from private to package-private, added newInstance() factory method for multi-threaded use - SpdxBuilder: uses a ThreadLocal<SPDXMatcherFactory> so each Maven reactor thread gets its own factory with isolated match state - INSTANCE kept for backward compatibility (single-threaded / tests) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

gnodet · 2026-07-28T07:07:17Z

@Claudenw Done — I've addressed the SPDXMatcherFactory thread-safety issue. Here's what changed:

SPDXMatcherFactory:

MATCHER_MAP moved from static to instance field (matcherMap) — each factory now has its own matcher registry, so Match instances created by one factory correctly reference that factory's lastMatch/checked state via SPDXMatcherFactory.this
Constructor changed from private to package-private, added newInstance() factory method
INSTANCE kept as-is for backward compatibility (single-threaded use and existing tests like SPDXMatcherTest)

SpdxBuilder:

Added ThreadLocal<SPDXMatcherFactory> FACTORY — each Maven reactor thread now gets its own factory instance
build() uses FACTORY.get().create(name) instead of SPDXMatcherFactory.INSTANCE.create(name)
Added removeFactory() cleanup method

This prevents the scenario you described: two threads scanning different files no longer share lastMatch, so they won't report each other's SPDX IDs.

All existing tests pass (including SPDXMatcherTest and SpdxBuilderTest), full mvn clean install BUILD SUCCESS.

DefaultLog.removeInstance(), DeprecationReporter.removeLogReporter(), and SpdxBuilder.removeFactory() were never wired into any cleanup path. The ThreadLocal values are naturally overwritten on each mojo execution via setInstance()/setLogReporter()/FACTORY.get(), so explicit removal is unnecessary. Remove the dead methods to avoid suggesting a cleanup contract that isn't enforced. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

gnodet · 2026-07-28T12:48:04Z

@Claudenw I did a thorough audit of the codebase for other static mutable state that could cause issues under parallel builds. Here are the results:

Already fixed in this PR

DefaultLog — static singleton → ThreadLocal
DeprecationReporter — static singleton → ThreadLocal
OptionCollection.parseCommands() — synchronized (protects OptionGroup.selected and Converters.FILE_CONVERTER.workingDirectory)
SPDXMatcherFactory — ThreadLocal factory in SpdxBuilder

Remaining: `MatcherBuilderTracker`

The instance() method is synchronized, which protects lazy init. However, addBuilderImpl() and getMatcherBuilder() operate on a plain HashMap after the instance() call returns — those HashMap operations are not synchronized.

In practice the risk is low: the map is mostly populated once during Defaults.init() inside the synchronized init block. But concurrent addBuilder() calls from modules with custom matcher XML configs (via XMLConfigurationReader.readMatcherBuilders()) could corrupt the map.

Minimal fix would be HashMap → ConcurrentHashMap. Happy to include that in this PR if you'd like — it's a one-line change.

Everything else: safe

All other static fields I checked (13+) are either immutable after class loading, stateless singletons, use ConcurrentHashMap, or are already protected by the synchronized parseCommands():

CLIOptionCollection.INSTANCE — mutable OptionGroup.selected, but protected by synchronized parseCommands()
Converters.FILE_CONVERTER — mutable workingDirectory, but protected by synchronized parseCommands()
BaseRatMojo static maps — populated once in static init, read-only
TikaProcessor.TIKA — Tika is documented as thread-safe
DocumentName.FSInfo.REGISTRY — uses ConcurrentHashMap
SelectorUtils.INSTANCE, UnknownLicense.INSTANCE — stateless/immutable singletons

ottlinger · 2026-07-28T14:14:07Z

@gnodet thanks, could you point your claude session to the classes mentioned in:
https://issues.apache.org/jira/browse/RAT-553

HgIgnoreBuilder
GitIgnoreBuilder
that seem to have parallelism issues as well. Thanks for the great findings.

gnodet · 2026-07-28T14:21:58Z

@ottlinger Thanks for pointing to RAT-553. I looked at HgIgnoreBuilder and GitIgnoreBuilder — here's the analysis:

Root cause: shared mutable builder instances in `StandardCollection` enum

StandardCollection is an enum, so each constant holds one shared instance of the builder:

GIT(..., new GitIgnoreBuilder()),       // line 99 — single instance for all threads
MERCURIAL(..., new HgIgnoreBuilder()),  // line 173 — single instance for all threads

fileProcessorBuilder() (line 294) returns that same shared instance. When ExclusionProcessor.extractFileProcessors() calls builder.build(basedir) from two reactor threads concurrently, they corrupt each other's state:

AbstractFileProcessorBuilder.levelBuilders (line 71) — a TreeMap that is populated during build() and clear()'d at line 135. Two threads writing/clearing the same TreeMap concurrently → ConcurrentModificationException or corrupted data.
HgIgnoreBuilder.state (line 52) — a mutable Syntax field (REGEXP/GLOB) reset to REGEXP at the start of process() (line 64) and toggled by modifyEntry() (line 72) as it parses syntax: glob / syntax: regexp directives. Two threads processing different .hgignore files concurrently → wrong syntax applied to entries.

GitIgnoreBuilder itself doesn't have extra mutable instance state beyond what's inherited from AbstractFileProcessorBuilder, but the shared levelBuilders is enough to cause corruption.

Potential fix

The StandardCollection enum could store a Supplier<AbstractFileProcessorBuilder> instead of an instance, so fileProcessorBuilder() returns a fresh builder each time. That way each thread gets its own instance with isolated state.

Happy to include this fix in the PR if you'd like — it's a focused change in StandardCollection and AbstractFileProcessorBuilder.

MatcherBuilderTracker: use ConcurrentHashMap instead of HashMap for the matcher builder registry, preventing corruption when multiple threads register or look up builders concurrently. StandardCollection: store a Supplier<AbstractFileProcessorBuilder> instead of a shared builder instance. Enum constants are singletons, so the previous shared GitIgnoreBuilder/HgIgnoreBuilder/etc. instances had their mutable state (levelBuilders TreeMap, HgIgnoreBuilder.state) corrupted when two threads called build() concurrently. The supplier creates a fresh builder per invocation, eliminating the race. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

gnodet · 2026-07-28T15:20:12Z

Latest commit: `MatcherBuilderTracker` + `StandardCollection` thread-safety fixes

Based on the earlier audit discussion, this commit (18a4149) includes two additional fixes:

1. `MatcherBuilderTracker`: `HashMap` → `ConcurrentHashMap`

The singleton MatcherBuilderTracker uses a synchronized instance() method, but once the instance is obtained, addBuilderImpl() and getMatcherBuilder() access the underlying HashMap without synchronization. In a parallel Maven build, concurrent put()/get() on a HashMap can cause infinite loops (hash bucket cycles) or lost entries.

Fix: One-line change — new HashMap<>() → new ConcurrentHashMap<>().

2. `StandardCollection`: `Supplier<AbstractFileProcessorBuilder>` instead of shared instances

This is the GitIgnoreBuilder/HgIgnoreBuilder issue discussed earlier. The StandardCollection enum constants stored shared singleton builder instances:

GIT(..., new GitIgnoreBuilder())
MERCURIAL(..., new HgIgnoreBuilder())
BAZAAR(..., new BazaarIgnoreBuilder())
CVS(..., new CVSIgnoreBuilder())

These builders contain mutable state:

AbstractFileProcessorBuilder.levelBuilders — a TreeMap populated during build(), then clear()'d
HgIgnoreBuilder.state — a Syntax enum toggled during parsing

Since enum constants are singletons, concurrent threads calling build() on the same shared instance would corrupt each other's state.

Fix: Store a Supplier<AbstractFileProcessorBuilder> instead, so each fileProcessorBuilder() call creates a fresh builder:

GIT(..., GitIgnoreBuilder::new)        // was: new GitIgnoreBuilder()
MERCURIAL(..., HgIgnoreBuilder::new)   // was: new HgIgnoreBuilder()

Both fixes pass the full build locally (mvn clean install -B — BUILD SUCCESS).

ottlinger · 2026-07-28T19:26:01Z

@gnodet can you retest that the site build works locally with you?
.budiltools/site
fails with a Java heap space problem in apache-rat-tasks while generating the dependencies report (maven-project-info-reports-plugin:3.9.0) with Maven 3.9.16 and JDK 25.0.2 with me.
(Branch master works fine)

- Deprecate INSTANCE field (will be removed in 1.0.0) - Make constructor private - Use computeIfAbsent() in create() method - Update changes.xml to "Make RAT safe for parallel builds" Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

gnodet · 2026-07-29T07:57:27Z

@ottlinger I ran .buildtools/site (./mvnw -B clean package site site:stage) locally and it completed successfully — no heap space issues:

Reactor Summary for Apache Creadur RAT 1.0.0-SNAPSHOT:
Apache Creadur RAT ................................. SUCCESS [ 48.963 s]
Apache Creadur RAT::Core ........................... SUCCESS [01:21 min]
Apache Creadur RAT::Tools .......................... SUCCESS [ 28.819 s]
Apache Creadur RAT::Plugin4Maven ................... SUCCESS [ 54.592 s]
Apache Creadur RAT::Tasks4Ant ...................... SUCCESS [ 58.730 s]
Apache Creadur RAT::Testdata ....................... SUCCESS [  3.491 s]
Apache Creadur RAT::Packaging ...................... SUCCESS [01:10 min]
BUILD SUCCESS

This was on JDK 21. The heap space issue you saw with JDK 25 + Maven 3.9.16 in apache-rat-tasks might be environment-specific rather than related to this PR's changes (since master works fine for you and this PR doesn't touch apache-rat-tasks at all).

gnodet · 2026-07-29T09:09:49Z

@ottlinger I investigated the site build issue more thoroughly, now testing with JDK 25.0.3 + Maven 3.9.16 (same versions you reported):

Results

Scenario	Heap	Result
This branch, JDK 25, default heap (~4GB ergonomic)	~4GB	✅ BUILD SUCCESS
This branch, JDK 21, default heap	~4GB	✅ BUILD SUCCESS
This branch, JDK 25, `-Xmx1g`	1GB	❌ `exec-maven-plugin` template failure in `apache-rat-plugin`
`master`, JDK 25, `-Xmx1g`	1GB	❌ Same `exec-maven-plugin` template failure

The 1GB failure is identical on both master and this branch — exec-maven-plugin:3.6.3:java fails on Velocity template processing with Unable to find resource '...index.apt.vm.vm'. This is a pre-existing issue unrelated to this PR.

This PR makes no changes to pom.xml dependency trees, so there's nothing here that would increase memory consumption during site generation.

If you're seeing a heap space issue specifically in apache-rat-tasks during the dependencies report, it might be related to:

Available system RAM (JDK ergonomics sets max heap to ~1/4 of physical RAM)
An explicit MAVEN_OPTS setting that caps heap too low
Other processes consuming memory on the machine

Could you share the exact error output and your MAVEN_OPTS / JAVA_OPTS settings?

ottlinger · 2026-07-29T19:25:20Z

The build problems remain with JDK 25.0.2 and 25.0.4:

20:01 $ .buildtools/site
Java HotSpot(TM) 64-Bit Server VM warning: Option -Xdebug was deprecated in JDK 22 and will likely be removed in a future release.
Apache Maven 3.9.16 (2bdd9fddda4b155ebf8000e807eb73fd829a51d5)
Maven home: /home/me/.m2/wrapper/dists/apache-maven-3.9.16/56ba1f9f
Java version: 25.0.2, vendor: Oracle Corporation, runtime: /home/me/jdk-25.0.2
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "7.0.0-28-generic", arch: "amd64", family: "unix"

Build fails with:

[INFO] Generating "Javadoc" report              --- maven-javadoc-plugin:3.12.0:javadoc
[INFO] Generating "Source Xref" report          --- maven-jxr-plugin:3.6.0:jxr-no-fork
[INFO] Generating "Test Source Xref" report     --- maven-jxr-plugin:3.6.0:test-jxr-no-fork
[INFO] Generating "PMD" report                  --- maven-pmd-plugin:3.28.0:pmd
[INFO] Generating "Dependencies" report         --- maven-project-info-reports-plugin:3.9.0:dependencies
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Apache Creadur RAT 1.0.0-SNAPSHOT:
[INFO]
[INFO] Apache Creadur RAT ................................. SUCCESS [ 24.849 s]
[INFO] Apache Creadur RAT::Core ........................... SUCCESS [ 42.500 s]
[INFO] Apache Creadur RAT::Tools .......................... SUCCESS [ 16.395 s]
[INFO] Apache Creadur RAT::Plugin4Maven ................... SUCCESS [ 24.631 s]
[INFO] Apache Creadur RAT::Tasks4Ant ...................... FAILURE [02:13 min]
[INFO] Apache Creadur RAT::Testdata ....................... SKIPPED
[INFO] Apache Creadur RAT::Packaging ...................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  04:03 min
[INFO] Finished at: 2026-07-29T20:16:30+02:00
[INFO] ------------------------------------------------------------------------
[INFO] 256 goals, 256 executed
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.22.0:site (default-site) on project apache-rat-tasks: Failed to render site: Error generating maven-project-info-reports-plugin:3.9.0:dependencies report: UndeclaredThrowableException: InvocationTargetException: Java heap space -> [Help 1]

If Maven is run with -X -e the following stacktrace is shown:

[DEBUG] State transition from 'CLOSED' to 'CLOSED' for Develocity Maven extension version '2.5.0'.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.22.0:site (default-site) on project apache-rat-tasks: Failed to render site: Error generating maven-project-info-reports-plugin:3.9.0:dependencies report: UndeclaredThrowableException: InvocationTargetException: Java heap space -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.22.0:site (default-site) on project apache-rat-tasks: Failed to render site
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:333)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:919)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:285)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:207)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:362)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to render site
    at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:132)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at com.gradle.maven.cache.extension.c.n.a (SourceFile:53)
    at com.gradle.maven.cache.extension.c.d.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.q.a (SourceFile:23)
    at com.gradle.maven.cache.extension.c.j.a (SourceFile:28)
    at com.gradle.maven.cache.extension.c.p.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.b.c (SourceFile:118)
    at com.gradle.maven.cache.extension.c.b.a (SourceFile:62)
    at com.gradle.maven.cache.extension.c.g.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.a.a (SourceFile:46)
    at com.gradle.maven.cache.extension.c.o.a (SourceFile:18)
    at com.gradle.maven.cache.extension.c.a.a (SourceFile:46)
    at com.gradle.maven.cache.extension.c.c.a (SourceFile:26)
    at com.gradle.maven.cache.extension.c.h$1.run (SourceFile:35)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute (SourceFile:30)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute (SourceFile:27)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute (SourceFile:67)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute (SourceFile:60)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute (SourceFile:167)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute (SourceFile:60)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.run (SourceFile:48)
    at com.gradle.maven.cache.extension.c.h.a (SourceFile:31)
    at com.gradle.maven.cache.extension.c.m.a (SourceFile:80)
    at com.gradle.maven.cache.extension.g.b.lambda$createProxy$0 (SourceFile:77)
    at jdk.proxy10.$Proxy91.execute (Unknown Source)
    at com.gradle.maven.scan.extension.internal.e.b.executeMojo (SourceFile:116)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:919)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:285)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:207)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:362)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error generating maven-project-info-reports-plugin:3.9.0:dependencies report
    at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument (ReportDocumentRenderer.java:204)
    at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render (DefaultSiteRenderer.java:395)
    at org.apache.maven.plugins.site.render.SiteMojo.renderNonDoxiaDocuments (SiteMojo.java:299)
    at org.apache.maven.plugins.site.render.SiteMojo.renderLocale (SiteMojo.java:164)
    at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:125)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at com.gradle.maven.cache.extension.c.n.a (SourceFile:53)
    at com.gradle.maven.cache.extension.c.d.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.q.a (SourceFile:23)
    at com.gradle.maven.cache.extension.c.j.a (SourceFile:28)
    at com.gradle.maven.cache.extension.c.p.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.b.c (SourceFile:118)
    at com.gradle.maven.cache.extension.c.b.a (SourceFile:62)
    at com.gradle.maven.cache.extension.c.g.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.a.a (SourceFile:46)
    at com.gradle.maven.cache.extension.c.o.a (SourceFile:18)
    at com.gradle.maven.cache.extension.c.a.a (SourceFile:46)
    at com.gradle.maven.cache.extension.c.c.a (SourceFile:26)
    at com.gradle.maven.cache.extension.c.h$1.run (SourceFile:35)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute (SourceFile:30)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute (SourceFile:27)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute (SourceFile:67)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute (SourceFile:60)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute (SourceFile:167)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute (SourceFile:60)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.run (SourceFile:48)
    at com.gradle.maven.cache.extension.c.h.a (SourceFile:31)
    at com.gradle.maven.cache.extension.c.m.a (SourceFile:80)
    at com.gradle.maven.cache.extension.g.b.lambda$createProxy$0 (SourceFile:77)
    at jdk.proxy10.$Proxy91.execute (Unknown Source)
    at com.gradle.maven.scan.extension.internal.e.b.executeMojo (SourceFile:116)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:919)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:285)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:207)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:362)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
Caused by: java.lang.reflect.UndeclaredThrowableException
    at jdk.proxy23.$Proxy122.generate (Unknown Source)
    at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument (ReportDocumentRenderer.java:193)
    at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render (DefaultSiteRenderer.java:395)
    at org.apache.maven.plugins.site.render.SiteMojo.renderNonDoxiaDocuments (SiteMojo.java:299)
    at org.apache.maven.plugins.site.render.SiteMojo.renderLocale (SiteMojo.java:164)
    at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:125)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at com.gradle.maven.cache.extension.c.n.a (SourceFile:53)
    at com.gradle.maven.cache.extension.c.d.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.q.a (SourceFile:23)
    at com.gradle.maven.cache.extension.c.j.a (SourceFile:28)
    at com.gradle.maven.cache.extension.c.p.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.b.c (SourceFile:118)
    at com.gradle.maven.cache.extension.c.b.a (SourceFile:62)
    at com.gradle.maven.cache.extension.c.g.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.a.a (SourceFile:46)
    at com.gradle.maven.cache.extension.c.o.a (SourceFile:18)
    at com.gradle.maven.cache.extension.c.a.a (SourceFile:46)
    at com.gradle.maven.cache.extension.c.c.a (SourceFile:26)
    at com.gradle.maven.cache.extension.c.h$1.run (SourceFile:35)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute (SourceFile:30)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute (SourceFile:27)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute (SourceFile:67)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute (SourceFile:60)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute (SourceFile:167)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute (SourceFile:60)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.run (SourceFile:48)
    at com.gradle.maven.cache.extension.c.h.a (SourceFile:31)
    at com.gradle.maven.cache.extension.c.m.a (SourceFile:80)
    at com.gradle.maven.cache.extension.g.b.lambda$createProxy$0 (SourceFile:77)
    at jdk.proxy10.$Proxy91.execute (Unknown Source)
    at com.gradle.maven.scan.extension.internal.e.b.executeMojo (SourceFile:116)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:919)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:285)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:207)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:362)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
Caused by: java.lang.reflect.InvocationTargetException
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:119)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at com.gradle.maven.cache.extension.g.b.lambda$createProxy$0 (SourceFile:80)
    at jdk.proxy23.$Proxy122.generate (Unknown Source)
    at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument (ReportDocumentRenderer.java:193)
    at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render (DefaultSiteRenderer.java:395)
    at org.apache.maven.plugins.site.render.SiteMojo.renderNonDoxiaDocuments (SiteMojo.java:299)
    at org.apache.maven.plugins.site.render.SiteMojo.renderLocale (SiteMojo.java:164)
    at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:125)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at com.gradle.maven.cache.extension.c.n.a (SourceFile:53)
    at com.gradle.maven.cache.extension.c.d.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.q.a (SourceFile:23)
    at com.gradle.maven.cache.extension.c.j.a (SourceFile:28)
    at com.gradle.maven.cache.extension.c.p.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.b.c (SourceFile:118)
    at com.gradle.maven.cache.extension.c.b.a (SourceFile:62)
    at com.gradle.maven.cache.extension.c.g.a (SourceFile:27)
    at com.gradle.maven.cache.extension.c.a.a (SourceFile:46)
    at com.gradle.maven.cache.extension.c.o.a (SourceFile:18)
    at com.gradle.maven.cache.extension.c.a.a (SourceFile:46)
    at com.gradle.maven.cache.extension.c.c.a (SourceFile:26)
    at com.gradle.maven.cache.extension.c.h$1.run (SourceFile:35)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute (SourceFile:30)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute (SourceFile:27)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute (SourceFile:67)
    at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute (SourceFile:60)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute (SourceFile:167)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.execute (SourceFile:60)
    at org.gradle.internal.operations.DefaultBuildOperationRunner.run (SourceFile:48)
    at com.gradle.maven.cache.extension.c.h.a (SourceFile:31)
    at com.gradle.maven.cache.extension.c.m.a (SourceFile:80)
    at com.gradle.maven.cache.extension.g.b.lambda$createProxy$0 (SourceFile:77)
    at jdk.proxy10.$Proxy91.execute (Unknown Source)
    at com.gradle.maven.scan.extension.internal.e.b.executeMojo (SourceFile:116)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:919)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:285)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:207)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:362)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
Caused by: java.lang.OutOfMemoryError: Java heap space

MAVEN_OPTS is set to '-Xmx384M -Xdebug' - once I set it to
'-Xmx1024M -Xdebug' the build works fine. Not really sure why this happened with your PR ;)

ottlinger · 2026-07-29T20:38:49Z

@gnodet thanks for your contribution!

ottlinger changed the title ~~fix: make DefaultLog and DeprecationReporter thread-safe for parallel Maven builds~~ RAT-573: fix: make DefaultLog and DeprecationReporter thread-safe for parallel Maven builds Jul 26, 2026

RAT-573: Make DefaultLog and DeprecationReporter threadsafe

891a233

ottlinger requested review from Claudenw and ottlinger July 26, 2026 21:27

ottlinger approved these changes Jul 26, 2026

View reviewed changes

ottlinger and others added 2 commits July 27, 2026 00:00

RAT-573: Make one of the integration tests run with 4 threads

ed1bf12

ci: retrigger CI (RAT-268 flaky test on second run)

fd0ab7d

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Claudenw requested changes Jul 27, 2026

View reviewed changes

Comment thread apache-rat-plugin/src/it/RAT-268/invoker.properties

gnodet and others added 2 commits July 27, 2026 10:19

gnodet changed the title ~~RAT-573: fix: make DefaultLog and DeprecationReporter thread-safe for parallel Maven builds~~ RAT-573: Make RAT safe for parallel Maven builds Jul 27, 2026

gnodet marked this pull request as ready for review July 27, 2026 10:27

Claudenw requested changes Jul 28, 2026

View reviewed changes

Claudenw approved these changes Jul 29, 2026

View reviewed changes

RAT-553: Add changelog about bugfix in all SCM ignore parsers

be95b02

ottlinger merged commit 04b752f into apache:master Jul 29, 2026
12 of 13 checks passed

ottlinger mentioned this pull request Jul 29, 2026

RAT-573, RAT-553: Regen webpage apache/creadur-site#8

Merged

Uh oh!

Conversation

gnodet commented Jul 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing

Known remaining statics (out of scope)

Test plan

Uh oh!

ottlinger commented Jul 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ottlinger left a comment

Choose a reason for hiding this comment

Uh oh!

Claudenw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gnodet commented Jul 27, 2026

Uh oh!

Claudenw commented Jul 28, 2026

Uh oh!

gnodet commented Jul 28, 2026

Uh oh!

gnodet commented Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Already fixed in this PR

Remaining: MatcherBuilderTracker

Everything else: safe

Uh oh!

ottlinger commented Jul 28, 2026

Uh oh!

gnodet commented Jul 28, 2026

Root cause: shared mutable builder instances in StandardCollection enum

Potential fix

Uh oh!

gnodet commented Jul 28, 2026

Latest commit: MatcherBuilderTracker + StandardCollection thread-safety fixes

1. MatcherBuilderTracker: HashMap → ConcurrentHashMap

2. StandardCollection: Supplier<AbstractFileProcessorBuilder> instead of shared instances

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ottlinger commented Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gnodet commented Jul 29, 2026

Uh oh!

gnodet commented Jul 29, 2026

Results

Uh oh!

ottlinger commented Jul 29, 2026

Uh oh!

ottlinger commented Jul 29, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

gnodet commented Jul 26, 2026 •

edited

Loading

ottlinger commented Jul 26, 2026 •

edited

Loading

gnodet commented Jul 28, 2026 •

edited

Loading

Remaining: `MatcherBuilderTracker`

Root cause: shared mutable builder instances in `StandardCollection` enum

Latest commit: `MatcherBuilderTracker` + `StandardCollection` thread-safety fixes

1. `MatcherBuilderTracker`: `HashMap` → `ConcurrentHashMap`

2. `StandardCollection`: `Supplier<AbstractFileProcessorBuilder>` instead of shared instances

ottlinger commented Jul 28, 2026 •

edited

Loading