When I click "Debug test file" in NetBeans on certain class, it is run against the binaries compiled from the last build.
I'd like NetBeans to recompile, but I can't find how to achieve that.
Also, it seems that sometimes the recompile happens - i.e. Maven is invoked. Must mostly I get runs with obsolete binaries.
How can I force NetBeans to recompile before running a (single) test?
Disabling Compile on Save feature in project properties should do. Then Maven build is executed all the time. Please note that in upcoming 7.4, Maven builds are always executed but with Compile on Save turned on, the phase execution is skipped.
Related
New to java and intellij, pls forgive me if i cannot describe the issue clearly.
Brand new install of intellij, brand new import of the java project.
From beginning, seems the project builds fine in intellij, in the GUI there's that clean/compile/verify/install/... life cycles. I click clean, then install, it triggers the unit test and all passing. Now i go to the project root in the command line, "mvn clean install" also passing.
Now i make a change to a resource file, *.sql which is used for in-memory db setup for unit test. i click clean, then install, still passes successfully.
Now i go to the command line again, "mvn clean install" fails in unit test.
I'm so confused now, either way i'm doing the "clean", what's the cause and how should to fix it pls ?
BTW, after working in visual studio for so long, this java and intellij is giving me heart attacks, why the build system in java is so hard and messy ?
Your project is likely configured differently from the maven pom.xml file. When the two aren't configured the same, you'll have problems. I would guess that some dependency is configured correctly in the IntelliJ Project file, but not in the pom.xml. I usually have the reverse problem. I use only the pom.xml to specify dependencies, and rely on the maven plugin to refresh the project (eclipse).
With IntelliJ, it's been a few years, but I remember the same idea. Try deleting the project file, and importing an existing maven pom file. Then modify your dependencies using only the pom.xml and not IntelliJ's project interface. If the pom.xml is correctly defined, the project import will work first try. That heavily depends upon the previous developer working with the project.
Maven is actually a very powerful (if not quirky at times) build tool, and the differences between execution on command line or "inside" IntelliJ are usually simple to explain.
Please check:
you are running the same version of maven (check command line with -version, compare to intellij setup in settings
you are using the same local .m2 folder (local repo) for maven vs intellij
you are not running with any "Profiles" in intellij (check that none are ticked).
you are not skipping any tests because they end with "IT" (meaning Integration Test)
These are the common reasons for differences.
If you post a log of your failing build we might be able to help more.
ok, my friend found the issue, in Maven settings in intellij, there's a "Runner" page, there's a "Skip test" there. In my case it's checked, so the run in intellij skipped unit test (which should fail) and did all other stuff, made it looks like it's passing.
Still several puzzles to me, but this "Runner" -> "Skip test" fixed the issue.
Pretty upset with intellij.
I have a multi-module project that uses maven. Is there a way I can point IntelliJ to maven target/ folder so when I start Debug it won't rebuild the project from scratch and re-upload a whole project via JRebel all over again.
Basically, use target/ as a build folder. Changing compile output path didn't work as I expected it to not compile classes that were compiled by mvn already.
The IntelliJ Run/Debug configurations can specify which actions happen before launching the application.
By default for say web applications, this would display
Build
Build x artifact
You may remove both entries if you are happy with building via maven before launching the application.
Regarding the JRebel side of it - it should certainly not be updating the classes on the second compile assuming nothing changed. The classes have their hashes checked before a reload. This is assuming maven and IntelliJ are using the default javac compiler. If either is configured to use ecj compiler, it's best to let JRebel only see classes built with the same compiler.
I just set up JRebel to use with my Spring web app in IntelliJ, and was very surprised to learn that I have to manually rebuild the project/recompile every time I want my changes to be reflected. Doesn't this defeat the whole purpose of JRebel? Is there something I'm missing here? With Eclipse it was nearly instant, make changes anywhere, save, instantly reflected in running app. With IntelliJ the process seems very clunky. Am I missing something here?
Running with JRebel in IntelliJ involves starting your application using Run > Run with JRebel and when you change your application code you have to build the project in order for IntelliJ to compile classes and update your application.
You can do this by running SHIFT + F9 or Build > Build Project
From the JRebel docs:
JRebel relies upon your IDE to do the compiling. JRebel reloads your compiled .class files and not your .java files. When you change code, JRebel pushes the changed classes and resources to the server without redeploying.
Regardless of what IDE you use, JRebel still needs the IDE to compile the classes before it can update the running application. IntelliJ is no different to Eclipse in this regard. Perhaps Eclipse was just auto building the project without you being aware of it. You can also instruct IntelliJ to auto build from Preferences > Build, Execution, Deployment > Compiler > Build project automatically.
Here's a screenshot showing that configuration setting:
I'd like to know what will Intellij IDEA do with my Maven project when I click "build the project"?
How will Intellij build the project with Maven?
Intellij IDEA will not automatically do a make install when you do a Build Project. In order to do that, proceed as follows:
Under Maven Projects tab (usually on the right hand side), select the goals you want Intellij to run after a Build -> Make Project and then right click and select the trigger (for instance in the above snapshot, the trigger was chosen as 'Execute After Make'. You can choose whatever you wish).
After doing this a Build -> Make Project will run a mvn clean install as well.
IntelliJ's build system refers to the Maven ecosystem for some hints, but at the end of the day it is a separate build system.
In IntellIJ, you have a Project, with many Modules. These are both IntelliJ concepts.
An IntelliJ Module has a responsibility to understand what are its dependencies and libraries. This can be done purely with IntelliJ semantic, or IntelliJ can allow some other build system to declare the dependencies and libraries. That is to say: the IntelliJ Module can be based on a Maven pom.xml or Gradle's build.gradle.
When you click "Make" on an IntelliJ Java Module: IntelliJ will check which libraries your Module asks for, and also resolve the dependencies of your Module to work out which libraries its dependent Modules ask for.
Once the libraries are known: IntelliJ will invoke Javac or the Eclipse Compiler (whichever you've configured as your Java compiler) with all those libraries on the classpath. And it will output a jar, not a Maven artefact.
IntelliJ Make will not run a mvn compile or similar (unless you configure it to explicitly, as per #Ashutosh Jindal's answer.
Why would IntelliJ use its own, separate build system, when you've provided an authoritative definition for how you'd like to build your project? I can imagine various reasons:
Maven generally just outputs an artefact (sources and binary jars, and a pom.xml), whereas IntelliJ needs additional semantic and indexes to provide all its IDE intelligence. It makes sense to perform the indexing process alongside the compile, since: if you do the compile incrementally, you can understand incrementally which indexes are dirtied also.
The IDE benefits from being involved in the compilation process. For example: IntelliJ can do "continue on error" builds using the Eclipse compiler. Additionally, the Eclipse compiler can be used to compile only those files which have changed (IDEs watch you as you code, so they know very well which files are dirtied). I have heard that Maven does incremental compile, but I don't know how its performance compares.
In order to support a variety of build systems (Ant, Maven, Gradle): the easiest engineering choice for IntelliJ is to rely on the minimum possible amount of domain-specific semantic, and use that to inform one IntelliJ-specific build system. This allows them to re-use a large amount of code, and have few domain-specific differences.
Is there a plugin or some nice way to make gradle compile and test my application in the background?
I know there are some plugins for intellij and eclipse(infinitest amongst others), but I am looking for a general gradle solution regardless of the IDE.
It would be nice to start a testing-deamon and make it use growl or some other notification tool to let me know that the code is not compiling or the tests are failing.
Continuous compilation/testing/etc. are features planned for future versions of Gradle. They will be based on the existing Gradle Daemon.
Update:
Gradle introduced the continuous build feature in version 2.5. The feature is still incubating, but we can already use it in our daily development. The continuous build feature means Gradle will not shut down after a task is finished, but keeps running and looks for changes to files to re-run tasks automatically. It applies perfectly for a scenario where we want to re-run the test task while we write our code. With the continuous build feature we start Gradle once with the test task and Gradle will automatically recompile source files and run tests if a source file changes.
To use the continuous build feature we must use the command line option --continuous or the shorter version -t. With this option Gradle will start up in continuous mode. To stop Gradle we must use the Ctrl+D key combination.
http://mrhaki.blogspot.com.au/2015/08/gradle-goodness-using-continuous-build.html