What does "Required filename-based automodules detected." warning mean?

Question

In my multi-module project, I created module-info.java only for few modules. And during compilation with maven-compiler-plugin:3.7.0 I'm getting next warning:

[WARNING] * Required filename-based automodules detected. Please don't publish this project to a public artifact repository! *

What does it mean? Is that because I have only a few modules with module-info.java and not the whole project?

I like this question for the fact people care about WARNINGs in their code and even I was puzzled looking at it for the first time. :) — Naman, Sep 30 '17 at 09:14

score 40 · Accepted Answer · edited Apr 05 '21 at 08:34

Automatic module recap

An explicit module (i.e. one with a module-info.java) can only access code of modules that it requires (ignoring implied readability for a moment). That's great if all dependencies are modularized, but what if they are not? How to refer to a JAR that isn't modular?

Automatic modules are the answer: Any JAR that ends up on the module path gets turned into a module. If a JAR contains no module declaration, the module system creates an automatic module with the following properties:

inferred name (this is the important bit here)
reads all other modules
exports all packages

Maven relies on that mechanism and once you create a module-info.jar it places all dependencies on the module path.

Automatic names

There are two ways to infer an automatic module's name:

entry in the manifest
guess from the JAR file name

In the first case, the name was deliberately picked by the maintainer, so it can be assumed to be stable (for example it doesn't change when the project gets modularized). The second one is obviously unstable across the ecosystem - not all project setups lead to the exact same file names of their dependencies.

What does it mean?

The reason for the warnings is that some of your dependencies are automatic modules and do not define their future module name in the manifest. Instead, their name is derived from the file name, which makes them unstable.

Stable names

So why are unstable names such a problem? Assume your library gets published with requires guava and my framework gets published with requires com.google.guava. Now somebody uses your library with my framework and suddenly they need the modules guava and com.google.guava on their module path. There is no painless solution to that problem, so it needs to be prevented!

How? For example by discouraging developers from publishing artifacts that depend on filename-based automatic modules.

"There is no painless solution to that problem"... well, a painless solution actually DID exist. Don't require modules by identity but by capability, e.g. the packages they export. But of course that solution was rejected, leading inevitably to the exact issue you describe. If only somebody had warned them... — Neil Bartlett, Mar 22 '18 at 21:27
Requiring packages instead of modules makes the descriptor as noisy and useless as the imports at the beginning of a class. Chances are, they will even be auto-generated, adding an additional build step on top of providing no value. I'm glad that dependencies are on modules, not packages. — Nicolai Parlog, Mar 23 '18 at 06:44
OSGi has been doing this for 18 years and yes we generate them in the runtime artifact. At build time we use artifact dependencies of course. Funny that you say this provides no value when it solves the exact problem that you described yourself. — Neil Bartlett, Mar 23 '18 at 14:45

Naman · Answer 2 · 2017-10-15T03:37:10.520

4

[WARNING] * Required filename-based automodules detected. Please don't publish this project to a public artifact repository! *

Is that because I have only a few modules with module-info.java and not the whole project?

No, its not because of a few module listed on the module-info.java but generated by the maven-compiler-plugin for all the automatic modules found in the module graph.

What does it mean?

Not to publish the current project is insisted probably since the automatic modules are expected to be converted to named or explicit modules by their owners and then published to repositories which might result in change to their module name as well. Additionally a precautionary point to note here is that according to the progress document of Maven ~> Java+9+-+Jigsaw, they are still not completely ready with the JDK9 compatible plugin versions.

Just to portray an example for such a use case. Think over these lines -

I've published an artifact com-foo-bar:1.0.0-SNAPSHOT:jar.
Another project of mine com-xyz:1.0.0 depends on it.
Eventually a project of yours relies on com-foo-bar transitively via com-xyz
You plan to modularize your code and make use of something like
```
module your.module {
    requires com.foo.bar;
    requires com.xyz;
}
```
(you need to specify the transitive dependencies in the module declarations separately)
All worked fine, but until the time I decided to modularize my libraries.
Now, the first thing I did was name my modules!
And I did something fantastic to explicitly call out my efforts like this:-
```
module modular.com.foo.bar {}
```
I end up breaking the code of any dependent library and eventually any that depends on yours in a modularized way.

Note: I agree over not practicing to use SNAPSHOTs in production, but there could be cases when eventually you rely on an artifact which is still in development phase.

Edit: From the comments by @khmarbaise

Its understood that people would wish to publish to artifactories but if they are not aware of the consequences you will be beaten in the future by this.

Maven would like to make it clear that the WARNING in this case is very serious which could have instead been a FAILURE but that would had been a bad user experience to deal with.

The ideal way to deal with this is that the library owners plan to migrate their artifacts to JDK9 and the tree is traversed bottom-up in which case the named/explicit module would be the only aspect prevailing without the need of the automatic module names and such warnings.

edited Oct 15 '17 at 03:37

answered Sep 30 '17 at 09:04

Naman

27,789
26
218
353

Maybe I misunderstand a thing but the message means that a module in the build has not defined explicitly the name of it's own which means the name will be assumes based on the automatic modules which in consequence means never publish this to something public nor use it like this cause as you correctly described the name based on automatic module name will likely change which will result in very bad things...this has no relationship to the Maven plugins? – khmarbaise Sep 30 '17 at 11:34
@khmarbaise *this has no relationship to the Maven plugins?*.. if thats the question to me. It does have relation to the compiler plugin which checks if the module name is same as the module's source file name(checking if its based onthe automatic module name), right? Or may be I am not getting exactly what you meant there. – Naman Sep 30 '17 at 11:38
The point is the original libs have not yet defined a `module-info.java` which means we fall back to automatic-module name...which is bad. This can only being changed by the library authors? – khmarbaise Sep 30 '17 at 11:58
@khmarbaise Agree to that the absence of module-info.class fallbacks to using the module as an automatic module and the library authors should define these and also the WARNING is justified in that case. Just that people would still like to push to artifactories using the automatic modules from their dependencies. – Naman Sep 30 '17 at 12:03
1

I understand the wish to publish to artifactories but if you are not aware of the consequences you will be beaten in the future by this. – khmarbaise Sep 30 '17 at 12:14
@khmarbaise Agreed and thats why I second the thought behind WARNING such usage. I am aligned to this anyway :) I hope my answer doesn't sound against it? – Naman Sep 30 '17 at 12:15
1

No sorry don't get this wrong...I would like to make it clear that the WARNING in this case is very serious ...maybe this should be failure but that would be not understandable for the most Maven users..;-(...Apart from that the list on the wiki page might not be up-to-date...I need to recheck the site... – khmarbaise Sep 30 '17 at 12:28
@khmarbaise Indeed waiting for that page to be udpated. As it has been serving to be an enpoint ever since [this answer](https://stackoverflow.com/a/36584317/1746118). And I would just udpate the answer with context from your comments. Thanks :) – Naman Sep 30 '17 at 12:31
1

@nullpointer Is there any way to get maven to tell me, which dependency actually causes the warning? I ran maven with --debug, and instead of giving me _more_ information about the warning the warning disappeared altogether. – soc Jul 17 '18 at 20:30
@soc Well, one would anyway be aware of the modules that it's using in the module descriptor. You would be a better person to know what exactly is the module that you've used as an automatic module without an explicit manifest declaration. – Naman Jul 18 '18 at 06:30

score -1 · Answer 3 · answered Apr 19 '18 at 05:59

-1

With the maven-compiler-plugin v3.7.0 it's an informational message. Not sure why you see it as a warning...

Here's what I get when I build my Java 10 based project with a module-info.java:

[INFO] Required filename-based automodules detected. Please don't publish this project to a public artifact repository!

answered Apr 19 '18 at 05:59

testphreak

489
5
16

1

I see it as WARNING (`maven-compiler-plugin` version `3.8.1` using Java 11). – Wim Deblauwe Sep 09 '19 at 07:29

What does "Required filename-based automodules detected." warning mean?

3 Answers3

Automatic module recap

Automatic names

Stable names

Linked