Develop Reference

How to (manually) disable Eclipse jdt.ls compilation in Maven/Java projects

I currently have a Maven Java 11 project that builds fine. However, I use Eclipse's implementation of the language-server for editing the code within Emacs. This works fine, everything that I really need is available.
However, my question, is how can I disable the Eclipse LSP/compiler from attempting to auto-compile the project? It's not always an issue, but often the JDTLS seems to be recompile everything all the time to the point that when I run Maven, it has to recompile everything again. At best, this is a slowdown in the develop->test cycle. At worst, I have to clean build frequently.
Eclipse has an option in its GUI which "builds automatically". I am curious, is there a text file I can toggle this setting with?

According to the lsp-java documentation, the setting you are looking for is lsp-java-autobuild-enabled.
However, if there is a way to run the tests directly rather than via Maven, it would be faster since Maven does not support incremental compiling like JDT does (ideally, compiling should be done incrementally on save and not when running the application or a test).

Intellij test run history

What I miss the most in IntelliJ compared to Eclipse is the test run history window. Does anything like this exist in IntelliJ? I didn't find it anywhere so far and have looked a few times at least.
In our project we have ~500 integration test cases which take like 5 minutes to run from IDE. Often I have a situation where for e.g. 5 tests fail in 2-3 different classes. I fix something, that should remove failures from first test suite, rerun it to see if it helped and I must rerun all 500 tests to see which classes contained failures earlier. That is really painful. In eclipse I would just lookup those in test history, repair them also and finally run all 500 to check if nothing new camed up.
Is there a plugin out there or do I miss something obvious?
I use IntelliJ 13.

You can right-click a tab with test results and select the "Pin Tab" option from the context menu. Then further test executions will not overwrite this tab, and you can still refer to it to see which other tests you need to fix.

On the current version of Intellij (2016), you have now a way to reimport older test Result. On the runner tab, click on the button "Import test Results", and select the one you want
EDIT : In the latest version, you have a "Recent Tests" action which allow you to see older test result without a need to open the rest windows. Shortcut Ctrl+Shift+Semicolon

You can also click the "Test History" button to see the old tests result.

Not relevant for Idea 13, but in 2021 this functionality is present in Idea.
https://www.jetbrains.com/help/idea/viewing-and-exploring-test-results.html#view-previous

Yes, given that you are using the IntelliJ test runner (rather than running the tests via maven), you can use the Rerun Failed Tests function.
https://www.jetbrains.com/idea/help/rerunning-tests.html
Edit: based on your comment, can I suggest you run the single test you are working on in "debug" mode, this won't erase the history of your compelte test suite, and you can do that in in combination with the Rerun Failed Tests as needed.

Creating a program that will run before and after compilation in Eclipse

I am currently working on a small program that should comment out some code used for testing.
I want it to auto run before the compiler while compiling the release version and another program that will comment the code back in after compilation was over.
The program works the only thing I am missing is to add it to the build process.
Thanks to all helpers!

In Eclipse, right-click a project, choose Properties → Builders and click New. You can add an Ant script or a command line that Eclipse will trigger when building the project. You can also control the order of builders in the same dialog.
However, I agree with JB Nizet – there are many advantages to having Ant or Maven build your project.

Don't use Eclipse to build the release version of your app. Use Ant, Maven, or any other build tool that is much more flexible than Eclipse, doesn't need a GUI, can be scripted and used by a continuous integration server.
All of these tools should easily be used to include your pre-compilation and post-compilation tasks in the build process.
That said, you could just use a public static final boolean constant FOR_TEST, and include all your testing code in
if (TestUtil.FOR_TEST) {
}
You would then have just a single place to change in the code to have all the test code removed from the compiled version. No need for a complex Java program to do that.
Or you could let all the testing code in the released version, and activate it when testing using a system property, for example. This wouldn't even need any precompilation/postcompilation phase, and would probably have a negligible cost.

IntelliJ. Debug a program even if it does not compile

I have a Java project in IntelliJ that compiles, and now I am slowly changing.
Is there a way to ask IntelliJ to run the project, even if some parts of the code still do not compile? If so, how?
Why I would need this, you ask? see this ticket:
IDEA-61945 Run and Debug commands should ignore compile errors not related to the main being run.
http://youtrack.jetbrains.net/issue/IDEA-61945?query=it#tab=Comments
Please, do not answer this post questioning whether I should or I should not need to run a project even if it does not compile. please.
If not possible in IntelliJ, is it possible in maven? How?

In Intellij 12 you also have the following option (which personally I find the best one):
Go to Edit configuration of your launcher
Go to the before launch section
If 'Make' is in the list: remove it
Add 'Make, no error check'
Now, when you run, a make will still be done automatically but the run will continue even if the are compilation errors.
Regarding the above debate; I think it makes perfect sense to be able to run a part of the code that does compile even if another part of the code does not not; e.g. if that other part of the code belongs to a module that is in your project but not involved when running.

I ran into this exact same problem at work today. Before now, I probably would have been quick to jump on the bandwagon of, "Why would you ever want to do that?" Turns out that Eclipse lets you do exactly this, and if you start working concurrently with other developers who depend on this feature (which is to say, check in code that doesn't compile), it's handy to be able to do the same in IDEA!
And lucky for us IDEA users, you can. Follow these instructions from the FAQ for Eclipse Users, and you're good to go:
To be able to run code with errors, you can select the Eclipse
compiler in Settings dialog, Compiler, Java Compiler and add the
-proceedOnError option to the Additional command line parameters for the compiler.
The only thing that's lame is that it's not quite as seamless as in Eclipse. First, you'll have to untick the option to Make before run because IDEA won't run if make fails. Then, you'll have to remember to build before running. With those caveats, though, you should be able to accomplish what you're after.

Stijn Geukens's answer is correct, but it can be improved.
In Intellij Idea version 12 instead of removing the "Make" rule it can be replaced with "Make, no error check". This way project will be rebuilt (compiler will atempt to do it), but it will run the program independently of compile outcome.

If you want to debug just one part, then you can create a unit test around that. If you do not use the class that does not compile, then you can still debug the unit test related code.

When there are compilation errors, you can exclude specific files from compilation.
Go to the Messages window (if it is not visible: View -> Tool Windows
-> Messages)
Right click the problem file
Exclude from compile

At least in Intellij 12 you can achieve this.
First try to compile the project, including the broken class(es).
Then in the Messages view, containing all the compile errors:
Right-click the class you want to exclude
Click 'exclude from compile'
See this question on how to reinclude afterwards.

For Intellij 2017.3.1 my configuration is like this:
Use the Eclipse Compiler: Settings -> Build, Execution, Deployment -> Compiler -> Java Compiler -> Use compiler: Eclipse
Select "Proceed on errors"
Edit your desired configuration defaults (I use this for JUnit) before launch to Build, no error check: Check this screenshot
Additional step in order for Intellij not to open the classes with errors when you run your configuration. Un-select Automatically show first error in editor in Settings -> Build, Execution, Deployment -> Compiler
PS: This configuration is not perfect for all usages. It only works when you are fixing unit tests that were failing because of your changes in implementation code. When you go back to implementing features it is more useful to disable this feature since it will let you run you implementation code with errors and it will not jump to compilation errors. You need to go back and forth with changing the Eclipse compiler with the Javac one for best results.

Wow, it's been a while since I've been in IntelliJ and I miss it dearly! From my recollection you should be able to right click the main method in a module and run it directly so long as the remainder of the files in the module compile. I don't think it matters that a second module in the same project has errors. Is that not working for you?

updating for version 2017 - 2.5 community as menu options are slightly different
Navigate to:
Run>Edit Configurations
near the bottom of the Run/debug config window look for
"before launch: Activate tool window "
the field below this heading lists your current build config settings.
Use the + and - symbols in order to add and remove build preferences.
Once completed
Select apply then Okay
Thats it!

I don't think its possible at all. How you can run something that doesn't compile? That would be like driving a car that isn't put together. You could comment out the files that don't compile, so that the project compiles....
Edit -- or you can have Intellij not count the file as source by
Right Click on your project -> open module settings -> select your module -> select the file -> excluded

What is build automation software (for example, Ant)?

I see reference of ant a lot but I don't get exactly what its meant to do? from what i've heard its supposed to compile your projects but can't i just do that by clicking Run->Run in eclipse?
Edit : I guess I should rephrase my question. I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?

I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?
Not all the Java development is done through eclipse and not all the jars may be built from the command line ( or should be built from the command line ) .
You may need additionally run test cases, unit tests, and many, many other process.
What ant does, is provide a mechanism to automate all this work ( so you don't have to do it every time ) and perhaps you may invoke this ant script each day at 6 p.m.
For instance, in some projects, a daily build is needed, the following are the task that may be automated with ant, so they can run without human intervention.
Connect to subversion server.
Download/update with the latest version
Compile the application
Run the test cases
Pack the application ( in jar, war, ear, or whatever )
Commit this build binaries to subversion.
Install the application in a remote server
Restart the server
Send an email with the summary of the job.
Of course for other projects this is overkill, but for some others is very helpful.

rogeriopvl is absolutely correct, but to answer your "can't I just do that by clicking Run->Run in Eclipse?" question: that's fine for a project that you're working on on your own, and don't need a repeatable, scriptable build in multiple environments.
If you're working on an open source project, however, or professional software which needs to be able to build on a build server etc, requiring a particular IDE to be running isn't a good idea.

Ant is used to automate a build process, but a build process is often much more than compiling. Ant has "tasks" that can be used to perform miscellaneous useful functions. You can create your own task to do just about anything by writing a java class and telling ant where to find it. You can then mix and match these tasks to create targets that will execute a set of tasks.
You can also set up a dynamic environment in which to build your application. You can set up property files to hold variables that can be used in the build process, i.e. to hold file paths, class paths, etc. This is useful for instance to differentiate between test and production builds where deployment paths, database instances, etc. might change. Ant also includes flow control (if, etc.)
Some things I've seen ant do:
Compile code
Use version control to checkout the latest version or to tag the version being built
Run sql scripts to build or rebuild a test database
Copy files from an external resource for inclusion in a project
Bundle code into a jar, war or ear file
Deploy a web application to an application server
Restart an application server
Execute a test suite
Static analysis, i.e. CheckStyle or PMD
Send email to a team to alert them to a build.
Generate files based on information from the build.
Example: I have a jsp in my app that does nothing but display version/build information. It is generated by ant when I run a build, and the production operations team checks this page when they deploy the application to make sure they've deployed the correct build.

In many larger companies (and likely some smaller ones), you'll find that production code is not built by the people who developed it. Instead, the developers may check their code into a source code repository and tag it. Then they give this tag to a build team.
The build team, in a separate (clean) area - possibly on some headless server (i.e. with no GUI) - will then check out the code and run a build script. The build script will be completely independent of the desktop environment/IDE.
This ensures that nothing which happens to be on any one developer's computer is "polluting" the build. (Or, more likely, nothing outside source control is required for the system to work!)
So most software you use will never, ever be built from a developer's desktop.
PS. You might also want to look at the idea of Continuous Integration

The short answer is that Ant is a great way to create a complete project build that is independent of any particular tool any developer may be using. Without an independent build, things can go haywire quickly - especially for large project teams.
And now for the long answer... I have been brought into several projects without any sense of an independent build. On one project, there was one guy who was not a developer that was tasked with building and deploying the software. He had created 147 separate windows batch files to compile each EJB, each servlet, and each client component. There was no error checking for this build. All log messages, including error messages went to standard out. It was up to him to manually recognize by reading this log which exception or message printed was a normal and which message was an error. He also had to deploy this software he just built. Deploying was equally as complex since there were several load-balanced tiers. Each module had to be placed in the right place manually with options setup to match downstream and upstream tiers. Building and deploying this software took him at least 3 days using this method. Of course, only then could anyone determine if the build "worked". Usually, after this period all the programmers would scramble to debug the build. Programmers would say my module works fine in my IDE. I just click run like this, see?
Indeed, the individual software modules usually worked, but the build and deployment was horribly ineffective. And just as bad, it was equally as difficult for anyone to deploy a build to more than one environment. Management would say, ok you now have this build working in our regression testing environment. Now deploy that same build in this other environment so the sales guys can demo up and coming software. That should be simple to do, but it also took at least 2 days, followed by a "debugging the build" period. Builds and deploys were never simple and never accurate. It really slowed the project down.
Anyway, we replaced this entire procedure with a complete Ant based build and deploy mechanism. The end result was that a complete build could be created and deployed in less than 30 minutes, completely automated. The QA guy managing the builds and deploys could keep a whiteboard of which environment had which build deployed to it and which group was using that environment. This was something that was just not possible with the old system.

Ant is for automating software build processes:
http://en.wikipedia.org/wiki/Apache_Ant

Ant allows CRISP (complete, repeatable, informative, schedulable, portable) builds. You can find great info on it in this presentation by Mike Clark and in his book, Pragmatic Project Automation.

Ant is a build tool, akin to makefiles (albeit with a very different syntax in XML). If you're only using Eclipse it's fine to stick to that and you can always convert an Ant build file into an Eclipse project (Eclipse's launch configurations are then, if I remember correctly, the equivalent of Ant's build targets).
If you want to deploy the source code of the application and allow others to easily build or set it up, automating that using Ant is probably not a bad idea. But it's usually not a consistent experience for users or at least I haven't seen much consensus on what targets should be there and doing what so far.
Ant may also be used for regular automated builds (you wouldn't want to hit Run in Eclipse every night, right? :-))

If there's one close to you I think you'd get a lot out of CITCON, the Continuous Integration and Testing Conference. You get to talk with lots of people about the benefits of automation applied to building and testing software.
Basically people use Ant (with other tools) to automate everything they want to have happen after a commit. The basic advantages of such automation are faster, better and cheaper.
Faster because things happen right away without waiting for a human to get around to it.
Better because computers are really really good at doing the same thing the same way every time. (Humans tend to suck at that.)
Cheaper because you have fewer mistake and the mistakes that occur are caught sooner and therefore cheaper to fix.

You are also referring to the ""Export ant buildfile".
If you write your own Ant script for building your application outside eclipse, you can write your own targets that use the Ant task to delegate to the generated build.xml.
Also, you can configure a project's 'builders' (project properties » Builders) to run any script (ant or otherwise) you want when you build the project, manually or automatically.

Joel (Spolsky) has a great article on "The Joel Test." Many of them revolve around being able to do important things often, quickly and reliably. One of those things is your build.

Eclipse is using ant for building, running, deploying, ...
"Ant is a Java-based build tool. In theory, it is kind of like Make, without Make's wrinkles and with the full portability of pure Java code." (from link text