JPMS

[xenoterracide]

Is your feature request related to a problem? Please describe.

java module (module-info) should agree with the gradle dependencies, for example compileOnlyApi should generally match requires static transitive

I suspect this is a bidirectional thing though. For example if I have exports com.myorg.foo but do not have exports com.myorg.foo.internal then even if something that would normally be detected as api should not be api.

if possible, opens... to specifications should possibly be determined, I suspect this would require looking at tests though.

I hope this is clearer than mud.

cc: @jjohannes you might be interested in this issue, or have ideas/suggestions

[Vampire]

At least the dependency consistency check would really be helpful, so that
implementation => requires
api => requires transitive
compileOnly => requires static
compileOnlyApi => requires static transitive

Not sure about runtimeOnly, but they might need to be absent in module-info.

[xenoterracide]

AFAIK runtime only dependencies should be excluded from module-info.

There's one exception to things being added to module-info that I've found though. java jdk namespaced modules may need to be listed in a module-info even if no direct abi dependency exists. This is because automatic modules can access everything and do not define which modules they require (static or otherwise). I've run into spring boot issues where I needed to add java.sql to my dependencies. I also ran into a spring boot triggered issue where it tried to load mockito even though I wasn't using it at all, just because it was on the classpath, and that triggered a mockito bug where it requires jdk.agent. So essentially any false positives on java/jdk should be ignored.

[autonomousapps]

Thanks for the issue. I'm not entirely clear on what the request is. What does this plugin do now, and what should it do differently? The issue title is also just a noun ("JPMS"), when a sentence with a verb would clarify things for me.

[Vampire]

Currently, the plugin validates dependencies declared in build logic.

In the module-info.class you also declare dependencies, usually the same ones as in the build logic.

It can easily happen that the scopes you use in both places differ.

It would be great if the plugin could also verify the dependencies in the module-info.class and advice on changes to be consistent to what is declared in the build logic. Otherwise one might just use requires for all dependencies which then is like using implementation for all dependencies.

That's what I hope for to get from this issue. Caleb described some further things, I just am not sure how helpful those would be. :-)

[Vampire]

Additionally to external dependencies, it would of course be awesome to get advice which JRE modules are needed in which scopes too.

[xenoterracide]

also this is creating false positives

Advice for :commons-jpa
Unused dependencies which should be removed:
  testImplementation(libs.jspecify)
  whiteboxImplementation(libs.jspecify)

but in module-info, I need it to at least compile the module

import org.jspecify.annotations.NullMarked;

@NullMarked module com.xenoterracide.commons.jpa.test {
  opens com.xenoterracide.commons.jpa.test
    to org.junit.platform.commons, org.hibernate.orm.core, net.bytebuddy, spring.core;
  opens com.xenoterracide.commons.jpa.test.transaction
    to org.junit.platform.commons, org.hibernate.orm.core, net.bytebuddy, spring.core;
  requires org.assertj.core;
  requires com.xenoterracide.commons.jpa;
  requires org.junit.jupiter.api;
  requires org.junit.jupiter.params;
  requires spring.beans;
  requires spring.boot.test;
  requires spring.tx;
  requires org.hibernate.orm.envers;
  requires org.apache.commons.lang3;
  requires com.xenoterracide.jpa.fixtures;
  requires spring.test;
  requires spring.boot.test.autoconfigure;
  requires spring.orm;
  requires org.jspecify;
}

what information is still needed? note: your verb is probably support. Currently JPMS isn't looked at, used, or included as part of the analysis.

[autonomousapps]

Essentially all of my work is in a Kotlin environment, where JPMS is not used, therefore I have limited experience with that. I'm happy to attempt to support it here, but I'm going to need some help to understand the requirements.

One thing that might help me is to describe, in natural language, what the spec is. You could write pseudocode Specifications (to use Spock lingo) that demonstrate various situations that can occur and what you'd expect DAGP's advice to be. Or if you're comfortable with how DAGP's test suite works, you could write actual failing specs. Let me know how I can help.