Make Java dev workflow robust to concurrent target executions

[tschaffter]

This issue has been solved for CI workflow in #503, but developers who run concurrent Java-Maven targets may bump into random errors. A secondary goal is to centralize Maven configuration so that multiple projects can be updated at the same time.

Set of solutions considered:

• Add Maven to the devcontainer and bypass the Maven wrapper
  • Partially solve concurrency issue (avoid concurrent download of Maven)
  • Need to evaluate the impact on the dockerization of Spring Boot services
• Add workspace-wide Maven wrapper
  • Centralize the version of Maven used.
  • Can we specify the location of the Maven wrapper to @nxrocks/nx-spring-boot?
• Provide each Maven project with a custom repository folder?
• Use the Takari Maven extension for reliable concurrent executions of Maven?
  • How to install it?
  • Does not solve concurrency issue when downloading the Maven binary.
  • The project seems no longer maintainer so not an option. The last update was 3 years ago.

[tschaffter]

@tinesoft I looked into another plugin for Nx and Spring Boot called @jnxplus/nx-boot-maven. One approach they are taking is to install the Maven of Gradle wrapper in the workspace folder and then have projects use it. This approach has the advantage of avoiding duplicated code, though in some cases the isolation that comes with being able to use different Maven wrapper in different projects may be more beneficial. Is it currently possible to configure @nxrocks/nx-spring-boot to look for the Maven wrapper inside a specified folder instead?

[tschaffter]

Running ./mvnw dependency:go-offline is relatively fast after the first run.

$ yarn nx run-many --target=prepare-java --parallel=1
yarn run v1.22.19
$ /workspaces/challenge-registry/node_modules/.bin/nx run-many --target=prepare-java --parallel=1

    ✔  nx run challenge-api-gateway:prepare-java (2s)
    ✔  nx run challenge-auth-service:prepare-java (2s)
    ✔  nx run challenge-config-service:prepare-java (2s)
    ✔  nx run challenge-core-service:prepare-java (2s)
    ✔  nx run challenge-service-registry:prepare-java (2s)
    ✔  nx run challenge-user-service:prepare-java (3s)
    ✔  nx run shared-java-challenge-util:prepare-java (2s)

 —————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————

 >  NX   Successfully ran target prepare-java for 7 projects (17s)
 
   See Nx Cloud run details at https://nx.app/runs/twmkX9NoxZH

Done in 17.97s.

This operation could be faster using Nx cache. How big is the folder that contains the Maven dependencies?

$ du -h --max-depth=0 ~/.m2/
411M    /home/vscode/.m2/

But it would actually be a bad idea to cache an output folder shared by multiple Nx projects, so let's not do that.

[tinesoft]

@tinesoft I looked into another plugin for Nx and Spring Boot called @jnxplus/nx-boot-maven. One approach they are taking is to install the Maven of Gradle wrapper in the workspace folder and then have projects use it. This approach has the advantage of avoiding duplicated code, though in some cases the isolation that comes with being able to use different Maven wrapper in different projects may be more beneficial. Is it currently possible to configure @nxrocks/nx-spring-boot to look for the Maven wrapper inside a specified folder instead?

To answer your question, right now, this is not possible with my plugin, as the wrapper (maven or gradle), comes from what Spring Initializr generates.
What would be the interest of having a common wrapper in the workspace ? (specially for your concurrency problem)
Besides, what if one project in the workspace want to use Maven wrapper, and the other Gradle?
I think we'll loose flexibility in most cases...

[tschaffter]

To answer your question, right now, this is not possible with my plugin, as the wrapper (maven or gradle), comes from what Spring Initializr generates.

That's good to know. I think that these files should stay.

Here are some elements that are on top of my head:

• For info, I started to explore using Gradle to benefit from more flexible and readable build file compared to Maven and faster task execution (build, test, etc.). For these reasons, it seems that I'm going to convert my projects so that they use Gradle build tools. I'm still figuring out whether VS Code provide a satisfying Gradle integration.
• Back to my question, the main benefit would be centralizing Maven/Gradle settings in the workspace folder. This is one of the benefits of using multi-project Gradle builds. However, I'm not sure how the multi-project Gradle build would work within an Nx workspace where Nx is responsible for executing the tasks.

About the wrapper specifically, I'm fine with it being shipped with each project folder.