Uploaded image for project: 'Maven Surefire'
  1. Maven Surefire
  2. SUREFIRE-1501

Optional dependencies not correctly handled with JPMS modules

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 2.21.0
    • None
    • Maven Surefire Plugin
    • None
    • Windows 10, Maven v3.5.2

    Description

      Attached is a pointlessly simple project for Java 9. The module-info declares an optional dependency on Google Guava (an automatic module) using requires static. This optionality is reflected in the pom.xml, where the dependency is marked as optional.

      It fails in surefire with JAVA_HOME=jdk9. The reason seems to be that although the Guava jar file is added to the modulepath, it is not referenced using --add-modules. As such, the module graph builder never pulls it in, despite it being on the modulepath. (Optional dependencies need to be directly added using --add-modules if in Maven's dependency graph)

      Adding the --add-modules to the `argLine` parameter solves the problem, but this is a bug because the surefire plugin should handle the situation without manually adding it.

      NOTE! The attachment has the --add-modules manually added to the pom.xml. Remove it to see the bug.

      Attachments

        1. maven-issue1.zip
          4 kB
          Stephen Colebourne

        Activity

          rfscholte Robert Scholte added a comment -

          IIUC the fix should be: all static required modules should result in an extra argument: --add-modules X 

          rfscholte Robert Scholte added a comment - IIUC the fix should be: all static required modules should result in an extra argument: --add-modules X  

          Yes, but only if the Maven dependency tree contains the relevant jar.

          scolebourne@joda.org Stephen Colebourne added a comment - Yes, but only if the Maven dependency tree contains the relevant jar.
          rfscholte Robert Scholte added a comment -

          That should not be an issue, because the used library works the other way around: process every artifact (=file) and decide where it belongs to. 

          Just to be complete: we should only look in the root/main module descriptor for these static required modules, ignore them when descriptor in dependencies also have static required modules. Looks like we need some extra examples to verify this behavior.

          rfscholte Robert Scholte added a comment - That should not be an issue, because the used library works the other way around: process every artifact (=file) and decide where it belongs to.  Just to be complete: we should only look in the root/main module descriptor for these static required modules, ignore them when descriptor in dependencies also have static required modules. Looks like we need some extra examples to verify this behavior.

          People

            Unassigned Unassigned
            scolebourne@joda.org Stephen Colebourne
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated: