Transitive module dependences not matching dependencies in POM

[g-tom]

With 4278cc1 (#299), jakarta.security requires transitive jakarta.servlet, jakarta.security.auth.message and jakarta.json. While the Maven artifact providing jakarta.json (jakarta.json:jakarta.json-api) has <scope>compile</scope>, the artifacts providing the two other modules (jakarta.servlet:jakarta.servlet-api, jakarta.authentication:jakarta.authentication-api) have <scope>provided</scope>.

The latter therefore are not transitive dependencies of a Maven project with dependency jakarta.security.enterprise:jakarta.security.enterprise-api (see table in Maven docs).

As a consequence, if the Maven project defines a module which requires jakarta.security, it has implicit dependences on jakarta.servlet, jakarta.security.auth.message and jakarta.json, but only jakarta.json is provided by a transitive dependency.

Therefore, the build fails with e.g. "module not found: jakarta.security.auth.message", if there is no direct dependency on jakarta.authentication:jakarta.authentication-api, regardless of whether this dependency is actually used.

Example:
A Maven project with

<dependencies>
  <dependency>
    <groupId>jakarta.servlet</groupId>
    <artifactId>jakarta.servlet-api</artifactId>
    <version>6.1.0</version>
  </dependency>
  <dependency>
    <groupId>jakarta.security.enterprise</groupId>
    <artifactId>jakarta.security.enterprise-api</artifactId>
    <version>4.0.0</version>
  </dependency>
</dependencies>

provides all necessary classes for e.g.

public class TestAuthentication implements HttpAuthenticationMechanism {
    @Override
    public AuthenticationStatus validateRequest(
        HttpServletRequest httpRequest,
        HttpServletResponse httpResponse,
        HttpMessageContext ctx
    ) throws AuthenticationException {
        return ctx.doNothing();
    }
}

If this is packaged into a module

module test {
  requires jakarta.security;
  requires jakarta.servlet;
}

building fails as described above.

As a work-around, an unused dependency has to be declared:

<dependency>
  <groupId>jakarta.authentication</groupId>
  <artifactId>jakarta.authentication-api</artifactId>
  <version>3.1.0</version>
</dependency>

[g-tom]

@arjantijms,

should this be considered a bug? At least, the need to pull in unused dependencies does seem undesirable to me and it was not necessary with 3.0.0. A possible solution could be to set jakarta.servlet:jakarta.servlet-api and jakarta.authentication:jakarta.authentication-api to <scope>compile</scope>, which would make them transitive dependencies. Nevertheless, they would remain unused, if the API using their types is not used (as it is the case with jakarta.json-api in the example). In case this API is used, it would be best practice to declare direct dependencies, anyhow, and then it should work with neither transitive dependency nor transitive dependence.

Regards,
Tom

[arjantijms]

You're right. The module-info.java declaration itself is correct for the API design (as those types are really used in the API), but it's inconsistent with the maven pom now.

Thinking of it, CDI may need to be requires transitive too, as it's used in the API as well (we use Literal extends AnnotationLiteral).

[g-tom]

The module-info.java declaration itself is correct for the API design (as those types are really used in the API)

But has anything not been working without the requires transitive? I think, in a project which depends on jakarta.security.enterprise-api, those types are only loaded if the respective API is actually used.

[arjantijms]

I think, in a project which depends on jakarta.security.enterprise-api, those types are only loaded if the respective API is actually used.

For a modular project, I don't think the JPMS actually defines a dynamic "being used". The rules are simpler; if a type X appears in the public API surface of a module M (in a type B exported by module M), then a "requires transitive" is needed for the module exporting type X.

See also: https://dev.java/learn/modules/implied-readability/

Maven obviously has to match that indeed, which is a bug in the API.