IntelliJ imports all libraries as provided dependencies

[rburgst]

I have created a simple test application with lazybones (just as described in the tutorial).

When I then import the project into IntelliJ by opening the build.grade file, then most of the dependencies have the provided scope.

If you then try to launch the application (by running Launcher.main()) you get

Exception in thread "main" java.lang.NoClassDefFoundError: groovy/lang/GroovyObject
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:122)
Caused by: java.lang.ClassNotFoundException: groovy.lang.GroovyObject
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

Steps to replicate:

1. create the project

    lazybones create griffon-javafx-groovy griffon-test
   

2. import the generated project into intellij by choosing File->Open and select the generated build.gradefile.

[rburgst]

if I try to import the pom.xml IntelliJ does not recognise the src/main/groovy and most of the resources folders. So I have to manually mark most of the folders as source/resource folders.

[rburgst]

When running the gradle idea task from the command line in the hope of getting a proper IntelliJ project then I have the same problem as importing the build.gradle. i.e. most of the dependencies are marked as provided.

[swalton00]

rather than running the "lauchermain", use the Gradle "run" task. You can
invoke this from the IntelliJ Gradle view, or from the the command line,
with "gradlew run".

What version of IntelliJ and what version of Java are you running?
Community Edition or full version? What Operating System?

The error message you have provided indicates that it is not finding
Groovy. If you just try to run the Java launchermain class that is what I
would expect. Make sure you either use the Maven -Prun, or the Gradle run.
Either or those are successful with the sample you are running. Then use
the IntelliJ gradle run task. (Use IntelliJ View, Tool Window, Gradle to
show the the Gradle view. -- you can double click on that to run it).

Scott Walton

On Sun, Dec 27, 2015 at 2:29 AM, rburgst notifications@github.com wrote:

I have created a simple test application with lazybones (just as described
in the tutorial)

...

[rburgst]

Hi, using gradlew run will make it difficult to do debugging and hot swapping.
In addition this will still prevent one from using many of the built in features such as test runners etc. If I have to run everything through gradle, then half of the benefit of the IDE is gone.

I am using IntelliJ Ultimate 14.1.6 on Mac OSX El Capitan.

[aalmiray]

This appears to be a systemic problem found in Gradle's IntelliJ plugin. I can't tell for sure if IntelliJ relies completely on it to import a Gradle project. There's nothing that we can do on the Griffon side to fix it unless the IntelliJ Gradle plugin exposes a hook to tweak dependencies.

workaround: manually update the generated files by defining the right scopes. You can do this too within IntelliJ using the project dependencies panel.

[rburgst]

did that but found to do the pom.xml route more convenient (there, I only need to tweak the few missing source and resource folders).

[aalmiray]

great. Are those missing directories undefined? I thought IntelliJ would pick them up as the build-helper plugin defines them.

[swalton00]

Running with IntelliJ Ultimate 15.0.2 on Windows, I do have a couple of
steps I need to go through to get it all working right.

If I first open the Gradle tool window, immediately after opening the new
project, nothing shows for Gradle tasks. Then, when I open the build.gradle
in IntelliJ, it prompts for something like "adding source directories can
....." When I click "yes" it proceeds to do a Gradle build. After a period
of time (after it downloads all the dependencies), the tasks show up in the
Gradle tool window. NOW I can run the gradle tasks by double clicking on
one (or add a Gradle task from the Edit Configurations")

You may find, when you change the dependencies in the build.gradle, you
need to click the "refresh" icon in the upper left of the Gradle tool
wiindow. This will tell IntelliJ about the new files (so they no longer
show up in red in the edit window. There are several Griffon files though
that will ALWAYS show up in red - you can ignore those.

Scott Walton

[swalton00]

I typically use Gradle, so when I import the generated pom.xml into
IntelliJ, it prompted me for "import unlinked Gradle project" and did all
the required Gradle imports. Since typically use Gradle, I've turned off
the corresponding Maven prompts. I added a new Maven target to "Edit
Configurations" -- the command line as: "-Prun" and run it successfully (no
errors encountered). Then set it to debug and successfully stopped at the
Griffon controller incrementing the clickCount variable.

I suspect that there's a step in IntelliJ you need to complete to get the
proper Gradle imported.

Scott Walton

[rburgst]

the problem is not getting the gradle build to import, it doesn't properly parse all dependencies and imports them with the wrong scope. this prevents the app from properly running when running them with the native IntelliJ runners. More importantly it prevents you from using the builtin IntelliJ test functionality. Running everything through the gradle jobs is possible but you are missing out on most of the benefits of the IDE.

[swalton00]

If you use the IntelliJ gradle view to run the tasks they all work (for me
at least), I can add a new (gradle) task, and either run it or debug it. If
I debug it, it successfully stops at every breakpoint.

It could be IntelliJ 14 vs 15, but I used 14 that way for quite some time
and never had a problem. I've tried several ways and can't get it to
fail.This could also be OS related. Or it could be the way you are doing
something. How can best determine what it really is?

I do see that you mention "hot swapping" and that is something I've never
seen working in this kind of an environment. I wouldn't expect it work.
Grails jumps through several hoops to get it to work, and it works mostly
because the code runs and ends before you start it again. That doesn't
apply to this environment.

Scott Walton

[stenis999]

I found this quite annoying, since a work-around has to be applied for all team members, as well as on all computers I work. If the project needs to be reimported, the work-around also has to be reapplied.

We have a different work-around that doesn't require redoing this "all the time". It does require a bit more initial work, but when done it works all the time and for everyone.

To achieve this, we create a multiproject gradle build and change the griffon project to a subproject. This requires some adjustments to the generated griffon project.

When that is working, we add a new 'launcher' subproject, that depends on the griffon project. Within these we add a simple launcher class for the application. This automatically get the correct classpath and can thus be executed from IntelliJ IDEA, giving you all the expected IDE benefits.

[aalmiray]

Turns out the culprit was integration-test.gradle and/or functional-test.gradle as they marked their configuration as part of Idea's PROVIDED scope instead of TEST. This added all transitive dependencies into the provided scope as noted by the reporter.