Develop Reference

Can't import the maven project in IntelliJ Idea 2016.1.1

I am trying to import a project in IntelliJ Idea 2016.1.1 using: File->Project from existing sources->choose the required pom.xml
It comes to this dialog box, but nothing happens on clicking next button.

I had the same issue, but managed to solve it by updating my /etc/hosts file such that there is was only one entry for localhost
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
# 192.xxx.xxx.xxx localhost <-comment out this
255.255.255.255 broadcasthost
#::1 localhost <- comment out this

In my case, this problem was solved by setting the JDK in IntelliJ IDEA settings. Like this:
Before selection correct JDK, I had the red text in this field.

I have had similar issue on my spare computer, the problem appears when creating/importing Maven project. It seems for some reason it has lost the access to java SDK and it was not there, even thus I tried to re-importing it. I tried to select java SDK again with out luck. I ended up with following solution:
Uninstalling IntelliJ (2016.2.4)
Reinstalling Java JDK latest 1.8, restart the system
Installing latest IntelliJ (2016.2.5)
First time I started IntelliJ, and when creating first time new project, ensure selecting the correct SDK path (see image)
Now you should be able to (click on next) creating/importing new Maven project.
The other answers did not helped me much.

I had the same issue just now,through the idea.log, I found the problem:
Caused by: com.intellij.execution.process.ProcessNotCreatedException: Cannot run program "/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/bin/java" (in directory "/Users/xxx/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/182.4129.33/IntelliJ IDEA.app/Contents/bin"): error=2, No such file or directory
at
com.intellij.execution.configurations.GeneralCommandLine.createProcess(GeneralCommandLine.java:408)
at com.intellij.execution.process.OSProcessHandler.startProcess(OSProcessHandler.java:51)
at com.intellij.execution.process.OSProcessHandler.<init>(OSProcessHandler.java:44)
at org.jetbrains.idea.maven.server.MavenServerManager$2.startProcess(MavenServerManager.java:367)
at org.jetbrains.idea.maven.server.MavenServerManager$2.execute(MavenServerManager.java:358)
at com.intellij.execution.rmi.RemoteProcessSupport.startProcess(RemoteProcessSupport.java:212)
at com.intellij.execution.rmi.RemoteProcessSupport.acquire(RemoteProcessSupport.java:139)
... 28 more
the jdk1.7.0_79.jdk have been removed,so it doesn't work...

I ran into this and at first it seemed due to the use of a tilde ~ in the file path of the root of the project. It also seemed to go "flaky" if you try to use a ~.
More investigation lead to:
/home/user/.IdeaIC15/system/log (might be a bit different for other systems)
Do
tail -100f idea.log
in a terminal in that directory and see what you get when you click "next"
Mine was missing / corrupt java7 instance
All this is pertaining to Linux only.

I had the same problem, turns out I had a lock on the directory. try renaming the folder to confirm this is not your issue. Once the lock is removed try importing the project.

I know this is older issue, but today I also encountered this issue. In my case it was JDK unavailable (as my IntelliJ was pointing to external JDK which got updated and old path didn't exists). Nevertheless, the issue can be different for different people. The best way to tackle this problem is to check intelliJ logs, that will tell you exact issue it is facing and then proceed with its fix. I'm sure this will save your time and you will solve the issue very quickly.
How to locate idea.log file is here
P.S. May be when you read this post, the above link to locate idea.log file stale. So kindly get the updated link from IntelliJ jetbrains website (Look for idea.log file path)
OR follow the below steps:
1. Open intellij
2. Click on Help tab from menu-bar
3. Select Show log in Finder. Get the path to this path and do tail -f </path-to-file/idea.log>

In my case to solve this problem I did a strace on Linux of the Intellij Java process that is called when you do a next (+ child processes) and discovered that it was related to the execution of the Maven embedded jar.
Execution of the Maven embedded jar (process 4940):
4940 execve("/home/rudy/Softwares/jdk1.8.0_111/bin/java", ["/home/rudy/Softwares/jdk1.8.0_11"..., "-Djava.awt.headless=true", "-Didea.version==2018.1.4", "-Xmx1024m", "-Didea.maven.embedder.version=3."...
Error returned by the process 4940:
4940 <... execve resumed> ) = -1 ENOENT (No such file or directory)
I had decided to move the jdk8 to a directory home/rudy/Softwares/jdks/jdk1.8.0_111 and it was previously in home/rudy/Softwares/jdk1.8.0_111.
It seems before to move JDKs used by Intellij to first reconfigure Intellij to use the new path and then use the import maven functionnality.
I did a mistake, it is true (moving the JDK) and Intellij has no way to know where the JDK was moved (unless scanning the all filesystem) but it should clearly display an error message and not get blocked on the 'next'.

I had this issue today and it took me 2 hours to identify and fix it.
I tried to import the project from perforce workspace which had '/' in the workspace name (ABC/lighting_workspace).
When I created another perforce workspace without '/' in the name (lighting_workspace), I was able to import the existing project :)

Had exactly the same issue, in my case it was a memory problem: the importer needed more memory than the one allowed by the VM's limit set by default after the installation of IntelliJ: I had 768 mb set by default and i moved them to 2048 mb.
You can set this under :
Preferences |-> Build, Execution, Deployment |-> Build Tools |-> Maven |-> Importing |-> VM options for importer

Install latest version of Intellij Idea (leave everything by default) and Java JDK (called SDK in IDE).
Create a new empty project.
Press Ctrl+Alt+Shift+F to open Project Structure panel.
Chose the SDK you downloaded, like : C:\Program Files\Java\jdk-10.0.2.
Apply and File->Open your project
Now it work ! (Also cleaned my host file)

are there gradlew or gradle caches on linux?

Are there caches or other environment files that can cause gradle to throw this error?
Exception in thread "main" java.lang.NullPointerException
at org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:34)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:25)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:58)
I'm building a Jenkins CI server for building android apps. The Jenkins master passes the job off to an AWS linux slave, where it
Wipes the previous workspace
Downloads the github repo
moves into the project folder
./gradlew clean build
Then it throws the exception above.
Other repos using ./gradlew build on this machine.
This repo built prior to: adding additional disk space to the machine and downloading more android SDKs, neither of which should affect gradlew. Attempting to build the exact repo that built, with the same configuration that built still throws the same exception.
I added echoes to the gradlew file to see where the problem happens, and all of them sound prior to the final line:
exec "$JAVACMD" "${JVM_OPTS[#]}" -classpath "$CLASSPATH" org.gradle.wrapper.GradleWrapperMain "$#"
What do I need to do to make this build?

This took some hunting, but here is the solution that I found. Jenkins (by default) does not have access to the $PATH or any default applications (so that the computer can run Ruby 2.2 and your CI jobs can run Ruby 1.0 for example)
Iff you look in the script that is causing the error, it's because it calls a script which calls a script ect, until at some level down (I want to say 7) it calls the diff function. because this dependency was written assuming that your UNIX box knows the baked in applications. Because the Jenkins user calling this function doesn't know that this binary exists, and the way the entire script is written it throws the exception above.
Hope this helps

Something must be messing with your gradle wrapper setup. I would highly recommend the Jenkins Gradle Plugin. It has made my gradle builds trivial. You can specify any path to the build.gradle if it is not in the root workspace.

Triggering a Git fetch, reset using Jenkins

I have a Java package which is checked in Git (and code.amazon.com) and I have a Ant job to trigger the package. Within the Ant job, I have created a macrodef for Git and I am performing a git fetch and git reset so that I can get the latest codebase every time I am triggering the Ant job.
When I am triggering the Ant job using Eclipse, it is working. If I am running the Ant job from terminal using ANT –buildfile my_buildfile.xml, it is also working.
Now I have setup Jenkins on my machine and am trying to run the Ant file. Jenkins is not able to trigger the Git job in the Ant file. It is giving following error:
/rhel5pdi/workplace/bangshis/EpubYJConvPerfWorkspace/src/EpubYJConvPerfLinux/Jenkins_Linux_build_Global.xml:81: The following error occurred while executing this line:
/rhel5pdi/workplace/bangshis/EpubYJConvPerfWorkspace/src/EpubYJConvPerfLinux/Jenkins_Linux_build_Global.xml:99: Execute failed: java.io.IOException: Cannot run program "git": error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1047)
at java.lang.Runtime.exec(Runtime.java:617)
at org.apache.tools.ant.taskdefs.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:58)
at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:428)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:442)
at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:628)
at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:669)
at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:495)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
Part of this error might be due to the reason that, my Jenkins is not able to trigger the job as the current user of the host machine.
To solve this problem, I have tried taking the following steps:
Creating a global credential and using password-less account (RSA ID).
Logging into Jenkins using the same username as system.
Installing Git and Git client plugins and setting them up appropriately.
Kindly let me know if I am missing something, and if there is any way out. If my approach is not correct, I would be glad if you can share few other ideas.

I think it's related to the git configuration on your master (or node)
This solution should work to fix your problem:
Jenkins giving error while cloning from gitHub

#Dr.Bokko is correct...and I should thank him for guiding in the right direction. I am trying to give the complete answer. There are three factors based upon which we can do the setup of GIT with JENKINS.
1st Factor: To access GIT repository, if it is a public repository, then user credentials would not be required. But for access restricted GIT repositories, we need to make sure that proper credentials are passed. Git and Git Client plugins need to be installed for Jenkins to understand GIT operations.
2nd Factor: Before running the script, add a build step and export all the libraries needed as a part of the shell script.
3rd Factor: Finally check the System Configuration in Manage Jenkins section and check the environment variables which are considered by Jenkins. If they are not appropriate, then go to the nodes management link, and all the environment variables as KEY-VALUE pairs.
Hopefully, these steps mentioned above would solve the problem.

The following error appears in your stacktrace:
Cannot run program "git": error=2, No such file or directory
What that means is that the git executable is either not installed or not in the command path of the process running ANT.
It's not entirely clear why you're calling GIT from ANT. Normally Jenkins would perform the checkout of the code first (using GIT) and then call ANT. I would highly recommend investigating this alternative workflow, which might require the installation of a GIT plugin for Jenkins (can't remember if this is a default plugin or not).

Why does Maven javadoc fail with error "cannot read options"?

When I run mvn javadoc:javadoc, I get the following error:
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An error has occurred in JavaDocs report generation:Exit code: 1 -
javadoc: error - cannot read options (The system cannot find the file specified)
Command line was:"C:\Program Files\Java\jdk1.6.0_14\jre\..\bin\javadoc.exe"
#options #packages
When I invoke the command "C:\Program Files\Java\jdk1.6.0_14\jre..\bin\javadoc.exe" on my system it runs the javadoc executable.
I am running:
JDK 1.6.0_14
Maven 2.0.8
The javadoc reporting part of my POM looks like:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
</plugin>
...
And relevant environment variables:
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14
M2_HOME=C:\Program Files\Apache Software Foundation\apache-maven-2.0.8
M2_REPO=C:\Documents and Settings\<user>\.m2\repository //<user> is my user
MAVEN_OPTS=-XX:MaxPermSize=128m -Xmx512m
I have tried reinstalling Java and Maven, as well as using Maven 2.1.0, JDK 1.6.0_11, and even JDK 1.5.0_11. I have compared my setup to a coworker who has practically the same environment but no problems. It used to work about a month ago, and no, I don't know what's changed on my system since then. I first encountered it with JDK 1.6.0_11. This happens on every project I've tried in our repository, and my coworkers have no problems with the same projects. So I'm pretty sure it's just my environment and not the projects themselves.
I would really appreciate any suggestions on this.

I figured it out, but first I tried various things:
Uninstalling every JDK and JRE on my system, and then reinstalling Java to a path with no spaces
Removing every environment variable I wasn't using, and cleaning up my PATH
Relocating Maven and my local repo to directories with no spaces
Rebooting (you never know, it's Windows)
Today I tried to run a batch file which didn't execute properly, and I quickly realized that when I double clicked on it, it was executing the file but not in the directory where it lived. And then it hit me.
A few weeks ago I got fed up with our IT guys forcing our cmd window to open at H: and so I Googled and used this page to "fix it". It seemed to work; I didn't have any problems for a few weeks and I had already forgotten that my cmd windows all used to open to some H: drive. But every single cmd window opened to a directory I specified--whether I ran "cmd" or clicked a batch file or if Maven opened a new cmd window...
I guess when Maven runs it shells out to execute the javadoc command. And so the javadoc part was working, but it couldn't find the options file it writes out because the working directory was wrong.
So, now I'm back on H: until I can figure that out. And then I'll screw something else up. But hopefully, if nothing else, this will help someone else...

I believe the problem is that the javadoc command is being run without any parameters. I ran into this in one of my multi-module projects where it was trying to javadoc a non-java module. (The javadoc was being requested by the parent, pom.)
Does the module in question have javadocs to be made? We finally moved to maven 2.1.0 and I haven't seen the problem reoccur.
Are your other team members also using maven 2.0.8?

Headless Eclipse Build returns ERRORLEVEL 13

Everything was going well. Nightly builds ran for more than a month with no problems. However, suddenly when invoking the feature builder from Eclipse the execution ends right away with the message.
ERRORLEVEL 13
As far as I know I haven't changed anything, as this computer is normally not touched. (It is only used for the nightly builds).
I've googled around to see what this error means but to no avail. I found a link from IBM that shows a custom bat file that catches this error, but the explanation given is not very useful.
My guess is that this is related to the workspace, somehow, or that the whole eclipse installation is corrupted.
Do you have any idea what this error means and how can it be corrected?

After reading what the error code means thanks to the answer from VonC I understood where to look. The problem was a lot more obscure that it seems.
I looked into the configuration folder for Eclipse (logs are either written there or in the .metadata folder when something goes wrong), and I found a huge log file. Inside the file I found the following error:
application org.eclipse.sdk not found
and the following exception, followed by a plugin name, several times:
java.util.zip.ZipException: Too many open files
Several plugins could not be loaded, causing a cascade of missing dependencies that prevented Eclipse from launching. I searched the web for this exception and found the following bug description from SUN, which says that Java 1.5.0 can not open more than 2,100 zip files.
The problem started a while after I installed the BABEL project translations for Eclipse into the build computer. These are more than 900 fragments, containing translations for many plugins, one for each language. As I installed it on top of an existing eclipse installation, it seemed that it was not a problem to open them.... until I cleared the workspace for the builds. Then Eclipse wouldn't launch anymore. I went over the limit. It didn't help that the first thing I tried to fix the build was, again.... clearing everything.
Because I only use this computer for headless builds, I didn't realize that the problem was in Eclipse itself and I was looking inside the build process. I only realized when I looked into the log file.
After installing Java 1.6.0_11 I was able to launch Eclipse and go on with my build.

It should mean "ant build failed", meaning the headless ant script fails at some point.
You should check if you can catch the log/output generated by this script to analyze this ant session and see at what point the ant script fails.
If it fails right away, it usually is because of:
a change in rights (writing access), or
in environment variable modifications, or
in resource access (path non accessible).
You also have to check if the computer is still in its original windows domain, and if the rights (admin ?) associated with the account running the ant script are still the same.