Re: m-javadoc-plugin with JPMS
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: org.apache.maven.plugins maven-clean-plugin auto-clean clean initialize 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" Date: Sunday, October 16, 2022 at 10:04 PM To: Maven Users List 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 wrote: maven-javadoc-plug
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 wrote: > maven-javadoc-plugin:3.4.1 - same error :((( > > On Wed, 20 Jul 2022 at 22:19, Maxim Solodovnik > wrote: > > > > done, > > > > same error :( > > > > On Wed, 20 Jul 2022 at 22:13, Maxim Solodovnik > 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 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 > 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 > wrote: > > > > > > > > > The only problem of having both is redundancy :) > > > > > > > > Technically speaking, you always have an automatic module name > even if > > > > >>> you don't expl
Re: Windows Installer / MacOS dmg
https://maven.apache.org/plugins/maven-assembly-plugin/usage.html From: Vivek Suraiya Date: Sunday, 16 October 2022 at 11:28 To: users@maven.apache.org Subject: Windows Installer / MacOS dmg I have a Netbeans 15 JavaFX (18.0.2 / JDK 18.0.2) project with several dependencies from the Maven repository. I wish to create a Windows installer and a MacOS dmg including all dependencies and the JRE. Is this possible to do?
Re: Windows Installer / MacOS dmg
Ah nice! Jpackage looks neat as long as you don't need a customisable installer. I accidentally read 18 as 1.8 which is where some of our applications are stuck at the moment... On Sun, 16 Oct 2022, 12:17 Thomas Broyer, wrote: > Doesn't JDK 18 come with jpackage for exactly that use case? Not sure > how/if you can drive it from Maven but you should be able to prepare > everything with dependency:copy-dependencies or the maven-assembly-plugin > and then run jpackage manually to produce the installers. > > Le dim. 16 oct. 2022 à 10:27, Vivek Suraiya .invalid> > a écrit : > > > I have a Netbeans 15 JavaFX (18.0.2 / JDK 18.0.2) project with several > > dependencies from the Maven repository. I wish to create a Windows > > installer and a MacOS dmg including all dependencies and the JRE. Is this > > possible to do? >
Re: Windows Installer / MacOS dmg
Doesn't JDK 18 come with jpackage for exactly that use case? Not sure how/if you can drive it from Maven but you should be able to prepare everything with dependency:copy-dependencies or the maven-assembly-plugin and then run jpackage manually to produce the installers. Le dim. 16 oct. 2022 à 10:27, Vivek Suraiya a écrit : > I have a Netbeans 15 JavaFX (18.0.2 / JDK 18.0.2) project with several > dependencies from the Maven repository. I wish to create a Windows > installer and a MacOS dmg including all dependencies and the JRE. Is this > possible to do?
Re: Windows Installer / MacOS dmg
In our own projects we do this kind of thing... For Windows, you could use either the: 1. IzPack and the izpack-maven-plugin which produces a Jar that can be executed on Windows. IzPack understand Windows/Linux/macOS and can produce a GUI and/or CLI installer that works on all of those platforms: https://izpack.atlassian.net/wiki/spaces/IZPACK/pages/491628/IzPack+Maven+Plugin+Reference 2. NSIS and the nsis-maven-plugin which can produce a standalone .exe installer for Windows - https://github.com/DigitalMediaServer/nsis-maven-plugin For a macOS DMG, you need to take a number of steps: 1. Use AppBundler to produce a macOS app from your Java project. We maintain a maven plugin for that, the appbundler-maven-plugin here - https://github.com/evolvedbinary/appbundler-maven-plugin 2. Produce a DMG from the macOS app using a number of macOS command line tools, we use the Maven Exec plugin for that - you can see examples in one of our projects here - https://github.com/eXist-db/exist/blob/eXist-6.0.1/exist-distribution/pom.xml#L1178 3. You then also have to cope with signing the DMG with an Apple Developer Certificate - we again use macOS command line tools via the Maven Exec plugin - https://github.com/eXist-db/exist/blob/eXist-6.0.1/exist-distribution/pom.xml#L1265 4. You then also have to cope with notarizing the DMG via Apple - we again use macOS command line tools via the Maven Exec plugin - https://github.com/eXist-db/exist/blob/eXist-6.0.1/exist-distribution/pom.xml#L1298 Step (1) can be run on non-macOS systems, and we have Linux alternatives for step (2), but as far as we are aware step (3) and (4) can only be done on a macOS system still. If you wish to include a JRE in your package for macOS the AppBundler has an option for this, see - https://github.com/TheInfiniteKind/appbundler. For Windows, I think you would need to incorporate jlink into your Maven Build process before supplying the resources to IzPack or NSIS. Kind regards. Adam. On Sun, 16 Oct 2022 at 10:27, Vivek Suraiya wrote: > > I have a Netbeans 15 JavaFX (18.0.2 / JDK 18.0.2) project with several > dependencies from the Maven repository. I wish to create a Windows installer > and a MacOS dmg including all dependencies and the JRE. Is this possible to > do? -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Windows Installer / MacOS dmg
I have a Netbeans 15 JavaFX (18.0.2 / JDK 18.0.2) project with several dependencies from the Maven repository. I wish to create a Windows installer and a MacOS dmg including all dependencies and the JRE. Is this possible to do?
