You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
generates code for two independent SBE schemas in two different modules
with build parallelism set high (e.g. mvn clean install --batch-mode -T 1.5C -U on an 8-core machine)
Error:
Settings passed on as System Properties, via pom.xml to module A are sometimes applied to module B. As an example, generated files may be written into another module's output folder.
Expected:
Settings applied per module as configured in the pom.xml of that module.
Suggestion:
Pass settings as Arguments to avoid concurrency issues caused by altering System Properties, or even better — load from a local file. Keep System Properties as a fallback for backwards compatibility.
The text was updated successfully, but these errors were encountered:
dmitry-livchak-qco
changed the title
SBE Tool Crashes on Multi-Module Maven Projects with High Build Parallelism
SBE Tool Fails Maven Builds on Multi-Module Projects with High Build Parallelism
Jun 25, 2024
dmitry-livchak-qco
changed the title
SBE Tool Fails Maven Builds on Multi-Module Projects with High Build Parallelism
SBE Tool Fails Maven Multi-Module Builds
Jun 25, 2024
I've arrived here as I'm having similar potential issue in a gradle kotlin DSL plugin. I'm calling SbeTool.main directly in my plugin ( rather than using a javaexec task), largely for efficiency reasons, so don't have to spawn a child JVM just to call this one method. So I'm having to call System.setProperty to inject properties into SbeTool.main. Would providing an overload that explicitly takes properties make sense? The main method would call this overload passing System.getProperties as an argument.
Context:
mvn clean install --batch-mode -T 1.5C -U
on an 8-core machine)Error:
Settings passed on as System Properties, via
pom.xml
tomodule A
are sometimes applied tomodule B
. As an example, generated files may be written into another module's output folder.Expected:
Settings applied per module as configured in the
pom.xml
of that module.Suggestion:
Pass settings as Arguments to avoid concurrency issues caused by altering System Properties, or even better — load from a local file. Keep System Properties as a fallback for backwards compatibility.
The text was updated successfully, but these errors were encountered: