I would like to know how to change the default java module structure in IntelliJ IDEA from:
module_name/src
Where src is marked as 'sources', to:
module_name/src
/main/java
/test/java
Where main/java is marked as sources and test/java marked as test sources.
Is there a way that I can make this the default so I don't have to manually do it each time?
You can create a project set up to your specifications and then save it as a template that will be available when you create a new project.
See the IntelliJ documentation for [Saving Project as Template]
(https://www.jetbrains.com/help/idea/save-project-as-template-dialog.html).
The right way - create a pom.xml and reorganise the source so that it will work with maven. After it - just import pom.xml into Idea, it will recognise maven project structure automatically.
The manual way - use "Module settings" -> "Sources" and manually change the source folders for your structure. See the screen example here http://wiki.jetbrains.net/intellij/File:Project_structure_dialog_left_hand_pane.png
Related
In my project I'm using the spring-boot-configuration-processor to generate configuration metadata, which can be helpful at setting fields in #ConfigurationProperties marked classes from .properties files.
As build system I use Gradle.
The configuration with JavaDoc in class looks like this:
#Configuration
#ConfigurationProperties(prefix = "user-config")
public class UserSettings {
/**
* User name.
*/
private String name;
// getters & setters
}
And I import spring-boot-configuration-processor dependency in Gradle like this:
annotationProcessor group: 'org.springframework.boot', name: 'spring-boot-configuration-processor'
The problem is that IntelliJ IDEA can't find generated file spring-configuration-metadata.json, which is putted into folder /build/classes/java/main/META-INF when executing build task from Gradle.
I did some research, and found out that IDEA uses out/production/classes path for production output, but Gradle uses build/classes/java/main path.
Then I came to this SO question, where I found a solution: https://stackoverflow.com/a/55516113/8521177. As pointed there, there are two solutions:
Configure the Spring Boot Annotation Processor manually in IDEA (which is unacceptable, because it would force to do so everyone, who works in my project)
Set IDEA output path to the same as Gradle path as pointed in this answer: https://stackoverflow.com/a/46420842/8521177, so IDEA will find the spring-configuration-metadata.json generated metadata file.
And the another is to put generated file in src/main/resources/META-INF manually and deploy the app with the file in this folder.
The second solution is worked out, but then in the same answer in comments I saw the #CrazyCoder's response - Intellij - set default output path to gradle output, which is saying that gradle idea is obsolete and the one should use 'delegate' option in IDEA. I turned on this option, and IDEA now produces output in the same folder as Gradle do, but IDEA again can't find generated metadata file, since output path again is set to out/.
So, what is the right solution to make IDEA recognize this generated file, considering that I don't want to force user do something manually?
P.S. - Also, I have the following automatically added source path: build/sources/annotationProcessor/java/main. I don't know what is it and where it came from, the folder is empty, but can be there solution with it? Maybe if I can make spring boot configuration processor produce generated file in this folder?
UPD: I use IntelliJ IDEA 2019.1.3 (Ultimate Edition), Gradle 5.4.1, Spring Boot 2.1.5.
Let's assume there are two Maven Java projects, A and B. A has a dependency on B. B is placed in remote Maven repository and also on GitHub.
In IntelliJ Idea IDE, I will open project A and also B (B is cloned from GitHub) in two separate windows.
Now, B has a class named Car. When I 'Ctrl+Left mouse button click' on class Car in project A, IDE switches me automatically to the source code in opened project B. Therefore I can comfortably work together on A and B.
How can I achieve same behaviour with .NET C# and Visual Studio?
The rough equivalent to Maven in the .NET ecosystem is NuGet. NuGet files can be created using the IDE or command-line tools such as dotnet pack or nuget pack. A NuGet file is just a regular .zip file with the .nupkg extension. These files can be hosted on http://www.nuget.org for the general public to consume, on a site such as http://www.myget.org, or on a private hosted NuGet server.
The NuGet tools also have the ability to create debug symbol packages that contain the source code files. The debug symbol packages can be hosted on public or private symbol servers and used in Visual Studio to step through the code, with the configuration options enabled in Visual Studio.
If you open project A in Visual Studio and automatic package restore is enabled and that project has a package reference to project B, when you build the project it will automatically download the NuGet file for project B, unpack it to your local NuGet cache, and use the assembly for project B in your project.
If Visual Studio is configured correctly to find a debug symbols package corresponding to the exact version of project B, it will allow the debugger to step through the code of project B.
AFAIK, opening the code file of project B and then setting a break point is not possible (someone leave a comment if this is wrong), you need to set a breakpoint in project A and then when you step into the line that calls/instantiates the Car class, Visual Studio will open up the code file so you can step through it.
Update 2023-01-15
Note that the above symbols documentation still works, but there is now a better way. If the author of a NuGet package configures Source Link and the code exists in a Git repository, an IDE can enable source stepping and the code files can be downloaded directly from the repository into the IDE's debugger. This means it is no longer necessary to package source files in the symbols package. This feature uses a Git commit hash to ensure that the source code matches the binary even if you upgrade the NuGet package later.
The symbols have also been updated to allow a .snupkg file by including <PropertyGroup><IncludeSymbols>true</IncludeSymbols><SymbolPackageFormat>snupkg</SymbolPackageFormat></PropertyGroup> in the project file. This new format can be uploaded directly to NuGet instead of having to use a 3rd party symbol or self hosted server for debugging.
Well, actually it is possible. But some MSBuild modification is necessary.
Preconditions:
use the new MSBuild format that was shiped with VS 2017
Step by step:
create a solution and add both projects
I assume project A has a package reference to project B and the nuget package names are the same as the project names
in the root directory of both projects, which is probably not part of any source control system, create a file with the name Directory.Build.targets with the following content:
true
<PropertyGroup>
<SolutionFileContent>$([System.IO.File]::ReadAllText($(SolutionPath)))</SolutionFileContent>
<SmartSolutionDir>$([System.IO.Path]::GetDirectoryName( $(SolutionPath) ))</SmartSolutionDir>
<RegexPattern>(?<="[PackageName]", ")(.*)(?=", ")</RegexPattern>
</PropertyGroup>
<ItemGroup>
<!-- Keep the identity of the packagereference -->
<SmartPackageReference Include="#(PackageReference)">
<PackageName>%(Identity)</PackageName>
<InSolution>$(SolutionFileContent.Contains('\%(Identity).csproj'))</InSolution>
</SmartPackageReference>
<!-- Filter them by mapping them to another itemGroup using the WithMetadataValue item function -->
<PackageInSolution Include="#(SmartPackageReference -> WithMetadataValue('InSolution', True) )">
<Pattern>$(RegexPattern.Replace('[PackageName]','%(PackageName)') )</Pattern>
<SmartPath>$([System.Text.RegularExpressions.Regex]::Match( '$(SolutionFileContent)', '%(Pattern)' ))</SmartPath>
</PackageInSolution>
<ProjectReference Include="#(PackageInSolution -> '$(SmartSolutionDir)\%(SmartPath)' )"/>
<!-- Remove the package references that are now referenced as projects -->
<PackageReference Remove="#(PackageInSolution -> '%(PackageName)' )"/>
</ItemGroup>
</When>
What happens here, is that all package references are automatically dynamically replaced with project references, when they are contained in the currently opened solution.
For further information, i have posted that solution also in a MSBuild github issue:
https://github.com/dotnet/sdk/issues/1151
We have this project setup for eclipse that I'm now trying to import into IntelliJ.
I've tried using the eclipse import in IntelliJ but that fails, I suspect it's because the person who set up the project decided there shouldn't be a src-folder and instead named it after our course, tddc17...
The structure looks like this:
- project
- lib (contains two jars)
- tddc17
- MyVacuumAgent.java
Now I've set up the jars as modules in IntelliJ and when I configure the run I can find the entry point so that's all good. The project also builds as it should but the problem is when I try to run it.
In one of the jars it tries to find "tddc17.MyVacuumAgent.java" which it then can't find.
I can't edit the jar so I can't change that, so what I need is a way to set it up so that it can be found. When building there's an out directory created with the structure:
- out
- production
- lab1 (name of the project in IntelliJ)
Could that be the issue?
Figured out the problem.
since it looked for tddc17.MyVacuumAgent.java it was expecting that to be part of a package. Which it wasn't. So I added package tddc17 at the top of the file. THis gave me an error but using alt + enter to let IntelliJ fix it created yet another tddc17 folder inside the existing one and now it all works.
I have a directory structure like the following, which holds source code for several "projects" I worked on in Eclipse so far:
project/
project/ivy-cache <-- libraries
project/module_1/src
project/module_1/test/src
project/module_1/test/integration/src
project/module_2/test/resources
project/module_2/src
project/module_2/test/src
project/module_2/test/integration/src
project/module_2/test/resources
...
How do I import this structure into IntelliJ in a sensible way? module 1 depends on module 2...
Ideally, I'd like to start with the settings from scratch, so I don't take any of the Eclipse stuff along that I don't need...
Motivation:
I'd like to try if compile-time annotation processing fits my problem. It needs to work out of the box, no compiler arguments etc.
Current state:
I have:
The annotation
An annotation processor
A .jar containing both of these and a javax.annotation.processing.Processor file containing the FQCN of my processor in META-INF/services
What should happen:
It should autodetect the processor
It should process the annotation and create a new class (WiredAnnotated)
I should be able to use this class in one step of compilation (not multiple phases)
I wan't the editor to accept this class is generated (e.g. AndroidAnnotations manages this as well)
What actually happens:
It autodetects the processor
It creates a new class (in out/production/*/generated/)
I am able to use this class
The source code looks right
When decompiling it looks ok too
The editor cannot resolve the class (see screenshot)
What I tried:
Restarting IntelliJ
Invalidating caches
Checking for output of the annotation processor
Screenshot:
When compiling, it actually works as expected. I guess it has something to do with inspecting the wrong directories.
Does anyone have an idea/clue on what I'm doing wrong? Did I miss information which could help you help me?
Thanks in advance, Till
Well, you need to add you out/production/*/generated/ to projects source folder. So, IntelliJ will know about your generated classes.
You can make it via Right click on directory > Mark directory as source root.
or
Project structure (F4) > Modules > Sources tab > Source folders should contain all directories with your source codes, generated one inludes.
In android there is a gen dir in root folder, but notice, it glows blue or green which means it marked as Source folder, it is also visible in Project structure > Modules. It contains R, BuildConfig and Manifest.