[MJMOD-8] NullPointerException on create

[andretadeu]

Hi,

I created this pull request to fulfill to address the need to set --class-path parameter from jmod create, because it offers the possibility to create a JMOD artifact from a JAR created in another project, in a Maven multi-module context.

Commit comment:

NullPointerException happens when I am trying to create a JMOD from a JAR from another project. The plugin was not setting classPath when it should to run the following command: 'jmod create --class-path '.

Thanks,

André Tadeu de Carvalho

[khmarbaise]

First thanks for your contribution but on the other hand I'm thinking about this use case which looks to me like a different goal in the Plugin instead of having a complex parameter setup ? Can you give examples for use cases here? Complete example projects?

[andretadeu]

Of course, I have two working examples:

The first one I created a multi-module Maven project where I generated both JAR and JMOD files in each project that contains Java source code with module-info.java, which is in https://github.com/andretadeu/maven-jigsaw-examples/tree/master/multi-modules-jmod-jlink. The second project is the same project in the issue, but with fixes, where there is a separated project to generate the JMOD from JAR, which is in https://github.com/andretadeu/npe-on-alpha-2.

Thinking about the approach of each module generating only one artifact, the second example seems more suitable, in my humble view. What do you think of these examples?

[andretadeu]

Hi @khmarbaise ,

I am sorry! I forgot the integration test to explain how to reproduce the error correctly and to assert that the fix address this issue.

Thanks,

[rfscholte]

There should be no need for this classpath entry. about-cli-app is a dependency, so will be available as a pathElement.

[andretadeu]

I think I made one mistake here: I should be filling pathElement. In JModCreateMojo:

else if ( classPath == null || classPath.trim().isEmpty() )
        {
            throw new MojoExecutionException( "You must either have a module in your project or the "
                    + "'classPath' configuration set in 'maven-jmod-plugin' configuration section." );
        }

I'll review this part and, in this case, I owe a better solution for this.

[andretadeu]

I can replace this classPath entry with project.dependencyArtifacts. In the test case provided, pathElement is null because this Maven project just get a modular JAR and create a JMOD file from it. What ssems reasonable to do in this case is to fill classPath with project.dependencyArtifacts.

[rfscholte]

You should be able to detect if there are classpath elements by looping over all the pathElements.

[andretadeu]

Just one observation here: jmod create can receive both --module-path and --class-path. In this case, I think it is a better solution is to segregate JMOD artifacts and modular JARs from non-modular JARs. Fixing the previous explanation: --class-path must contain the artifact(s) or the folder(s) that should be inside JMOD file, i.e., you would expect that one modular JAR or target/classes folder would be enough. --module-path are the folders or files containing Java modules neede to compile. It's not clear how it should be used with jmod. In all examples I have, it is not used.

I am using Java 9 Modularity book and the official Oracle documentation for references.

[andretadeu]

@rfscholte Another proposal for this bug fix.

[rfscholte]

The original code needs a clean up. It clearly shows to me that this was written while trying to understand the modular system based on code from other plugins.
My suggestion: squash your commits, so we have at least a working IT. After that I'll clean up the code.

[andretadeu]

My suggestion: squash your commits, so we have at least a working IT. After that I'll clean up the code.

Done. I look forward to see the final solution. Thank you for all the help!

[rfscholte]

Did you try to use the generated jmod? I would expect it to fail because it is missing picocli. IIUC --classpath will simply use the resources from these dirctories and jarfiles. After refactoring the project this IT fails with Error: java.util.zip.ZipException: duplicate entry: classes/META-INF/MANIFEST.MF because picocli ended up on the classpath too.

[andretadeu]

I tested before of my refactoring and I didn't test it because I was expecting to maintain the behavior, since I was just replacing the origin of the information to fill classPath. I'll test again. However, I've discover another thing about --module-path (please check: https://github.com/java-modularity-examples/jigsaw-examples, example 10-exploring-jmod). We shouldn't be using --module-path, unless we want to setup a module that requires this module we are packing to add a hash on it, requiring the --hash-module parameter.

[andretadeu]

Did you try to use the generated jmod? I would expect it to fail because it is missing picocli. IIUC --classpath will simply use the resources from these dirctories and jarfiles.

I'll double check it. Check any number of times if needed.

[andretadeu]

I tested now with Java 9, 10, and 11, and Maven 3.6.0:

I ran the command: mvn clean verify -Prun-its, after that I removed the generated JMOD file, and executed the command:

jmod create --module-version 99.0 \
--class-path /home/andre/workspaces/oss/maven-jmod-plugin/target/it/mjmod-8-generate-jmod-in-other-project/about-cli-app/target/about-cli-app-99.0.jar \
--config /home/andre/workspaces/oss/maven-jmod-plugin/target/it/mjmod-8-generate-jmod-in-other-project/about-cli-distribution-jmod/src/main/configs \
--cmds /home/andre/workspaces/oss/maven-jmod-plugin/target/it/mjmod-8-generate-jmod-in-other-project/about-cli-distribution-jmod/src/main/cmds \
--module-path \
"/home/andre/.sdkman/candidates/java/11.0.1-open/jmods" \
/home/andre/workspaces/oss/maven-jmod-plugin/target/it/mjmod-8-generate-jmod-in-other-project/about-cli-distribution-jmod/target/jmods/about-cli-distribution-jmod.jmod

where the arguments were generated by maven-jmod-plugin and it's in jmodCreateArgs file. From the tests above, I didn't get the error you got. I confess I got this error, but it happened after I had made a mistake in my implementation.

[rfscholte]

I've solved it in the refactor branch
Most important thing you need to change when working with static required modules is to mark them as optional dependencies.
Please review before I'll merge it back to master.

[andretadeu]

Concerning to the question of filling in the --class-path parameter, it looks good to me.

[andretadeu]

It would be nice if you removed the commented out code. Thanks for everything.

[MachineIntelligence6]

Did you try to use the generated jmod? I would expect it to fail because it is missing picocli. IIUC --classpath will simply use the resources from these dirctories and jarfiles. After refactoring the project this IT fails with Error: java.util.zip.ZipException: duplicate entry: classes/META-INF/MANIFEST.MF because picocli ended up on the classpath too.

I'm also getting the above error. This happen when added different jars in my example project.

[jira-importer]

Resolve #66

[jira-importer]

Resolve #66