Compile and test with java 11 and jupiter

[regrog (Andrea)]

I’m trying to compile and build an example project in eclipse:
java 11
gradle 5.6.3
junit-jupiter 5.5.2
eclipse 2019-09 R (4.13.0)

This is my test project:
test-jupiter-jdk11.zip (57.9 KB)
running gradlew build I get this error:

test-jupiter-jdk11/src/main/java/module-info.java:4: error: module not found: org.junit.jupiter.api
        requires org.junit.jupiter.api;

Adding this:

ext.moduleName = “aaa”

afterEvaluate {
repositories {
jcenter()
}

   compileJava {
        inputs.property("moduleName", moduleName)
        doFirst {
            options.compilerArgs = [
                '--module-path', classpath.asPath,
            ]
            classpath = files()
        }
    }

    compileTestJava {
        inputs.property("moduleName", moduleName)
        doFirst {
            options.compilerArgs = [
                '--module-path', classpath.asPath,
                '--add-modules', 'junit',
                '--add-reads', "$moduleName=junit",
                '--patch-module', "$moduleName=" + files(sourceSets.test.java.srcDirs).asPath,
            ]
            classpath = files()
        }
    }

    test {
        inputs.property("moduleName", moduleName)
        doFirst {
            jvmArgs = [
                '--module-path', classpath.asPath,
                '--add-modules', 'ALL-MODULE-PATH',
                '--add-reads', "$moduleName=junit",
                '--patch-module', "$moduleName=" + files(sourceSets.test.java.outputDir).asPath,
            ]
            classpath = files()
        }
    }
}

The error is still there
I can’t figure out how to fix this problem…

[lingocoder]

@regrog

I can’t figure out how to fix this problem…

Hey @regrog,

I was able to fix that problem and get your project working by simply applying the mrJar plugin to it…

You can see in the screencast that I’ve removed the eclipse{} block you originally had. The mrJar plugin has an Eclipse Modulefication feature that does away with the noisiness of that block.

You also don’t need to require the JUnit 5 module in your module-info with mrJar in the mix. So that’s gone too.

Here’s the mrJar-ified project if you’re interested.

You might occassionally need to do a Right-click — Gradle — Refresh Gradle Project after you make certain changes in your project as you’re working in it. Let me know if I can answer any questions for you about the usage of mrJar . Or this usage page might be useful. TIA

[lingocoder]

@regrog

„…The error is still there“…

Hey there @regrog?

Any luck?

[regrog (Andrea)]

Yeah, sorry for the delay, too many things to do.
Your plugin seems to work, I’m only not sure why are you changing default eclipse bin folder with build folder.
I don’t know if it’s a good idea or not mixing them while working with eclipse, isn’t that going into conflict?

[lingocoder]

@regrog

„…Your plugin seems to work…“

Awesome @regrog! Sincere thanks for the feedback I’m relieved it didn’t break on you. Heh-heh.

@regrog

„…I’m only not sure why are you changing default eclipse bin folder with build folder…“

I did that primarily because ${projectDir}/build/classes... is a Gradle convention for the output folder. And since mrJar is a Gradle plugin, it makes sense to me to follow that convention.

@regrog

„…*I don’t know if it’s a good idea or not mixing them while working with eclipse, isn’t that going into conflict?“

The Gradle convention thing is the primary reason I went for build/.... But secondarily, it’s just a habit I’ve developed over a lot of years of using Eclipse. I just always nuke bin as usually the first thing I do whenever I create a new Eclipse/vscode project. And replace it with either target/classes or build/classes. Depending on which builder I’m using.

I’ve done it forever and it’s never caused my Eclipse/vscode projects any problems.

[lingocoder]

@regrog

„…isn’t that going into conflict?…“

Here are some other things, @regrog, that convince me there is no risk of conflict:

• Eclipse provides the ability to change the „default“ source and output folders — i.e. to make your own custom default; that is: something other than src and bin
  • permanently — on a workspace-wide basis
  • and/or temporarily — on a project-specific basis
• Eclipse devs probably wouldn’t allow the GUI to change the default source and output folders if changing them could potentially cause conflicts
• The values set as „defaults“ in most software are ordinarily never mandatory values

So, all of these laborious steps I’m doing here manually in the Eclipse GUI…

…have the exact same effect that the mrJar plugin has. The only difference is that the plugin changes the defaults programatically versus manually. Notice in the screencast that Eclipse’s Problems view shows 0 items?

And too: You now how when Eclipse sometimes takes forever to do stuff? Sometimes that’s because it has to index the files of the project. If you have a Maven project that has both the conventional target/classes and Eclipse’s default bin then it is very likely that there are duplicate files in both locations at any given time. And the more files there are, the longer Eclipse’s indexing takes. So I see that as another reasonable case for doing away with the default bin folder in certain circumstances.

Apologies if that’s belaboring the point. But I figured it would be helpful to share what I’ve learned with you and other users new to Eclipse who might not be aware that the IDE itself provides the ability in the UI to override those defaults.

[regrog (Andrea)]

You gave me a good hint for another topic about build folders in eclipse and gradle. Thanks!
Are you using the eclipse ‘build automatically’ property?

[lingocoder]

@regrog

„You gave me a good hint for another topic about build folders in eclipse and gradle. Thanks!…“

You’re welcome! It’s the least I can do Are you able to share what that other topic is? It sounds interesting!

@regrog

„…Are you using the eclipse ‘build automatically’ property…“

Do you mean in the screencasts? Usually Build automatically is enabled by default in Eclipse. Isn’t it? And I don’t recall explicitly disabling it.

So yeah, I probably am using it in the screencasts actually. Are you asking because of your other topic?

[regrog (Andrea)]

I’m trying to use your plugin in a multi project but I can’t run tests in eclipse. Running tests via Gradle works good.
This is the project example: multiProjectA.zip (62.1 KB)
When I try to run tests in api, eclipse asks for junit 5.
Also, I cant understand if I should put apply plugin: 'com.lingocoder.mrjar' in allprojects or in subprojects.

@lingocoder

You’re welcome! It’s the least I can do Are you able to share what that other topic is? It sounds interesting!

I’ll share the question as soon as I create it, I can’t create a good topic right now.

[lingocoder]

@regrog

„…This is the project example: multiProjectA.zip (62.1 KB)…“

Thanks @regrog. I’ll take a look in a moment. In the meantime, you could take a look at these examples of mrJar being applied in other multi-module projects:

• The mrJar-ified version of the Gradle Guide’s modular Java 9 Storyteller Application
• Paul Bakker’s mrJar-ified gradle-modules-plugin-example
• Multi-module Group-compilation with --module-source-path & JavaFX — uses Composite Builds

You should be able to get an idea from those project’s build.gradles how to setup your project. But I will download your project and see what I can see regarding your problem running tests.

I really appreciate your helping me troubleshoot the plugin, regrog. Much appreciated

[lingocoder]

@regrog

„…eclipse asks for junit 5…“

Yeah, Eclipse takes a — how should I say? — „non-standard“ approach to integrating JUnit in a JPMS-architected project.

Luckily, though, with your example project it was pretty straightforward to apply mrJar and get your tests running correctly:

I’ve uploaded the screencast version of your project here.

Notice in the screencast when I switch to the shell? You need to delete the .classpath file that Eclipse generates on first import. It needs to be deleted because the Eclipse Modulefication feature of mrJar won’t modulefy the project if there is already a .classpath file there. For v0.0.15, that step is necessary.

Having deleted it though, running the :eclipse task is, therefore, also necessary. Running the :eclipse task is the key to mrJar’s Eclipse Modulefibility. You can see the before and after effects in the screencast.

Before it, the project’s dependencies are in the Classpath. After it, the project’s dependencies are in the Modulepath.

NOTE: If you ever do File — Gradle — Refresh Gradle Project at any point after you run the :eclipse task, and IFF things go out of whack, then you might have to re-Moduleificate the project by rerunning the :eclipse task again.

For v0.0.16, I will probably just overwrite .classpath. In the meantime, however, I hope it’s not too much effort to do those two shell commands manually for the time being.

Please, don’t hesitate to get in touch with any other questions, regrog. Thanks again for your feedback. Muy appreciado