When I develop spring boot gradle projects in intellij idea, if I want to change some code and restart the project, I have to click the Make Project menu item and this will trigger a gradle build.If the gradle deamon is dead, it will start first which is an upset process.
While in Spring Tool Suite, everything is so easy, just Ctrl S and STS will restart immediately witout the long gradle build. So is there any way to make intellij idea restart faster?
I know if the gradle deamon is alive, gradle build in intellij idea is not very slow and is acceptable. But on my computer, the deamon can usually live for only several minites. When I change some codes and want to see the effects, the deamon died. I have to start the deamon every time! Is there any other ways to make the deamon live longer?
Thanks a lot if there is any useful tips!
Well, thanks to #Gregg and #CrazyCoder 's comment, I found some useful links:
Developing/Debugging a Gradle-built Spring Boot app in IntelliJ IDEA
I accidently enable the delegate to gradle option in idea, which will trigger gradle build instead of idea's build, which is faster than gradle's. So disable the delegate to gradle option is a choice.
From another post, I get some idea to use the continuous build in gradle: open a terminal and run gradle assemble --continuous, when files are changed(for example save files or defocus window), gradle will compiles files automatically. Then run the spring boot app use gradle bootRun or from the tasks in idea, everything is ok. But this way will start two gradle so ram usages are larger.
Update:
I found another way to automatically compile. Fisrt, enable build project automatically option, then use ctrl shift a and input registry to open a dialog, and then enable compiler.automake.allow.when.app.running opiton. Finally, project will compile automatically and spring boot will also restart automatically.
Related
I have observed an inconsistent way properties are being read in Eclipse. I have a very simple Springboot web project with typical property files. Here is my project layout:
Notice the two property files: testapplication.properties and application.properties. They are identical at this point, the intention is to use them for test and non test environments.
When I try to run this application in Eclipse, I am getting an error about missing expected property values, for example:
Could not resolve placeholder 'min.thread.count' in value "${min.thread.count}"
When I run the same setup using gradle's bootRun task, it works fine.
When I run the same setup in InteliJ it works fine.
If I rename the testapplication.properties to application.properties the application runs fine in Eclipse. As such it is using property form test folder.
In addition, I am pretty sure when I started Eclipse this morning I was able to run the application with a proper application.properties and testapplication.properties files. I was working on a unit test and renamed the testapplication.properties to application.properties, did some work, then renamed it back to testapplication.properties the application refused to start. I have attempted to replicate it: shut down eclipse with two different property files (application and testapplication), start it again and run application. However, at this moment I have the same issue (complaining about missing property value).
As you can see this i weird behaviour. As it stands I find that I cannot use Eclipse as I am not sure what it will do. I've switch to community edition of InteliJ as it seems to be working correctly. But as a long time fan of Eclipse I am heartbroken :)
Does anyone have any clue what could be causing this?
EDIT:
I have checkin in my test project here:
https://github.com/twolak2003/CamelSpringBootEureka.git in branch PropertyFileIssue. Simply clone, switch to PropertyFileIssue branch, import to eclipse as gradle project.
It is a simple vanilla spring cloud boot project running a eureka server and eureka client. For the purpose of this issue we'll just concentrate on eureka-service.
I am using latest Eclipse Oxygen. I did notice the same issue in Eclise Neon. I switched to Oxygen hoping the issue will go away. Only plugin is the Spring IDE. Using Java 8 to run this.
Test 1: Start the EurekaService/src/main/hello.java as Java application.
It starts fine and will read the src/main/resources/application.property file.
Test 2: Rename the EurekaService/src/main/test/resources/restapplication.properties to EurekaService/src/main/test/resources/application.properties. Start the EurekaService application again.
Findings: It starts fine as well BUT it uses property file in the /src/test/resources. This to me is issue as well, it should not be using /test/ for running the application.
Test 3: Now rename the /src/test/resources/application.properties to /src/test/resources/testapplication.properties again. (this is repeat of test1). Once again run EurekaService/src/main/hello as java application.
Finding Despite this being a repeat of test1 the test failed due to "Could not resolve placeholder 'tomek.prop' in value "${tomek.prop}"".
Am I doing something really stupid or is there an issue?
For now with heavy heart I am switching to InteliJ to keep my project going. The behaviour of Eclipse is just too unpredictable for me to stomach for now :(
So far I don't have a correct answer for this other than stop using Eclipse :). But there is workaround.
DO NOT use more than one application.property file.
If you need test properties to override actual properties then name your file as anything else but "application.property". Otherwise you'll get unpredictable behaviour and your Eclipse runtime get's confused.
I use IntelliJ IDEA version 13 on MacOS. I have a maven project, the project is stored in Git. Everything worked well.
Yesterday my Macbook crashed, then I reinstalled MacOS as well as IntelliJ IDEA. After that I checked out my project from Git and open the project in IDEA again. But now In Maven Project's Lifecycle, test is disabled, there a dash across test. I can still package my project, but "Tests are skipped".
Since my project code has no any change, I'm guessing I might miss configured something in IntelliJ IDEA. Any idea?
There's a skip test toggle in Maven Projects tool window.
To enable the maven Test, these are two steps need to complete
Step-1: Go to the settings tab, then go to Build, Execution, Deployment
Step-2: Then select the testing, and uncheck the Enable test runs.......
I have a JVM application that I need to debug using breakpoints with a Gradle task (run and test as dependencies) within IntelliJ 2016.3.5.
There are various sources on how to accomplish debugging with Gradle and IntelliJ:
Debug Gradle plugins with IntelliJ
Using Intellij to set breakpoints in gradle project (most helpful one)
https://youtrack.jetbrains.com/issue/IDEA-119551
https://youtrack.jetbrains.com/issue/IDEA-86465
https://youtrack.jetbrains.com/issue/IDEA-119494
However, these sources are either outdated or meant for another scenario. I do not want to debug the Gradle script but the JVM that runs the actual Java/Scala application. Moreover, the recent versions of IntelliJ use the Gradle Tooling API, which does not offer the option to turn off the daemon. A native support from JetBrains is only provided using the debugging button on the run and test tasks directly, but not if they are defined as dependencies from another task (e.g., check).
According to the sources, this is the way to go then:
run { // or test, doesn't matter
jvmArgs "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"
// xor, or both, doesn't seem to make any difference
debug true
}
In any way, Gradle (or the JVM) will then start to listen on port 5005:
Then, I have created a remote configuration with the following parameters:
But when I start the IntelliJ remote debugging task, it fails:
I have also tried using port 5006 and suspend=n without success. Before that, I tried using Gradle arguments in the IntelliJ-Gradle run task. Then, it indeed connected, but seemingly to the Gradle script and not the application JVM because it did not interrupt at the breakpoints. How to fix this?
Debugging of gradle tasks like 'test', 'run', actually all gradle tasks that implements JavaForkOptions interface, should work in IntelliJ since 2014 year
Meanwhile, I found the solution myself. If you have a similar issue, follow the approach mentioned above using the debug option.
test {
debug true
}
But make sure that external connections are accepted in the settings after IntelliJ restarted:
Then, it connects to the correct JVM and interrupts at the breakpoints using the remote task:
If you restart IntelliJ, however, with the very same option (external connections) enabled, then the debugging task might fail due to a blocked port:
So, for some reason, IntelliJ blocks that port after a restart but it is necessary to enable the setting for the debugging task to work. That's odd and I don't think it is intended to behave like that.
Anyways, if you disable the setting and restart, the port will be open again. Then, re-enable the setting, do not restart, just run the Gradle task, and the debugging task. It will work.
I hope this helps anyone else looking for an intermediate solution to debug JVM applications with Gradle and IntelliJ among the confusing and partially outdated answers out there. If anyone has a better or simpler suggestion, feel free to append your answer.
In sbt there is a live mode, if I use sbt ~run, then every time a java source changed, it will reload automatically. playframework also support that so that when change a source code, we don't reload manually. For gradle, I am running spring boot, but need to shutdown it and then startup after change some code, even if I am using --daemon, it still need some manually work. Anyway to load the code automatically?
A live mode for Gradle is in the works but not currently available. Plugins such as spring-boot may of course provide their own solution.
So I've been running into this for a while and I've seen other questions / answers pertaining close to the subject but I don't feel I understand what's going on yet.
I'm using Spring Roo 1.1.15, Eclipse 3.6.0 & Maven 2.2.1.
I have found that if I have had a successful run of tests (running from within Eclipse) and then make any modification to a RooEntity class object that any/all Roo-centric tests will fail on the next run with the following:
Entity manager has not been injected (is the Spring Aspects JAR configured as an AJC/AJDT aspects library?)
This will continue until I do the following:
Enable "Build Automatically" in Eclipse's Project menu
Flip over to a terminal window and at the project root issue:
mvn -o clean package
Once mvn is finished, then flip back over to Eclipse and refresh the project
Let Eclipse refresh and then rebuild
At this point I can run the test suite and it will report accurate information. (Tests pass or fail based on actual results and not complaining of the Entity manager.)
I have not had the time to upgrade this project to the latest version of Roo and I admit that may be the proper "fix" but I was wondering if anyone else has seen this behavior and can explain what's happening in the rebuild process that would cause the manager to "disappear"? If so or you have found a way to allow Eclipse to act successfully independent of the terminal workaround, feedback would be great.
Thanks as always.