dependsOn(compileKotlinTask)

    if (enableValidation) {
      compileKotlinTask.source(file("src/main/java9"))
    }

    // Ignore warnings about using 'requires transitive' on automatic modules.
    // not needed when compiling with recent JDKs, e.g. 17
    options.compilerArgs.add("-Xlint:-requires-transitive-automatic")

            // Verify modules element was renamed to subprojects - use the updated document from pomMap
            Document updatedDocument = pomMap.get(Paths.get("pom.xml"));
            Editor editor = new Editor(updatedDocument);
            Element root = editor.root();
            assertNull(DomUtils.findChildElement(root, "modules"));

     * There are two circumstances where the dependency may nevertheless be placed somewhere else:
     *
     * <ul>
     *   <li>If {@link #MODULES} path type is also set, then the dependency can be placed either on the
     *       class path or on the module path, but only one of those. The choice is up to the plugin,

  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>org.apache.maven</groupId>
    <artifactId>maven-compat-modules</artifactId>
    <version>4.1.0-SNAPSHOT</version>
  </parent>

  <artifactId>maven-settings-builder</artifactId>

  <name>Maven Settings Builder (deprecated)</name>

Keep class names, function names, modules, file names, and CLI commands unchanged.

### List of English terms and their preferred French translations

     */
    private String deprecated;

    /**
     * Flags this Mojo to run it in a multi-module way, i.e. aggregate the build with the set of projects listed as
     * modules. By default, no need to aggregate the Maven project and its child modules
     */
    private boolean aggregator = false;

    // ----------------------------------------------------------------------
    //

    }

    /**
     * Tests the formatting of an option without module name.
     */
    @Test
    public void testOption() {
        String[] formatted = JavaPathType.MODULES.option(paths());
        assertEquals(2, formatted.length);
        assertEquals("--module-path", formatted[0]);
        assertEquals(toPlatformSpecific("src/foo.java:src/bar.java"), formatted[1]);
    }

    /**

            <tagBase>https://svn.apache.org/repos/asf/maven/components/tags</tagBase>
          </configuration>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
  <modules>
    <module>maven-archiver</module>
    <module>maven-artifact</module>
    <module>maven-artifact-manager</module>
    <module>maven-artifact-ant</module>
    <module>maven-artifact-test</module>

See the okcurl module for an example build.

```shell
$ ./gradlew okcurl:nativeImage
$ ./okcurl/build/graal/okcurl https://httpbin.org/get
```

Java Modules
------------

OkHttp (5.2+) implements Java 9 Modules.

With this in place Java builds should fail if apps attempt to use internal packages.

```
error: package okhttp3.internal.platform is not visible

  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>org.apache.maven</groupId>
    <artifactId>maven-compat-modules</artifactId>
    <version>4.1.0-SNAPSHOT</version>
  </parent>

  <artifactId>maven-plugin-api</artifactId>

  <name>Maven 3 Plugin API</name>