I've reinstalled my windows machine and installed Java 13, Maven 3.6.2 to finally run my projects. I use java immutable classes which get generated by maven. I have a problem where only SOME generated sources are picked up and some are missing in the editor (shows errors). However, I'm able to run the application through IntelliJ and build with Maven.
Any ideas on how to fix this?
Do note that I've gone through a number of similar questions where ALL generated-sources are not picked up and I have the correct settings for picking up source files.
Kind of a funny situation here... Everything worked fine, but I found that one of the interfaces I used (from which a generated source is made) had another generated source marked as red (as if not imported). Importing the full path for it suddenly resolved the issue.
common.advert.Price getPrice();
My guess this is an editor problem that I have.
Related
I'm fairly new to using JavaFX and have been tinkering with it on my own in a few simple projects.
I have to collaborate with a few others for a main project, where I am seeing this conflicting issue:
I'm having an issue with the src.zip file of javafx. On my standalone projects, I do not encounter this issue. However, since working with others, this error has appeared. Prior to this, I was getting a Kotlin plugin issue, where I had to completely disable Kotlin.
Error:java: C:\Users\nolan\Javalibs\javafx-sdk-11.0.2\lib\src.zip
I'm unsure of what this issue might mean, so any help would be appreciated.
Thank you.
I had the same problem too and discovered it was because I added the JavaFX 11 SDK to Intellij incorrectly. I initially had the added library point to just the directory /lib. Since this directory includes both the jars and src.zip, Intellij will try to run both and produce the error.
To solve this, when Intellij prompts you to "Select Library Files," you need to explicitly select the files within the /lib directory which will then be added as shown here. This will also allow proper inspection of the source code without Intellij having to decompile the class file when ctrl + left clicking a class name.
Figured this out. I extracted the src.zip in the appropriate directory (deleting the zip as well), then had to change my VM Path to include:
--module-path "C:\yourpathto\javafx-sdk-11.0.2\lib;out\production" --add-modules=javafx.controls,javafx.fxml
I forgot to add ;out\production to the Module path.
A quick rebuild then solved this issue.
I have a Gradle file which, whenever I load open it in IntelliJ IDEA 14.1.5, shows IDE errors for the entire file. Namely all the errors seem to be either:
java.lang.String errors
or
groovy.lang.Closure errors
I've tried clearing the file's contents and only writing the top line:
group 'com.me.blah'
but even that results in an error.
For context's sake - this is an individual module in a larger SpringBoot project. This module is a set of simple static files (with Gradle for CSS compilation, static analysis, etc), while the rest are Java modules, and are not having Gradle issues.
Can anyone think why IntelliJ would be struggling to understand this Gradle file?
I've noticed this often. When creating a new project and using the 'Gradle' template, IntelliJ seems to get it all wrong. So what I've resorted to doing is after creating a new project, delete the .idea and .iml files and re-open the project directly from the Gradle file. IntelliJ seems to better understand what is going on in this case.
For the first part of the question: group is a property, so there must be an assignment, not a function call. The right code is:
group = 'com.me.blah'
I found this suggestion in the IDEA bug tracker(IDEA-142683):
Workaround:
One can add a comment such as
//noinspection GroovyAssignabilityCheck
to suppress the warning, but this should not be necessary as these are standard every day Gradle usages.
This issue was recently updated and is marked fixed, ready for release with version 2016.2 release.
Try File | Invalidate Caches and restart. It worked for me after i mess the syntaxe somewhere else in the file.
For anyone looking for a similar fix, this boiled down to the type of the module. My module was defined in my .iml file as
type="WEB_MODULE"
I created a new Gradle module and pasted in the same contents, deleted the original, renamed the new module to have the same name as the old one, and everything worked fine. When I diffed the results the only change was that the .iml file now said:
type="JAVA_MODULE"
So there's the answer, seemingly. Change your module from "web" to "java".
For me, after trying out all this answers without result, changing the Java SDK of the project did the trick, I was on 1.8 and changed it to the newest one, but still a project level language of 8.
Hope this helps!
What I found is that this warning is from Groovy inspection of the Intelliji. So if your project is not pure groovy, you can disable this inspection by going to File -> settings -> Editor -> Inspections -> disable Groovy. Again, just a workaround.
Happened to me recently on windows. I tried all of the above but it didn't work.
What i did:
1 - I had JAVA_HOME environment variable already set. So IDEA picked that as project SDK and these warnings showed up.
2 - So, i removed the default JAVA_HOME from project SDK and manually added jdk path. Restarted and all warnings were gone.
Maybe it will help someone. Thanks.
So I have a maven module (module-A) in IntelliJ. I recently moved some classes from it into another new maven module (module-B) and added a dependency to it. Once I had done this I also modified the signature of a method of one of the moved classes (now in module-B).
I re-imported the poms so that IntelliJ would pick up the dependency changes and ensured all Java imports for the affected files were correct again. Now when I attempt to run my webapp (which depends on the two modules) I get a compile error in a class in module-A calling the modified method of the class in module-B.
The error message is basically saying that that method doesn't exist but believes the old method still exists! I click on the 'make' error and it takes me to the line in a class in module-A calling the modified method...the weird thing is, IntelliJ knows it is fine in the file. i.e. The method is not underlined in red like a compile error would normally be, but the class file name is :(
I compiled it from the command line using 'mvn install' (having also installed module-B) and it is all successful. I have deleted the classes directory in the target of both module-A and module-B and also invalidated IntelliJ's caches and restarted...still happening...any ideas?
I found out that this might help:
File -> Invalidate Caches
Maven Projects -> Reimport should help.
I spent a few hours on this same issue. All of the cleans in the world didn't help.
I deleted my out and target directory in my project and recompiled - that cleared it.
Edit: There is also a magic feature under the file menu: "Invalidate Caches / Restart" This fixes a bunch of "intellij is confused" problems.
Change "Java Compiler" setting in IDEA (User compiler javac in-process) to fix the problem.
Try to mvn clean your projects and mvn install your project B.
The maven integration with intelliJ is kind of buggy when you use the make command directly provided by Intellij. You should directly use the mvn commands, or start them from the maven panel.
I ran across a very similar problem that was driving me insane.
My code would compile fine with the ant task I normally run, but it would not build in IntelliJ, complaining about "Cannot Find Symbol blah blah"
Turns out, you can add "Excluded" files for the compiler. My file somehow got added to that list.
This list is located in File > Settings > Compiler > Excludes (IntelliJ 13)
Following steps should fix this problem :
delete .IntelliJIdea12 / .IdeaIC12 older under c:/user/.../
Invalidate Intelli's cache: File > Invalidate Caches.
This re-indexes your workspace on start-up and also clears your local history. Before you do this, commit or back up all your uncommitted changes.
Once your workspace is back after indexing, do a maven clean install.
when the build is successful, click on Maven Re-imports
This worked for me, I think it should work for others too with a similar problem.
So just stated it up this morning and it's all working!
Last night what I did do was open a new project (intelliJ project) from module-A's and module-B's parent pom and successfully got it to build, possibly doing that and then opening my original project again fixed it somehow...very annoying though
The behavior I see is similar to the one described by the original author.
Error markers show up on the right side of the editor in Intellij 14 and less so in 13.
This happens also if using Scala instead of Java and using SBT instead of Maven.
Also noticed this occurs after the second project is loaded. The first is always fine.
(After much trial and error) Figured it might be caused by Intellij's internal caches becoming somehow corrupt. "Invalidate caches" worked sometime and sometimes did not.
I work with a number of projects using Play! Framework and they use different versions of Scala and lots of dependencies.
I hypothesized the caches become corrupt because the internal key Intellij uses is not good enough to handle situations when the same class, loaded multiple times in different jars, has different signatures, and this results in the editor errors while external builds work fine.
Then the "Changing Ivy Cache Location for sbt projects in IntelliJ IDEA?" post gave the idea to segregate the ivy cache SBT and Intellij use in the hope that the ivy path is part of the internal cache key.
Paul Phillips of TypeSafe provide the "SBT extras" tooling and here I found a way to instruct SBT to use a project based ivy home, cache and SBT boot:
https: //raw.githubusercontent.com/paulp/sbt-extras/master/sbt
declare -r noshare_opts="-Dsbt.global.base=project/.sbtboot -Dsbt.boot.directory=project/.boot -Dsbt.ivy.home=project/.ivy"
How to configure Intellij
: see http://content.screencast.com/users/SemanticBeeng/folders/Snagit/media/ec8ec491-6d0c-4691-9598-916a63ba65ef/12.02.2014-08.59.png
Then did the same for the external SBT build to work in sync
: see http://content.screencast.com/users/SemanticBeeng/folders/Snagit/media/dcb287c4-200f-47f3-a937-42865675a22b/12.02.2014-09.01.png
Finally got rid of the user home based .ivy2 and all the contents.
To be sure Intellij does not use this folder I made it readonly.
This was a mistake. Intellij seems to silently fail resolve dependencies if you do this.
This solved the errors and believe they will not come back. :-)
If Intellij guys hear this: please test your releases (Scala, SBT, editor) with all the Play Framework templates from TypeSafe. The problem becomes apparent quickly this way.
I just had a similar issue that was driving me insane. I had done all the other things mentioned in the answers above because I have used Intellij forever, but none worked. In the end I found out that in the maven projects portion of Intellij, one of my modules had been marked "ignore" a simple unignore command from the context menu did the trick.
In my case, I had manually marked a directory as "Test Sources Root" but IDEA marked it on a parent Maven project. Unmarking it in File->Project structure...->Modules fixed the problem.
This could happen if you are using different version of java while building outside IntelljJ. My IntelliJ had java10 and I was using java8 while building at terminal. Changing java version to IntelliJ fixed this issue for me.
I had a very similar behavior. Running (Scala-)tests would always fail due to errors in unrelated java classes during the 'make' step.
It turned out, I had included a 'global' SDK library that collided with one of the dependencies from the project. A proper helpful error message only showed up after I deleted the 'make' step from the test.
I then deleted the duplicate library, re-added the make step to the test and everything is now working fine.
I ran into this problem today after upgrading from 12 to 13.
Later I fixed issue as I used the same name for Project and Module and looks Intellij allows this but cannot handle it correctly.
No idea why setting will impact the compilation, although there is no error in java editor. Should be a bug in version 13.
I was facing a similar issue after upgrading from IntelliJ 12 to 13. After multiple uninstalls and re-installs (of multiple intelliJ versions), numerous cleans and .m2 repository clearing, I finally figured out what my issue was.
In my intelliJ settings, the repositories mentioned in my main POM file could not be connected to. this was in turn due and alternate repository that was mentioned as a part of my pom file.
Once the POM was made to point to the correct repository, all my classes had their compilation issues resolved.
To check if your repositories are being connected to, go to File -> Settings -> Maven -> Repositories
Here, your indexed maven repositories should be connected to successfully. If they are not, then intelliJ will not be able to resolve most 3rd party and module dependencies.
I'm embarrassed to say, but we also had this problem, but it was due to a mistake in our package name.
When creating the packages for a new project I accidentally created a package called "org.package".
My project then had a directory structure like:
/src/main/java/org.package/
Which caused all sorts of havoc with IntilliJ.
Once the correct folder structure was created on the file system, IntelliJ worked great.
/src/main/java/org/package/
Note the difference in /org.package/ vs /org/package/
The fix was i made it javac instead of Ajc and i put 1.8 of course according to your jdk version.
for some reason when i invalidate and restart intellij it was set to be the default !
my version is
This happened to me...what fixed it was realising there was an extra main.iml file in the source directory. Deleting that instantly made the compile errors go away.
None of the above answers worked for me.
In my case, I had to finally create an explicit Maven Run Configuration for the module (with Command Line as "clean install") and then run it.
It is in Run > Edit Configurations
close the project
go-to the project folder and delete idea project file and .iws file
run mvn idea:idea
restart the project.
seems idea keeping the old project dependencies without cleaning even though we run file -> invalidate caches
Setting the proper Java SDK solves the issue
Right click on the project and select "Open Module Settings"
Check if you have the right Java SDK under platform settings
Check the SDK under Modules
Rebuild the project from "Build" menu
Delete the installation directory.
Remove the following directories:
~/.config/JetBrains/
~/.cache/JetBrains/
~/.local/share/JetBrains/
This will remove each and every configuration plus installation of jetbrains tools, be it IDEA, goland,etc.
Now install everything from scratch.
That's the only way it worked for me
I have a project which has shared functionality between three other projects and have linked these to existing projects as I normally would using the add project functionality of the libraries folder.
This all used to work however when I started up Netbeans yesterday it just wasn't working as in the other projects won't compile even though the projects are linked. It can recognise the packages - just the actual classes themselves were not recognised... and to add to the weirdness some of the classes are getting picked up fine.
I have checked the dist folder of the shared project and the Shared.jar file exists. Also I have checked the Jar and the other classes that are not being recognises are there also.
Any suggestions?
alt text http://inverse.seednet.eu/snaps/duvc6r.png
Solution
I had to reinstall netbeans to get this solution resolved
This is most likely a bug in 6.8, as I have ran into the same problem and I only solved it by recreating the project, was a fairly fast process, only had to re-import the sources and then add the JARs on which it depends.
To confirm this case you only have to see the imports that NetBeans did not find, and then go to the included JARs and see if the class really is there, if it is, then it should be able to find it.
Do you have AbstractCrawler.class compiled to its output location as well?
I've a strange and new issue with an eclipse 3.5 rcp application: Everything worked fine, then I changed the running system and moved a single class from one plugin to a dependent plugin. No big issue, but all of a sudden the application complains with a class not found exception (or NoClassDefFoundError - don't know exactly but will look it up and edit the post...)
I double, triple, ... checked all that I know, and made sure, that the manifest contains the dependancy with the correct version number and that the package is correctly exported in the other plugin. Eclipse jdk doesn't complain (no compiler errors/warnings) but when I debug just to the point where the class is instantiated and use 'CTRL+SHIFT+I' to inspect the 'new MyClass()' statement, the inspectors tooltip sais, that it can't resolve that class.
Any help, hint and encouraging comment is highly appreciated!
I also encountered a NoClassDefFoundError in an Eclipse 3.5 Galileo RCP app where I had a src/java folder in one plugin and needed to export a package for use by another plugin.
The solution for me turned out to be including the bin folder as part of the runtime class path. Normally it's only been necessary to include the . folder.
Solved the issue just by chance (and don't have the faintest idea whether this was a bug or a feature...):
The plugin project, where I moved the class into, had a maven-like folder structure with src/main/java and src/test/java, both folders defined as source folders.
Just because I wanted to try almost everything, I changed this structure back to the typical eclipse structure with just src as the single source folder.
And, after another 'project clean', it's running again. Strange...?
Edit
thanks for the hint, the folder structure was just a typo in this post.
After a lot more struggle - I'm quite positive that this was an eclipse issue. After 'solving' as above, the very next day the application failed to load other classes from the
same plugin and I think, after a restart of the Galileo workbench, the problems are gone.