IntelliJ error when package name different than the folder name - intellij-idea

I was writing a simple class HelloPrinter3.java. It's in directory src/two. Now IntelliJ is giving me an error, saying Package name 'three' does not correspond to the file path 'two'. But it also compiles and runs fine.
I already know that a package name should not necessarily be the folder name. But what I am confused is the error. It cannot be the java error as the file would not have run. But then is it IntelliJ error? How can I differentiate between these two errors while writing code? Thanks in advance.

This IDE inspection detects package statements that do not correspond to the project directory structure. Also, reports classes without package statements if the class is not located directly in source root directory.
While it's not strictly mandated by Java language, it's good to keep classes from package com.example.myapp inside the com/example/myapp directory under the source root. Failure to do this may confuse code readers and make some tools working incorrectly.
You can point the cursor at package three and press Alt + Enter to see which fixes the IDE suggest:
Also, you can disable this inspection in the IDE settings if needed:

Related

HelloWorld in Kotlin gives error "Could not find or load main class"

I spent the last 1,5 hour trying to make this simple tutorial work in IntelliJ IDEA, as you can see in this video.
When trying to run the code, I get the error:
/[...] -Dfile.encoding=UTF-8 src.HelloKt
Error: Could not find or load main class src.HelloKt
Caused by: java.lang.ClassNotFoundException: src.HelloKt
I have tried setting up SDK, invalidating cache, removing .idea and .gradle, rebuilding project, deleting the profile and adding it again. I tried those actions in different orders.
Here's a screenshot of the project:
It also complains Kotlin is not configured, but I have already configured it.
Here's the run configuration:
Here are the project settings:
Your Hello.kt file needs to be somewhere inside the src/main folder, probably in src/main/kotlin. This is different from the tutorial, because your project is using Gradle, and the one in the tutorial isn't. I think this is because newer versions of IntelliJ use Gradle by default for new projects, which wasn't the case when the tutorial was written.
The use of src/main/kotlin and src/test/kotlin as source code directories is a convention in Gradle (and Maven). When importing a Gradle project into IntelliJ, main becomes a module, and kotlin becomes a source folder within that module. The same goes for test. In your screenshots, the bold text and blue icons on main and test confirm that's how your project is set up. Files outside of those folders aren't treated as source files, which explains why your Hello.kt file isn't being compiled or recognised correctly.
It's likely that the default behaviour of IntelliJ when creating a new project has changed since this tutorial was written. In the tutorial, they select "Kotlin" as the project type and this creates a project that doesn't use Gradle. As a result, the project doesn't use the src/main/kotlin directory structure.
I can see from your video that you selected the same option, but on the next screen, IntelliJ still automatically selected Gradle as the build system for the new project. To match the project structure used in the tutorial, I think you would need to select "IntelliJ" as the build system.

Did something Change with Pycharm 2016.3.2 - UnitTests no longer auto discovered

I have upgraded my Community version of PyCharm to 2016.3.2, and I'm not positive it was this exact version, but when I went to run files that had unittests in them, only some of them are recognized as UnitTests that I can right click and run.
I have looked to make sure that my classes implement unittest.TestCase
class clWorkflowWebClientTest(unittest.TestCase):
all of my tests begin with test_blahblah()
If I go into Edit Configurations and add one manually, I can right click and run it from the project tree, and it runs as a UnitTest. But I don't get the "Run UnitTests in Blah' dialog when I right click the file.
This turned out to be an issue I caused myself. we had added a folder called 'UnitTest' and introducing this to the path caused issues with PyCharm knowing what was a true UnitTest file.
I still don't know exactly what caused some files to work, but there appears to be one method in those files that did work that was probably being imported from another file that had the proper pathing.

"Class already exists" error in IntelliJ on Groovy class

in IntelliJ (2016.2 and previous) we have our Groovy classes marked red with the error "class already exists".
I think we can exclude that the cause is the stub-generation, as this is deactivated.
Probably it's caused in our constellation: We have included our compiled groovy (and java) classes in a jar that is registered as dependency.
Dependency MyProduct.jar contains com.mycompany.MyGroovyClass
Our source contains com.mycompany.MyGroovyClass
The error disappears if the dependency is registered with Test-Scope, in all other scopes the error appears.
However, in our structure we kinda have to include the compiled classes in a compile scope, as we want to avoid that each developer needs to compile all classes (I know about the compile in background ability, but we have a constellation that prevents this from working).
We have no errors in com.mycompany.MyJavaClass which exists as well in source and in MyProduct.jar.
Any ideas on how we can solve this?
We've been suffering the same issue, it seems to be that IntelliJ registers the Java class, but also the Groovy class, and because of that it is showing that message (BTW, we are using a Maven Project).
So we ended up by going to the target folder -> right click -> Mark Directory As -> Excluded. Then, this setting will be saved on the IML file, and it won't happen again.
Hope it works for your as well!
Cheers
I'm using gmavenplus-plugin:1.5
After marking target/generated-sources/generated-sources/main as "Excluded", The error disappeared. I even did "invalidate cache and restart", It persists the setting. This is great. Intellij 2017.1.5
We have two ways to fix this issue
Exclude Stub Directory
target folder -> generated-sources -> groovy-stubs -> Right click main folder -> Mark Directory As -> Excluded
Remove generateStubs goal from gmaven plugin
Remove <goal>generateStubs</goal> from gmavenplus plugin
Make sure you Mark the src folder as Sources Root and do the same for the test folder
Then delete the target folder (most likely it's marked in yellow) and don't worry it won't delete any code from your project
If the issue persist, proceed to go to File -> Invalidate Cache/Restart

xml files are not copied to target intellij idea

I have some xml files within the source folder along with the java files.
Intellij Idea is not copying them to the target folder.
I want those xml files to be along with the classes in the target.
Eclipse does this fine.
Can anyone please tell how to achieve this in Intellij Idea?
If, like me, the other answer didn't solve your problem -
If IDEA thinks your project is a Maven module (or once was), and it isn't, it'll behave like this. You can fix this by closing the project, editing the .iml file to remove the isMavenModule property, reopening, and rebuilding:
<moduleorg.jetbrains.idea.maven.project.MavenProjectsManager.isMavenModule="true"type="JAVA_MODULE" version="4">
In its default configuration, IDEA should copy any xml file that are in a source directory into the target directory. Other build tools may not. So this answer is assuming you are making the project via IDEA's internal build/make. If using maven (or gradle), you should place your resources in src/main/resources and not src/main/java as Engineer Dollery mentions in his/her comment.
If you are using the IDEA builds and it is still not copying them over, there is a setting you can check. Go into Settings > Build, Execution, Development > Compiler. On the Compiler settings dialog at the top is a "Resource Patterns" text field. This will define what files IDEA will and will not copy over. The default entry is:
!?*.java
!?*.form
!?*.class
!?*.groovy
!?*.scala
!?*.flex
!?*.kt
!?*.clj
!?*.aj
It is just a set of negation patterns of things not to copy over. So XML files should be copied. Check this setting and see if there is something in it to prevent xml files from being copied.

"Duplicate class found" - IntelliJ and .class files

I recently imported one of our company's project into IntelliJ Idea (10.5.1). We build and run the project using an ant build script and IntelliJ supports that just fine.
However, IntelliJ seems to have a distinct problem when the compile output directory equals the source code directory, ie .class files are placed in the same directories as their corresponding .java sources.
(Note that I am aware that is not a proper way to go, but tell my boss that. This project is over 15 years old and correspondingly large, too many things depend on it to be this way, there is nothing I can do about that.)
So once things are compiled, IntelliJ detects the .class files and adds them to the project tree. The problem here is that it considers them class declarations, thus I get a "duplicate class found" message for each and every class. This doesn't make me unable to work, but it is extremely annoying as you may guess.
I tried making the IDE ignore .class files, but apparently that makes it not load any classes at all, including the JRE runtime and anything else located inside of .jar files.
Is there any way to make IntelliJ Idea ignore .class files which are in the same location as their .java sources?
Make sure that you've configured the output directory to the source directory, disable the Exclude of the output directory to see your files.
I coped with this same problem when cloning a project from Bitbucket. To solve it in IntelliJ:
Project Structure > Modules > Source > Source folder > <<"Eliminate the unwanted source folder">>
In my case, I had non-implemented classes in one source folder and a second source folder with the implemented classes (same class names).
I deleted one, built again, and the problem got solved.
Give it a try!