We just started using Play Framework 2 (Java) with IntelliJ IDEA (14.1.1) on a new project.
As it is now, simple tasks like running tests always seem to start with a 20 second long "make" step, and then the tests itself takes a few milliseconds.
According to the "messages" view, the Play 2.0 compiler is handling compilation, even though this is not checked in the Play2 options in IDEA.
Is this normal?
Are there any known quickfixes for how to make this work in a practical way?
A workaround was described in the issue mentioned in my last comment.
Disable play2 compiler in settings
Delete the play*xml files in the .idea folder for your project
Restart IDEA
If you reimport the project (e.g. when build.sbt changes), you'll have to delete the xml files and restart IDEA again.
This will presumably be fixed - look for updates in the YouTrack Issue
Related
I've come back to project after a long diversion, and upgraded tooling. This means Netbeans 12.5, Java 17, Gradle 7.3… at least allegedly. For some reason, despite setting the Gradle version to 7.3, it appears to build with 7.0.
Per the image below, setting the Gradle version to 7.3 doesn't seem to be picked up. (That is immediately after hitting Apply.) It still tries to build with 7.0. And – for some indeterminate reason – it can't.
Restarts don't help; I can't get the configuration to be picked up. (Searches for reference to similar issues provide 5-year-old answers that are no longer relevant.) I've even tried deleting the 7.0 distribution; to no avail, it comes right back.
Can anyone provide guidance on getting this to work properly?
Netbeans 12.6 fully supports Java 17 and Gradle 7.3. Gonfiguring the Gradle wrapper for 7.3 gets picked up correctly, eliminating all errors I was experiencing.
Don't bother with gradle in Netbeans. It's a horrible, buggy disaster and 12.6 just seems to want to up the ante.
Netbeans does NOT support gradle in a meaningful way for normal users.
You now get complex multi-projects whether you want them or not.
When creating a Java Application you don't get a choice at what the Main class is called. It will be App with app.java and you will like it.
If you try to rename app.java to something useful. It will not change "Class App" to "Class Useful" it will instead change it to "ClassUsefulp". It will not rename the test file and you will be left with several syntax errors that you can have fun cleaning up.
No, you cannot rename the subproject itself. That will continue to be the extremely descriptive and useful "app" subproject. The IDE will not provide you a way to rename that.
There is no meaningful, intuitive way to create/delete/modify subprojects.
If your gradle version is somehow out of sync there is still no useful way to reset/recreate the gradle wrapper other than creating a whole new project and moving your source code over to the new project.
Oh, so you gave in and accepted the multi-project structure. You noticed that if you go through the multi-project creator GUI then you can create multiple subprojects. Yeah, good luck with that. They won't have gradle build.scripts or wrappers. You won't be able to build your awesome creation.
Want to use command line arguments? Forget it. There is no "run" element in the project properties. You cannot create different run configurations.
Want dependencies? Or any other project configuration? It's all manual editing of gradle files. There's no GUI to assist non-gradle-wizards.
Yeah. you can probably work around a lot of this by dropping to a command line shell and editing the gradle scripts/files manually and running gradle commands manually. A) you're going to need to be a gradle wizard, and B) why are you using an IDE in the first place? you've got gradle, you've got vi available. Bathe in the nostalgia because you'll have to anyways.
Do you like the idea of gradle? Do you use Netbeans? Stick with Ant, or Maven if you need external dependencies; you'll thank me later.
I am frustrated by the long build time that IDEA needs before starting my application. I do use DCEVM to enjoy changing code on the fly better than plain hot-swap does, but this doesn't work if I really do need to start my applications multiple times.
IDEA is supposed to be able to have incremental compilation, but I'm not seeing it. I see no options to enable this. Start or starting a debug of the application, takes nearly half a minute. Must it take so long? In theory, IDEA has all the class files already generated, except for the source files that were just edited. IDEA ought to be able to fill in the few blanks, and get the application running almost instantly. What's the hold up, why does it insist it must re-compile every single source file again?
ps. I'm using the Eclipse compiler in IDEA, so that it tolerates some source files not being compilable. I have to do that, because it is one giant tree of java files, where I can not control every one.
Then I saw that perhaps Gradle does have incremental compilation. So I thought to re-create my project, this time with Gradle. I am having a very difficult time figuring out how it works, how it integrates, what tasks are moved from IDEA to Gradle (if any). Even creating a simple skeleton test application with Gradle in IDEA is very frustrating. There are all sorts of fuzzy bits all over the place that leaves you guessing. The tutorials on Jetbrains are almost useless. I can't find one single clear to the point that just explains it in a nutshell how it works. I see some demos that says, click here, and here, and there, but the results on my end aren't the same as what I see outlined.
For instance, Gradle complains that it can't find the junit jar. Ok, so I go into the project settings, and attempt to add the junit jar to the classpath. Under Libraries, I then see an entry to "Gradle: junit:junit:4.11". But there is a second one: "junit-4.11". Why two? Can I delete one? Why is the one so verbal, colon this colon that, etc.
So I add the junit jar files I have to both.
But then in the Gradle Projects window, where I see the hierarchical breakdown of the gradle project setup, verification->test. This is then supposed to run the test class I did manage to create.
FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all dependencies for configuration ':testCompileClasspath'.
> Could not resolve junit:junit:4.11.
Required by:
xpert_client4:xpert_client4:1.0-SNAPSHOT
> No cached version of junit:junit:4.11 available for offline mode.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
"Could not resolve junit:junit:4.11".
Gradle is extremely frustrating. If all I have to have, is to start a main() in a large project, why would I go through this trouble of using this gradle system that offers things I don't need? Why is it so convoluted, fuzzy, and confusing?
Same goes for an Android project. IDEA can compile and run an Android app without Gradle just fine. Simply avoid anything gradle when setting up, and it just works.
Plus there are all the things that one has to do to speed up the supposedly slow Gradle system. There is the daemon thing. Parallelize, and apparently you can set it in two ways (why). Configure on demand. Globalize. Minimize. minSdkVersion. Offline (oh no, not that Maven thing that pulls down jar files from the internet over and over). jCenter. Profile.... it goes on and on. All those workarounds, hacks, adjustments, tweaks.
Is there anything to be gained by gradle-ifying a working IDEA project? Would I get faster build and startup times if I go through all this trouble? Can I avoid Gradle altogether, and forever (in the hopes that it doesn't somehow becomes mandatory).
I've been coding since the 80s. I've used all sorts of systems. I've build my own build systems. I'm not green here. I also hate having RTFM, if those FMs don't get to the point, and don't explain things well - as if the ones that wrote it, don't really understand it themselves - they know what buttons to press to get it going and that's it.
I find this thing one of the most frustrating things I have seen in a long time. The previous horrible build system I've tried in the past, and have avoided like the plague since, is Maven. The lack of clear thinking with these systems is astounding.
So, aside from these frustrations, what I'm after is: is it worth figuring out Gradle and applying all the workarounds and tweaks, so that I may, once I go through this grief, enjoy faster build and startup times of my application?
Or, would I be better off, avoid Gradle altogether, and instead, do something like place the startup of my application in a loop, so that every time I exit that the application that it re-runs main(). I would then use DCEVM to code on the fly while possible.
Lastly, I forgot to mention. Enabling automatic build in IDEA works really badly. A build seems to always involve re-building every single file, over and over. And setting build to automatic, all it ends up doing is it redoing this in the background over and over. There is nothing that happens in an asynchronous way, where when I finish editing a source file, and start the debug of the application, where IDEA has done any of the building in the background ahead of time, because it redoes the whole thing again after every single tiny little code change. Plus it makes the CPUs spike to near 100% constantly.
IDEA is a great IDE, but the whole compile thing is a total nightmare front to back.
Make sure to disable anti-virus protection in your Gradle caches directory and your IntelliJ project directory. For me, this reduces Java compilation time dramatically, because of all the intermediate files and JARs associated with Java builds. Excluding those same directories from Windows Search indexing can also help.
As of September, 2020, this is the list of default directory locations that should be exluded from virus scanning and Windows search indexing, published here.
Gradle cache: %USERPROFILE%\.gradle
Android Studio projects: %USERPROFILE%\AndroidStudioProjects
Android SDK: %USERPROFILE%\AppData\Local\Android\SDK
Android Studio system files: %USERPROFILE%\.AndroidStudio<version>\system
I published some instructions on my blog for doing this for Windows Defender and Windows Search Indexing, which I'll repost here for completeness:
Windows Defender - How to Exclude a Directory
Open Windows Defender Settings
Click "Virus & threat protection"
Click "Virus & threat protection settings"
Scroll down to "Exclusions" and click "Add or remove exclusions"
Click "Add an exclusion" and select "Folder" from the drop-down menu
Navigate to the directory to be excluded, or paste its path into the "Folder" text-box, and click "Select Folder"
Windows Search Indexing - How to Exclude A Directory
Open Windows Control Panel
Search for "index" and choose "Indexing Options"
Click the "Modify" button
Under the appropriate drive letter, navigate to the folder you want to exclude, and make sure it is unchecked
Double-check your work by verifying the directory shows up in the "Exclude" column of the "Summary of selected locations" table
Even I was facing the same issue and found one option in Intellij IDE, which closely solves my issue, but not fully.
Build Project Automatically and Compile in Parallel
Though it does not solve fully, but I see some performance improvement in build time, whenever I add/upgrade dependency and run the tests.
When I first ran eclipsify on my Project I noticed that Eclipse complained about the:
return ok(index.render("Your new application is ready."));
Line. It did not recognize the index method. The application still ran so I ignored it for the time being. Now, however, I am getting a new error. I think I just added a few dependencies to Mongo, attached some Model files and rebuilt but I am now getting this error:
compile: sbt.InvalidComponent: Could not find required component 'compiler-interface-src'
I'm not sure why this is happening, especially because I'm a bit of a sbt idiot. As a side note, Eclipse is reporting that my "classes_managed" build path entry is missing, but I think that is due to my inability to compile after doing a clean. (Clean and update are working).
1) Templates are compiled by Play, not by eclipse. After the "eclipsify", you need to run play compile (or play run) and refresh your eclipse project. See How to make Eclipse see the changes in Play! compiled templates?
2) After adding dependencies, launch a new time the play eclipsify command.
But i think it's not the problem. What is the dependency you add ? And what is your Play2 version? (I suspect an incompatibility with a Play2.1 library)
And for your information, a general rule: Play doesn't depend on Eclipse to compile files. Do not try to clean in eclipse, but run play clean (and refresh eclipse).
Happen to run into this issue few times, tried above, also following
Clean up Play-framework based project
But nothing worked.
What it turned out to be was a IntelliJ Idea cache corruption issue, and invalidate and restart Idea worked fine.
IDE misconfiguration is a big source of inefficient time use in our team.
I wanted to know if other teams have tried to check the health of the eclipse workspace with continuous integration.
Eclipse is open source and extensible, and most (all?) of its files are in xml. So it should not be difficult to add a step to continuous integration that checks the health of the workspace, such as no missing Jar files, no errors, etc.
What we have is a separate ant script to do the real builds that go to QA and to the customers. This ant script is run with continuous integration and we have put in place a few simple checks that catch most big showstoppers.
The workspace configuration is a different story and we sometimes detect problems when it's too late (the dev left home).
EDIT: Note that we share our Eclipse config files.
There is some information on building with Eclipse from the command line here.
(Should be a comment, but I can't).
I don't see why you want to do that. Eclipse complains loudly if anything is broken, so leave it to the developer.
What you should consider instead, in my opinion is to write tests that check that everything is as you expect it to in the building process of those builds from source code that the developer has checked in the source repository.
If a build breaks due to a jar is missing in the build, add a check. If a build breaks because it is dependent on a certain feature in the JVM, add a check.
Only ship builds outside of the development team that pass all tests. Those builds that fail, should be fixed by the developer introducing the change that broke the build.
Since you are using Ant, you can create a custom task that verifies the following files against pre-defined ones. If they don't match, report problem:
workspace/.metadata/*.* (whichever configurations you think are important)
workspace/project/.classpath
workspace/project/.project
workspace/project/.settings/*.* (whichever configurations you think are important)
Of course, these files include some hard-coded paths, so you can use regular expressions in the pre-defined files.
If you want to check only simple things like "the project doesn't compile", then just compile the project in the ant script (using the javac task) and see if there are errors.
Another thing - continuous integration should better be IDE-agnostic. I.e. you must have a IDE-less environment (a CI Engine) that compiles the project. Imagine the following:
three developers, one of them accidentally removed a jar from his Eclipse, but the project in the repository is compiling. No need to report problems in that case
one of the developers adds a new jar and commits. The others have not updated. No problems are reported in there workspaces, although after they update, they might get the problem.
That all said, I think you'd better look at Hudson, which is a continuous integration engine. Thus you won't be dependent on IDE settings for your builds.
New to Java and Eclipse. For some reason, the first time I load Eclipse on a given day, it freezes at "Initializing Java Tooling : 59%". Eventually, it gets past this and I can do my work. However, this "Initializing Java Tooling : 59%" stage takes a REALLY REALLY REALLY long time. Does anybody know why it does this or how to fix it?
You can take several thread dumps of the Eclipse Java process to see what plugins are being executed. Here is some info on how to take thread dumps.
What happen is that Eclipse loads all project configurations and then for each project it initializes all declared builders. The builder loading and initialization is what takes most of the time. Some builders need to resolve and/or reload project dependencies such as jars and other projects and also check if project resources had changed. This process can also trigger initialization of builders on other projects and it may take longer depending on 3rd party plugins you are using.
It breaks on a per workspace basis. I have had some success removing plugin data. Usually this can be found by at:-
[workspace-directory]/.metadata/.plugins
If you delete everything except:-
org.eclipse.core.resources
You will keep your projects but everything else will be deleted (preferences, scm repositories ... etc.) and will need to be recreated/reimported (you will be greeted by the welcome page, but do not be alarmed).
There is probably a specific set of plugin data that should be deleted, but this fixed my last occurence, and so I have nothing else against which to further hone in on the problem state ... for the time being.
Following mike's advice, I resurrected my workspace by just deleting [workspace-directory]/.metadata/.plugins/org.eclipse.jdt.core. That directory doesn't seem to store any important information.
I had this problem and found a solution here:
http://tedvinke.wordpress.com/2010/06/21/eclipse-initializing-java-tooling-hangs/
Here's what I did.
Rename the .projects folder in .metadata/.plugins/org.eclipse.core.resources
in the workspace folder. This doesn’t seem to affect any project and
the .project folder will be recreated when Eclipse restarts.
A more simple-minded approach than Eugene's very clever one is to remove all your plugins, one by one, keep notes, and watch performance after each removal. This should help pinpoint the plugin that's doing the big initialization. It's possible that you didn't really need that plugin after all.
In my experience, there is often a big delay associated with source control plugins because some feel the need to check project state against the repository on startup. There may be options to control this. You can also look at what kind of label decoration is in effect; if some decoration is dependent on repository state, that could be your time waster right there.
Be warned that this procedure may be destructive! You probably included those plugins for a reason, and if you remove the plugins it's possible you'll lose capabilities on already present projects, and that even replacing the plugins will not necessarily restore everything in all projects to the former state. As the disk repartition people say: We assume that you have everything backed up!
How about doing the following
eclipse.exe -clean
Just uncheck "Build Automatically" and force quit Eclipse. Then start it again.
Project>Build Automatically - uncheck
-force quit
-start Eclipse