Ah, finally got past this bug to release by just backing out the one change in my POM that I’d dismissed as irrelevant. I had entered this code in the problematic module’s POM to work around a bug failing modular builds without an intervening clean:
<!-- Work around https://github.com/sormuras/junit-platform-maven-plugin/issues/94 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-clean-plugin</artifactId> <executions> <execution> <id>auto-clean</id> <goals> <goal>clean</goal> </goals> <phase>initialize</phase> </execution> </executions> </plugin> While that effectively added a “clean” at the start of the build it appears to have also triggered the behavior described in the thread below. I still think there’s a bug in AbstractJavadocMojo in the if/else looking for a module descriptor, which fails to look for the module descriptor in the case that an output directory exists but a jar does not. Workaround if you’re not using junit-platform-maven-plugin is to add a package or install (or possibly site?) prior to the goal you’re trying to use. From: "Daniel B. Widdis" <wid...@gmail.com> Date: Sunday, October 16, 2022 at 10:04 PM To: Maven Users List <users@maven.apache.org> Subject: Re: m-javadoc-plugin with JPMS It's amusing when you come upon an error, google the error message, and find an email thread you participated in and forgot about. Resurrecting this thread from last July and hoping for some insight. I last released my project using maven-release-plugin on July 20, 2022 with no issues. My project setup includes a parent pom and modules - one module builds with compatibility for Java 8 and has automatic-module-name - another module builds - another module contains only the src/main/java/module-info.java file, and uses the maven-resources-plugin to add source and resource paths to the other module's source tree - I have made no significant changes to my POM since the previous release, and it works just fine for test, verify, deploy goals, but breaks on maven release:perform with the message cited earlier in this thread: [ERROR] Creating an aggregated report for both named and unnamed modules is not possible. [ERROR] Ensure that every module has a module descriptor or is a jar with a MANIFEST.MF containing an Automatic-Module-Name. [ERROR] Fix the following projects: [ERROR] - com.github.oshi:oshi-core-java11 The error message is not helpful, as that module descriptor IS in that module. I can reproduce the error on the commandline by running mvn javadoc:jar. I can work around it by running mvn package javadoc:jar. However, attempting to add the package goal to the maven release plugin does not fix the problem. I have tried adding an automatic module name in addition to the module descriptor. Same problem. I have tried changing the lifecycle phase during which these javadoc goals are executed. Same problem. I have tried adding "dummy" class files in the problematic module's source tree just in case the solo file and lack of support for the added source files is an issue. Same problem. I have traced the error down to the following code: The log error message is generated in AbstractJavadocMogo line 5085 when the unnamedProjects list is not empty. https://github.com/apache/maven-javadoc-plugin/blob/8b589325762280cef9ff8df2bc3431d4fccafbc7/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5087-L5094 That occurs when the conditional on line 5046 (result not null and getModuleDescriptor not null) fails. https://github.com/apache/maven-javadoc-plugin/blob/8b589325762280cef9ff8df2bc3431d4fccafbc7/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5046 The result variable checks two sources. First, it looks for a jar with getClassesFile() if it exists, and selects the automatic module name from it. Even if result fails here, it does not bother to check for a descriptor elsewhere due to the if/else. https://github.com/apache/maven-javadoc-plugin/blob/8b589325762280cef9ff8df2bc3431d4fccafbc7/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5003 Tracing through getClasses() it eventually returns the output directory if it's not null, so in the case there's no jar in the output directory, I think this fails and never gets to the "else" case (findMainDescriptor()) where it actually looks for module-info.java https://github.com/apache/maven-javadoc-plugin/blob/8b589325762280cef9ff8df2bc3431d4fccafbc7/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5031 I believe this may be the bug reported earlier in this thread by Maxim Solodovnik, and may be the reason performing "package" first works as a workaround. However, I attempted to add an automatic module name (in addition to adding the package goal for the release) and still got this problem so this may not be the only issue. Hopefully these hints can help someone try to get to the source of this bug... On Sun, Aug 28, 2022 at 10:25 PM Maxim Solodovnik <solomax...@gmail.com> wrote: maven-javadoc-plugin:3.4.1 - same error :((( On Wed, 20 Jul 2022 at 22:19, Maxim Solodovnik <solomax...@gmail.com> wrote: > > done, > > same error :( > > On Wed, 20 Jul 2022 at 22:13, Maxim Solodovnik <solomax...@gmail.com> wrote: > > > > well, > > > > m-javadoc-plugin is being called at `*db` module only which is only > > depends on `*util` module > > both has `module-info.java` > > > > let me add `module-info.java` to all modules (not sure why) so we can > > ensure this is not a problem :) > > > > On Wed, 20 Jul 2022 at 21:51, Daniel Widdis <wid...@gmail.com> wrote: > > > > > > Some modules have module-info.java and some don’t. That’s exactly what > > > the error says. > > > > > > > On Jul 20, 2022, at 7:24 AM, Maxim Solodovnik <solomax...@gmail.com> > > > > wrote: > > > > > > > > On Tue, 19 Jul 2022 at 17:20, Olivier Lamy <ol...@apache.org> wrote: > > > >> > > > >>> On Tue, 19 Jul 2022 at 16:42, Maxim Solodovnik <solomax...@gmail.com> > > > >>> wrote: > > > >>> > > > >>> On Tue, 19 Jul 2022 at 13:16, Daniel Widdis <wid...@gmail.com> wrote: > > > >>>> > > > >>>>> The only problem of having both is redundancy :) > > > >>>> > > > >>>> Technically speaking, you always have an automatic module name even > > > >>>> if > > > >>> you don't explicitly name it. It will use your jar filename to deduce > > > >>> one. Unless you use a reserved word in your jar, and then the world > > > >>> breaks. __ > > > >>> > > > >>> I thought maybe this is the issue in m-javadoc-plugin: it is weird to > > > >>> check `automatic module name` in manifest if module-info.java present > > > >>> > > > >> > > > >> Sounds possibly a bug. > > > >> Do you have an easy project to reproduce you could provide? > > > >> > > > > > > > > sorry for delay :) > > > > here is very simple example project: > > > > https://github.com/solomax/multimodule-with-war > > > > > > > >> > > > >> > > > >>> > > > >>> > > > >>>> > > > >>>> On 7/18/22, 11:07 PM, "Maxim Solodovnik" <solomax...@gmail.com> > > > >>>> wrote: > > > >>>> > > > >>>> Thanks for the answer Daniel :) > > > >>>> > > > >>>> On Tue, 19 Jul 2022 at 13:03, Daniel Widdis <wid...@gmail.com> > > > >>> wrote: > > > >>>>> > > > >>>>> I think you're asking on the right list. And it's not a "basic" > > > >>> question but it isn't an obvious answer either. > > > >>>>> > > > >>>>> I'm not sure your question has enough detail for anyone to deduce > > > >>> the answer. Linking to your project may help you get more attention > > > >>> on it. > > > >>>>> > > > >>>>> FWIW, I have both an automatic module name and module-info in my > > > >>> modular projects and it doesn't cause any problems, but that's > > > >>> clearly not > > > >>> your problem. > > > >>>> > > > >>>> The only problem of having both is redundancy :) > > > >>>> (and they should be in-sync) > > > >>>> > > > >>>> everything works as expected in case `Automatic-Module-Name` is in > > > >>> manifest > > > >>>> > > > >>>> I'll try to create simple project to illustrate the problem :) > > > >>>> > > > >>>>> > > > >>>>> On 7/18/22, 10:55 PM, "Maxim Solodovnik" <solomax...@gmail.com> > > > >>> wrote: > > > >>>>> > > > >>>>> Hello, > > > >>>>> > > > >>>>> Is the question too basic? > > > >>>>> Or maybe I'm asking wrong list? :) > > > >>>>> > > > >>>>> On Fri, 15 Jul 2022 at 15:41, Maxim Solodovnik < > > > >>> solomax...@gmail.com> wrote: > > > >>>>>> > > > >>>>>> Hello All, > > > >>>>>> > > > >>>>>> I'm trying to migrate our project to JPMS > > > >>>>>> After adding module-info.java to my modules (and removing > > > >>> explicitly > > > >>>>>> set `Automatic-Module-Name`) > > > >>>>>> I'm getting: > > > >>>>>> > > > >>>>>> [INFO] --- maven-javadoc-plugin:3.4.0:javadoc-no-fork > > > >>> (default) > > > >>>>>> [ERROR] Creating an aggregated report for both named and > > > >>> unnamed > > > >>>>>> modules is not possible. > > > >>>>>> [ERROR] Ensure that every module has a module descriptor or > > > >>> is a jar > > > >>>>>> with a MANIFEST.MF containing an Automatic-Module-Name. > > > >>>>>> > > > >>>>>> I thought `Automatic-Module-Name` should be added only if > > > >>>>>> `module-info.java` is missing > > > >>>>>> Is it bug in maven-javadoc-plugin or maybe I'm doing > > > >>> something wrong? :) > > > >>>>>> > > > >>>>>> java 17 > > > >>>>>> Apache Maven 3.8.5 > > > >>>>>> > > > >>>>>> -- > > > >>>>>> Best regards, > > > >>>>>> Maxim > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> -- > > > >>>>> Best regards, > > > >>>>> Maxim > > > >>>>> > > > >>>>> > > > >>> --------------------------------------------------------------------- > > > >>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > >>>>> For additional commands, e-mail: users-h...@maven.apache.org > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>> --------------------------------------------------------------------- > > > >>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > >>>>> For additional commands, e-mail: users-h...@maven.apache.org > > > >>>>> > > > >>>> > > > >>>> > > > >>>> -- > > > >>>> Best regards, > > > >>>> Maxim > > > >>>> > > > >>>> > > > >>>> --------------------------------------------------------------------- > > > >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > >>>> For additional commands, e-mail: users-h...@maven.apache.org > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> --------------------------------------------------------------------- > > > >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > >>>> For additional commands, e-mail: users-h...@maven.apache.org > > > >>>> > > > >>> > > > >>> > > > >>> -- > > > >>> Best regards, > > > >>> Maxim > > > >>> > > > >>> --------------------------------------------------------------------- > > > >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > >>> For additional commands, e-mail: users-h...@maven.apache.org > > > >>> > > > >>> > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Maxim > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > -- > > Best regards, > > Maxim > > > > -- > Best regards, > Maxim -- Best regards, Maxim --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Dan Widdis
