Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SBE Tool Fails Maven Multi-Module Builds #998

Open
dmitry-livchak-qco opened this issue Jun 25, 2024 · 2 comments
Open

SBE Tool Fails Maven Multi-Module Builds #998

dmitry-livchak-qco opened this issue Jun 25, 2024 · 2 comments

Comments

@dmitry-livchak-qco
Copy link

dmitry-livchak-qco commented Jun 25, 2024

Context:

  • SBE Tool is integrated in a Maven build
  • in a multi-module project
  • 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.

@dmitry-livchak-qco 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 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
@smandy
Copy link

smandy commented Jun 28, 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.

@smandy
Copy link

smandy commented Jun 28, 2024

I've raised PR #1002 for consideration.

I believe this provides a workable solution for @dmitry-livchak-qco 's (and my!) problem

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants