I have only one module in the project, named FilterWidget. Despite that, IntelliJ sees multiple "ghost" copies of it:
All these modules allow partially separate, partially shared setup, which creates a mess.
What is it and how to fix?
These are not ghost modules; these are modules representing individual source sets in your Gradle project. As described on the JetBrains Web site, IntelliJ IDEA starting with version 2016.1 creates a separate module for every source set in your Gradle project, in order to correctly resolve dependencies which are only used in one source set.
Related
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.
I am an Eclipse/STS user/developer, now trying to use IntelliJ Idea (CE)
2020.2.(1,2,3)
For a project based on Gradle, how spring-integration, when I open the IDE it happens the following
Ok, let the IDE load the project ... but
From above, that is the problem, I don't want that the IDE starts automatically to build/rebuild the project. I just need, open the project and that's all.
Observation: for example in Eclipse/STS exists the option to disable Build Automatically
I did do a research in the Web and I read the following posts and questions:
How to disable automatic gradle builds?
IntelliJ IDEA “Build project automatically” apparently not working
Intellij IDEA Java classes not auto compiling on save
Sadly the dialog options were changed but ...
Therefore:
From above, seems nothing to do.
Observation: from above observe the Build project automatically option is disabled
Even with that disabled and after to restart the IDE, I must always stop manually the build process
So what is missing? or Do I need a special extra plugin to accomplish my goal?
The images that you show indicate that you are building with Gradle, but the Compiler option that you disable is relevant for building projects with Idea not with Gradle.
For the 2020.2 version, you need to do the following:
Open the Setting > Build Tools page.
Disable the "Reload changes in build scripts" option.
This way you can manually control the reload. When you change the build script, you will see a small gradle icon in the right side of the editor.
For more info, refer to the IntelliJ IDEA help > Gradle section.
https://www.jetbrains.com/help/idea/work-with-gradle-projects.html#auto_reload
There are two different things in IntelliJ's Gradle support that sometimes confused: sync and build. Your pictures demonstrate sync process (note caption on the toolwindow). Word build is kind of misleading here.
What is sync? In gradle we use Groovy to define the build procedure. Groovy is an imperative programming language, so it's hard to predict resulting dependencies graph without actually executing the script. During the sync Idea executes configuration phase of gradle build (one that builds dependency graph), and obtains configured objects from the Gradle daemon. This information is used to setup project in the IDE: modules, libraries, dependencies, which sources are test, which are prod, etc.
Actual build is not happening during sync. You can convince yourself by adding syntax error to any source file, and observe that the sync succeeds. But build will fail if you invoke it.
In answer to the original question: you can't disable automatic build, because it is not enabled.
Is it possible to disable sync in Gradle project? Short answer - no. If you need a code browser, which is not required to understand all the cross-references in the source code, IDEA is not the best choice probably.
TL;DR;
Without sync IDE does not know which files are sources, and which are not. IDEA cannot open folders. It only can open projects. Good thing is that module can contain folder. So you can do the following: File | New | Project. Select Empty project, Next, select some random folder outside the source folder you want to open, Finish.
Then add new module:
Select Java in the left panel, everything else keep default, Next, Finish. Then in new module remove existing content root, and add folder with sources as new content root
Resulting project is mostly useless. Tons of red code (at least, unresolved symbols from external libraries), no inspections, no navigation, no sense. But it might be useful in some rare situations indeed.
Presently having an annoying time getting a jar added to the external library for the project, then in turn not disappear when syncing and the imports working. Adding I figured out and answered in another question. The issue is to keep persistent and accessible to a jar I create within the project for import.
I am not sure if I am missing a step or forgot to set something. I am using a modified gradle (forgegradle) to create the project. Have not found a solution with the documentation, or any for IntelliJ yet. I am generally new with IntelliJ, choosing to use it instead eclipse which I have previously used.
The goal is a to create an add-on for a mod to another jar. The main jar already in the external library from the start, now attempting to add the mod to it. I could modify the mod, but it is not my code, so rather not simply modify it directly and repackage it.
a jar added to the external library for the project, then in turn not disappear when syncing and the imports working
If you are using an external build tool / system that syncs with IntelliJ it is recommended to use that build tool / system to add dependencies.
IntelliJ will always take a backseat, and treat the build tooling / system as the source of truth for the project model as best it can.
You mention you are using gradle, I would recommend adding the dependency as a managed dependency that is, let gradle download it from a repository, and resolve the dependency/library itself.
If you can not do this, and you can't host a repository yourself, The next best recommendation I have, is creating a 'libs' folder inside the project, that contains jars that can't be found in repositories (They may be mods or plugins that were never published)
You can read up on how to add a library folder to gradle here: How to add local .jar file dependency to build.gradle file?
I have a large multi module SBT project. One module is a Play2 project. Now, by default, IntelliJ IDEA excludes the whole target folder and IDEA's own compiler does not run the compile goal from sbt, but tries to figure everything out itself. This leads to important Play2 parts like routes and reverse routers not built.
When I run sbt compile from the console, these components are built, but since they are in the target folder which is excluded in IDEA by default, IDEA ignores everything in there.
Every time when switching Git branches (the Play2 project is only in one branch as of now) I have to go into the project structure and adjust the excluded folders manually.
Is it somehow possible to have IDEA figure this out by itself, and call sbt compile when rebuilding the project?
We are planning on restructuring a complex project with many modules/pieces, what ever you wanna call it. In order to move toward a standard directory structure, we would like to adopt the maven file structure.
So the big question is: Can anybody provide a description of the maven file structure, where we don't have to dig through all the maven speak?
Please see
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
src/main/java Application/Library sources
src/main/resources Application/Library resources
src/main/filters Resource filter files
src/main/assembly Assembly descriptors
src/main/config Configuration files
src/main/webapp Web application sources
src/test/java Test sources
src/test/resources Test resources
src/test/filters Test resource filter files
src/site Site
LICENSE.txt Project's license
README.txt Project's readme
BTW, we did that migration on existing projects.
It was a really long and hard task to make everything work as intended, but we are finally done and happy with it.
UPDATED
When you have many projects, you have the same structure for each project.
Now the real problem starts when you want to group them. We had a hard time reading Maven documentation and best-practices, and deciding what was the appropriate structure for us.
The basic idea would be to group related projects in a common directory (that we call a module), allowing to process the module as a whole without listing them. But if you open the module in an IDE (Eclipse in our case), the projects themselves belong to it, but are not opened as subprojects (that notion doesn't exist in Eclipse).
We ended up with a strict hierarchy, that freed us from many maven problems:
The actual coding projects (java projects) are always leaf in our directory tree. They are the only ones we open in the IDE. They are of type JAR, or WAR.
Their parents/modules are always of type POM. They have no java code.
I've been using the same approach as Jens on a number of projects both with Maven 2.2.1 and now with Maven 3.0-alpha-6: POM modules define the module structure of your project tree, JAR/WAR modules are the leaves of the tree. All modules have the same version.
Advantages:
You can
place properties or dependencies on
specific levels in the module
hierarchy and they will be inherited
to all sub-modules.
You can build
related modules simply by going to
the appropriate level in the tree and
running "mvn install" - Maven will
work out the correct build order
according.
Various Maven plugins such
as the release plugin rely on this
tree structure.
The latest Maven
Eclipse plugin can handle this
structure very well and will
represent the tree as a flat list.
There is an experimental feature in
the plugin which ensures that
so-called "shadowed" artifacts appear
only once which helps when searching
for resources in Eclipse.
Disadvantages:
Extension takes some time. For instance, if you decide that a JAR module requires sub-modules, you will need to convert the existing JAR module into a POM module and then distribute its contents to the newly created JAR sub-modules as POM modules cannot contain any code themselves.
All the POM modules will appear in Eclipse and can slow down the build somewhat. Hoever, you can close them and Eclipse will source them from the repository instead.