I try to migrate from eclipse to IntelliJ IDEA 13.
Up until now I had multiple eclipse projects which are all in the namespace xxx.yyy.zzz.
(Kind of a plugin infrastructure with one main app and plugins using the same namespace...).
After migrating the eclipse projects to IntelliJ modules everything builds fine, until I open a File of the main app. IntelliJ then complains: "Package name "xxx.yyy.zzz.Foo" does not correspond to the file path "src.xxx.yyy.zzz.Foo", and therefor also fails to find the imports depending on this package.
This happens even though I set the source-folder to src. The weird thing is: This only happens to some of the imported modules, others (in the same namespace) are fine.
And also the modules which show this behavior start behaving like this only after I import other modules (so I guess there is some problem with conflicting package-namespaces in modules?)
Any input would be highly appreciated, since I can't find a solution to this.
Thanks!
Related
One of my colleague recently created a new project in eclipse ,committed and pushed with built-in git client.
After I cloned to my computer and opened with eclipse, I found eclipse creating .classpath file.
Isn't .classpath a crucial file for eclipse project(also .project) to find referenced jars?
I am very confused after googling, seeing all the discussions talking about ignoring them.
Aren't they crucial to Eclipse to work correct ?
Why are people ignoring them ?
What's the problem if I have them not ignored ?
These Eclipse-specific files make it easier to set up Eclipse and Visual Studio Code for a Java project.
In general, IDE and tool specific files (Eclipse, Jenkinsfile, GitHub workflows settings, etc.) should be shared as long as they are used and maintained. Otherwise, delete them.
Of course, if you use a different IDE than Eclipse and Visual Studio Code and do not use the Eclipse compiler in IntelliJ IDEA, these Eclipse-specific files are useless, but they do no harm. As long as you do not use functions like file or folder links (stored in the .project file), sharing these files does not lead to IDE lock-in.
In Maven and Gradle projects the .classpath file can be derived from the pom.xml or build.gradle file, but settings that cannot be derived like compiler settings (warnings and errors), formatter or save actions settings (which are stored in the project's .settings folder) should be shared so that everyone uses the same.
This also applies to the .project file, as it contains which natures the project has and which tooling is required. If something is missing, a dialog will ask if the missing plug-ins should be installed.
Eclipse puts these files into the project folder and not into the .metadata folder, because they are intended to be shared. But why there are people who do not share these files? Probably because of historical reasons. 15 or 20 years ago, there wasn't Git, Maven and Jenkins. In these days, a Java application was usually built on a developer's computer by manually exporting JARs or at best via some batch/shell scripts. This meant, making the same build on a different computer or even just with a different IDE or IDE version might led to a different result, causing a lot of trouble. IDE agnostic builds was the solution for this problem. Maybe that's why people today still think that everything have to be IDE agnostic and recommend to use Maven or Gradle. But these files are not shared to build a product to be shipped. Hopefully.
They're Eclipse specific, so they don't really belong to the project's source code. Developers might be using different IDEs, so Eclipse's .classpath would be useless for someone using IntelliJ IDEA for example.
Since the project most likely uses Maven / Gradle / some other build system, the IDE is capable of generating the classpath based on the pom.xml or build.gradle files, as you noticed. Only if there isn't a build system, and the project is IDE specific, it would be necessary to include those files to make sure the project keeps its meta-data. But that's an unlikely scenario in modern times and real life work situations.
It doesn't usually cause problems to include those (unless there are conflicting project specific configurations from different developers), but they're not necessary either. I don't include them since there's no advantage, and it keeps the root of the project cleaner.
That very much depends.
If your team decides that the eclipse project configuration files are the essential source of truth, and everybody else should be using them: then sure, these files should sit in your source code management repository.
But doing so leads to "IDE lock-in". Or worse, it leads to having multiple files containing the same information, as a future IntelliJ user might prefer to add .iml files on top of that. So any change to project definitions needs to happen twice now.
So, ideally, in 2020: use other tools as your base source of truth (like gradle definitions), and then tell your individual IDE to use that.
I see that unchecking "Show Derived Resource" under the top right corner menu under Open Resource (Command + R) does work for most of the eclipse project including regular maven project. But it doesn't work for Multi module eclipse project for me. Could be an issue with m2e? Any solution?
Eclipse has a weekness regarding nested projects in general, maven multi-module projects are just a flavor of them.
In my experience it all works best if you only import the module-leafs but not the intermediary ones. The drawback is that you dont have their pom in the IDE, but unless you need to edit them it's not a problem. m2m will still use them during building and stuff.
If you really want to have the intermediary projects too, then you need to set the folders of the nested modules to "derived" in the properties dialog. However, that setting is a little fickle in my experience and gets lost along the way. A solution to this is this plugin that I have used in the past https://nodj.github.io/AutoDeriv/ and works similar to .gitignore.
I fixed my problem but I don't know how/why this fixed it so I am looking for an explanation.
I opened my project yesterday and I could no longer build due to the fact that the java and jsp imports could no longer see javax.* classes. I had another project that worked fine but could find no differences in their build paths.
After reading several threads on build path, etc. and not finding any problems in the configuration file I simply retyped the import in one of the source files, eclipse was able to lookup class tree as I typed in the editor, and once one of the imports was retyped the project would now build.
I would like to understand what in the Eclipse project configuration was hit and why this happened and how this method I used actually resolved the problem.
IntelliJ IDEA 13 has started exhibiting a very weird behavior in my local setup.
Namely, in any new Java class added to an existing project, Code Completion does not work. So, after declaring an object variable of any type in the new class and then typing the name of that variable, followed by the dot (.), no suggestions come up for any of the methods of the corresponding object.
For example, after declaring
File f = new File("/home");
typing f. does not bring up a list of all the methods in the File class, to select one from. As a matter of fact, when typing the dot (.), no suggestions appear and at the bottom left (in the status bar) of the IDE window, the message "Identifier expected. Identifier expected." is displayed. Sometimes, a long list of totally irrelevant methods from irrelevant components or libraries are proposed.
Strangely, Code Completion works as expected if the above declaration happens in any of the existing classes.
This behavior persists after many combinations of machine restart, IDE restart, project re-importing, closing/reopening, or rebuilding.
Any ideas?
Make sure you mark all your Source directories as such in File -> Project Structure -> Modules.
Ensure that you are not in Power Save Mode while running IntelliJ (File [menu] -> Power Save Mode checked or not). If Power Save Mode is enabled, IntelliJ will not run background tasks, including code completion.
For followers, one thing that helped me (auto complete only showed cast
field
instanceof
etc.) was that I had opened a maven module that didn't link correctly to its children (it had a commented out submodules section), so IntelliJ just showed the maven java files as basically "text" files with a tiny "j" in their icon in the project pane. Fixing up the root maven pom.xml file to include the children dirs as modules and voila, they are treated as real java files again, woot!
I am using IntelliJ Ultimate 2017.1, and I encountered similar issue.
Maven project, was trying to using selenium APIs, but the intellisense didn't pop up relative methods for me.
Here is the way I solved my issue:
Right click on your project src folder
Choose Mark Directory As
Then select Sources Root
I had this same problem and it was caused by me not having a folder marked as sources root.
Right click on your src directory and Mark Directory As > Sources Root.
It helped me to mark the src directory as the "Source Root".
Cut the folder .idea and the files *.iml in the root folder and paste somewhere else out of project. when you re-open the project , auto import will work again magically.
There could be 2 reasons for your problem
Either the the source folder is not properly configured in the your build java build path. If the source folder is not properly configured the autocomplete wont get the required class definitions and autocomplete would fail for your project.
Restoring the default options in 'Windows > Preferences > Java > Editor > Content Assist > Advanced'
Right click on project -> Add framework support -> Select Maven -> Click OK
The only thing that worked for me was killing IntelliJ (on Ubuntu) and starting it again.
This is not IntelliJ 13 but a more recent 2017.1.1 Community version. Adding this answer here so that others benefit from a cause that has its roots in the Gradle Configurations.
Now, in my case too the auto complete, Generate Override methods and other features were not working. What I figured out is that in my project settings, I had multiple configurations for the gradle modules. The moment I cleaned up the rest of the modules and retained the only one (apart from test) I needed for that project, all behaviors were back to normal.
Also in such cases of Gradle projects, remember to mark all your sourceSet root folders ad the Source folders.
Edit: If you do not want to create multiple configurations per sourceSet and you are importing a gradle module, on the import screen, you should also disable the Create a module for per sourceSet flag. Without this, I was having to remove the multiple modules after importing the module.
It was happening for me in a module that was not added in the parent project pom (they did it on purpose), that was the reason, I right clicked the pom.xml of the module that has the issue and clicked the
now the autocomplete came and in addition to that I can see the module as a separate project in the maven tab on the top right.
I was facing this issue while coding for eclipse-che client extension. Eclipse che modules are all of maven type. My client extension project was an independent module which can be compiled independent of the parent project. When I imported the same structure to Intellij my client-side extension project was not giving suggestions. After I include the client-extension project to the parent module (adding it to pom.xml) the suggestions started showing up.
Remove your package from the Settings>Editor>General>Auto Import>Java>Exclude from Import and Completion
I had run into this problem. None of the solutions from this post worked, but I was able to fix it because I accidentally put my project's package in the "Exclude from Import and Completion" settings.
I had a groovy project where somehow the jdk was not set as a dependency, so jdk classes would not autocomplete.
Fix:
project structure
modules
(your module)
tab Dependencies.
In the field Module SDK, add a jdk.
I had similar problem, nothing in this topic helped.
So finally I made it work, I clear cache of IntelliJ and restart.
File > Invalidate Caches / Restart.. > Invalidate Cache and Restart (button)
In IntelliJ I get this weird error when I try to compile.
Cannot find annotation method 'cascade()' in type 'javax.persistence.ManyToOne': class file for javax.persistence.ManyToOne not found
I know, it seems pretty obvious what the problem is, but having spent too much time on this problem I now turn my trust to you!
I use ideaCommunity-9, where I have created a global library for JBoss, which contains all JBoss jars including ejb3-persistence.jar. My module includes this library, and I have moved it to the top of dependencies.
No otherwhere in classpath I have a javax.persistence.ManyToOne class, and it also opens up in IntelliJ without problems.
If I open the file where I get the compile error, IntelliJ shows no problems and also navigates to the class file on pressing Ctrl+B.
The code is also build with ant and here it works fine.
Besides the above error I get six others along the same path (name in Table, etc.) - all related to JPA. I also get a message saying "Please file a bug to JDC yada yada yada."
Try to tick a checkbox "export" in your dependencies.
I mean: "File" menu -> Project Structure -> Modules -> Dependencies, and there you can see libs included to the module. You should also see a checkbox near each lib in column 'Export'.
Just got this myself but non of those things were my issue. I downloaded a project from github, then opened in intelli J with the problem after trying to run a junit test.
Solution: Project Structure -> Modules -> 'Project_Name' -> Sources (tab) -> click src folder -> Mark as: Sources
This should highlight src to be blue and all the class files should be the circles with C instead of looking like normal files. Try running a test again and see if that does it.
I'm sure, it is too late to answer, but I had to follow a different approach for this error to resolve this issue.
I had to create this as global library and add that library to the module, then only the error is resolved.
Isn't that similar to this SO question?
The solution there was to add all JBoss jar (which you did), but also all persistent-related libraries (like Hibernate)
See this JBoss project configuration for example:
alt text http://jdick.co.uk/blog/wp-content/uploads/2008/12/projectstructure1.jpg
In short, ejb3-persistence.jar might not be the problem here, just a symptom of other elements missing.
Or, if it is the problem, it may be related to the fact that it is not deployed correctly (for the WebApp configuration).
Here's an idea:
Maybe you have multiple versions of your jar file.
Search your folder hierarchy for the file ejb3-persistence.jar,
using a file management tool such as Total Commander.
Multiple appearances of the file in your classpath may confuse IntelliJ Idea
into not recognizing the proper class in the proper jar.
had a similar problem ("cannot find class spring...DefaultResourceLoader even though it was in my maven dependencies) and no amount of tweaking of revalidating caches seemed to help. Blowing away my $HOME/.Idea* paths and (basically) starting from scratch fixed it for me. At least for now...
I was getting the class not found error message when trying to execute a .groovy test class, which referenced a .groovy file (located in the root of the source directory of a submodule - i.e. no packages).
Moving the source file .groovy into a package, fixed the issue for me.
Move:
src/main/groovy/RunMe.groovy
to
src/main/groovy/somePackage/RunMe.groovy
In intelliJ I got this problem when I built (ctrl+shift+F9) at the file level.
The reason is, I had changes in other files in the same maven project, that were not getting picked.
I solved it by building at the project level (Select the Maven project in intellij and press ctrl+shift+F9)