More Gradle/GWT/AppEngine/Intelli-J Fun

[Evan Ruff]

Hey guys,

After a ~maddening weekend, I've finally gotten my project(s) converted over to Intelli-J/Gradle. I'm running into a couple of naggy issues that I was hoping someone could help me out with.

To recap, the structure looks something like this:

\actualApplication (business logic, actual deployment target)

\library_common (model, users, etc)

\library_datastore (DAOs for AppEngine Datastore)

\library_application (common gxt/gwt stuff for login, place management, etc)

#1: Intelli-J is reporting weird JRE Emulation Errors.

As it stands, the gradle builds work great; however, in Intelli-J, when I edit any of the client classes in library projects, Intelli-J gives me a warning that: Method 'String.compareTo( String )' in not present in the JRE Emulation Library so it cannot be used in client code. So, obviously, that's not correct. Intelli-J still compiles and runs fine, but I'd like to make it stop doing that.

#2: Something Fishy with Startup Times

So, this thing takes FOREVER to get to the module loaded in DevMode. The server starts and the plugin connects, but I get an unresponsive javascript errors in chrome before the thing ever shows up. I have to hit "No" every time just to get it to come up. The first time. It doesn't seem TOO bad once it's rolling, but MAN it's so so slow. Any tips on what I might be doing wrong?

Thanks for any tips!

E

[Evan Ruff]

Oh, also, I have one other weird issue.

I have the follow deps in \library_application:

    providedCompile 'com.sencha.gxt:gxt:3.1.0'

    providedCompile 'com.google.gwt:gwt-dev:2.6.1'

    providedCompile 'com.google.gwt:gwt-user:2.6.1'

When I look at the setup and everything for \actualApplication the libraries are in there as expected with the type "provided". When I go to make the project, Intelli-J acts like it can't find those libraries at all, giving me all sorts of weirdness with class file not found for anything referenced in those libs. If I add them to the deps in \actualApplication, then it "makes" as expected; however, I get two references to the classes when debugging which is quite annoying.

Doing a gradle clean build from the command line in \actualApplication works flawlessly without the libs in the deps in the gradle.build, just inheriting them from the subproject..

Any idea on how I can make them only be included once in \library_application?

Thanks!

E

[Jens]

#1: IntelliJ's inspection that produces that "error" is slightly outdated. Either ignore it or disable the inspection on class/method/statement level or turn the inspection off.

#2: Gradle/IntelliJ should not impact DevMode + Browser plugin performance. The initial load of your app can be slow until things are cached in gwt-unitCache. Also the Chrome plugin isn't the fastest compared to FireFox or IE plugins. So I guess you are not doing anything wrong. You app just reached a certain size where it takes time. You could check if your heap memory is large enough for DevMode as you should increase the heap memory from time to time as your app size grows.

-- J.

[Jens]

Am Montag, 21. Juli 2014 00:00:09 UTC+2 schrieb Evan Ruff:

Oh, also, I have one other weird issue.

I have the follow deps in \library_application:

    providedCompile 'com.sencha.gxt:gxt:3.1.0'

    providedCompile 'com.google.gwt:gwt-dev:2.6.1'

    providedCompile 'com.google.gwt:gwt-user:2.6.1'

When I look at the setup and everything for \actualApplication the libraries are in there as expected with the type "provided". When I go to make the project, Intelli-J acts like it can't find those libraries at all, giving me all sorts of weirdness with class file not found for anything referenced in those libs.

If "make" does not work, then your module dependencies are not correctly set for IntelliJ modules. Maybe anything in providedCompile is not detected during IntelliJ import?

 

If I add them to the deps in \actualApplication, then it "makes" as expected; however, I get two references to the classes when debugging which is quite annoying.

Why do you get two references? Where do they come from?

-- J.

[Evan Ruff]

Hey Jens,

Thank you so much for your help. It's quite frustrating learning a new IDE and without people like you I think I'd just QUIT PROGRAMMING all together! 

Thanks for the tips on the inspection weirdness. For anyone else that has this inspection hiccup, you can disable it by going to File > Settings > Inspections then open the Google Web Toolkit set and this uncheck "Classes not from JRE Emulation in Client Code." Boom problem solved.

As for the speed issue, I think it might be related to the provideCompile issue.To make the issue happen, I comment out the deps in the \actualApplication build.gradle, then I:

1. in shell, \actualApplication\gradle clean

2. in Intelli-J, go to Gradle Tasks, sync

3. in Intelli-J, go to Build> Make Project

Then, I get the errors in the Messages Make window... a bunch of class file not found, etc.

If I leave the deps in the \actualApplication and repeat the process above, it works as expected; however, the two references show up in the debugger when I stumble upon an exception. If I click something in a gxt.* or gwt.* package, it pops up a window with paths to two separate libs (in the gradle cache). This would indicate that it might be pulling two copies of those JARs in, and I can't imagine that's good for performance either.

I can perform all the gradle GWT tasks as expected from shell with only the library project having the dependency.

Is there something that I need to set in Intelli-J for these specifically? When I look at the Module Settings, the dependencies are there in the \library_application (Provided) project, and the library_application project is indicated as a dependency in the \actualApplication project.

Thanks for any advice!

E

[Jens]

Is there something that I need to set in Intelli-J for these specifically? When I look at the Module Settings, the dependencies are there in the \library_application (Provided) project, and the library_application project is indicated as a dependency in the \actualApplication project.

If your library_application is a provided dependency of actualApplication and library_application itself has provided dependencies then it might be that IntelliJ just ignores these provided dependencies of library_application. Maven does this too (see table at: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).

I think you should define your GWT dependencies of library_application as compile dependency because you need them on class path whenever you use library_application somewhere else. If the other project uses library_application as provided then all the compile dependencies of library_application should be treated as provided automatically.

-- J.

[Evan Ruff]

Hey Jens,

Thanks for the suggestion, I will try that out. What I was trying to avoid was having the libraries (gwt-user, gwt-dev and gxt) be included in my WAR. I thought provideCompile was used for this senario. Am I misunderstanding how to use it?

If so, how would I go about instructing gradle/Intelli-J to exclude those?

Thanks!

E

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/13p7us72HKw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Jens]

Thanks for the suggestion, I will try that out. What I was trying to avoid was having the libraries (gwt-user, gwt-dev and gxt) be included in my WAR. I thought provideCompile was used for this senario. Am I misunderstanding how to use it?

No that's fine. Sadly Gradle does not have a build-in provided scope yet. It is just that if you have a provided dependency and that dependency also has provided dependencies then these might be ignored/omitted like Maven does.

-- J.