We have a Java project in small team, all developers use Intellij IDEA.
I need to setup code style so that
some settings (for example use tabs instead of spaces, import order, threshold for asterisk import etc.) are common for all developers, these settings are obligatory and versioned in Git
tab size setting is up to each developer since it affects only appearance on his screen and not source code. It should not be versioned. Technically it should override common setting (actually its value should not be among obligatory values at all).
How to achieve it?
My attempts:
I am aware of "Stored in Project" vs "Stored in IDE" configuration where the first one is recommended to be in VCS. However, if I define common settings as "Project" configuration, user can define custom "IDE" setting and activate it instead of the "Project" configuration, not on top of it.
We also have .editorconfig file in project root with some common settings. Since the file is versioned in Git there would be great to have something like .editorconfig-gitignored file with custom settings (or put .editorconfig one level down into each subfolder, which is clumsy)
Since Intellij Idea can override project settings with .editorconfig settings, it seems to be a solution to define common settings in Idea and custom setting in (newly gitignored) .editorconfig file. Unfortunately some properties in .editorconfig are mandatory as well so I feel it would be downgrade at this moment.
Related
I develop plugin for IntelliJ. How can I modify custom properties for my plugin tests?
For example I want to set idea.max.content.load.filesize property to, say, 100MiB
These are system properties, so java.lang.System#setProperty
Depending on the properties you wish to modify, you may be able to use idea.properties, which contains the "default properties used to run IntelliJ IDEA" (per the link you provided). To modify the file, you go to Help > Edit Custom Properties... (see these steps).
For example, I used this approach to address a problem where my machine's security software was blocking plugins that used IntelliJ's default config directory (C:\Users<user>\AppData...).
This is the Windows OS default Application Data directory and is included in the paths scanned by the security software. By moving my idea.properties file to a different directory (c:/development/idea/caches/), not automatically scanned by the security software, my plugins were no longer blocked.
It's a different use case from what you're describing, but may be an approach worth looking into.
I want to set code style for the project so that all the developers of the project format the code the same way. All of the team uses IntelliJ. When I add my style in the file
/myproject/.idea/codeStyleSettings.xml
the IDE creates the file
/myproject/.idea/codeStyles/codeStyleConfig.xml
with the contents
<component name="ProjectCodeStyleConfiguration">
<state>
<option name="PREFERRED_PROJECT_CODE_STYLE" value="Default" />
</state>
</component>
Will the default settings override my code style settings? Should I use the same component name in my settings file to override the default one?
In addition to those, I see a codeStyle.xml file in the root directory of some well-known java libraries such as https://github.com/qos-ch/slf4j , is it for another IDE or does that also have an impact on formatting in IntelliJ?
By the way, I think generally code style config is confusing if not mess, there is also IDE level global settings and I think/hope it will be applied when there are no rules for a specific option, right?
Intellij IDEA 2017.3 has got new project code style settings format. Now all code style settings are located under <PROJECT_ROOT>/.idea/codeStyles directory with the ultimate intention to support multiple project code styles linked to different scopes. New code style settings format is also cleaner and contains all code style settings properly grouped per language. Some old legacy Java, HTML settings previously stored without any language tag are moved to "JavaCodeStyleSettings", "HTMLCodeStyleSettings" etc. respectively.
The old .idea/codeStyleSettings.xml is imported into two new files: .idea/codeStyles/codeStyleConfig.xml containing a link to preferred project code style and .idea/codeStyles/Project.xml with code style settings for different languages. The latter is optional and created only if there are non-default settings. If .idea directory is under version control, both files can be added to VCS too. The old codeStyleSettings.xml is kept for backwards compatibility.
Original answer (now obsolete):
.idea/codeStyleSettings.xml stores the project specific code style that is for sharing with the project so that all the team members have the same code style applied automatically for this specific project. Check this answer for details.
.idea/codeStyles/codeStyleConfig.xml is used to override the default project code style.
By default it contains <option name="USE_PER_PROJECT_SETTINGS" value="true" /> so that project specific configuration from .idea/codeStyleSettings.xml is used. If you switch your code style settings to use a scheme stored in the IDE instead of the project scheme, this file will store your choice.
IntelliJ IDEA also has support for .editorconfig which will have the priority and override IDE and project scheme by default. Check the documentation for more details.
codeStyle.xml in the project root is for Eclipse IDE and is not used by IntelliJ IDEA. It can be probably used by IntelliJ IDEA as well, if you have Eclipse Code Formatter plug-in installed and configured accordingly.
A little intro:
I work on a project with legacy codebase witch uses internal xml based descriptors with specific file extensions (about may be 10 extensions).
Let it be *.desc, *.check etc.
To have code highlighting for such a files I can configure Idea to consider these types of files as XML.
It's available through:
Preferences / Editor / File types
And then add all custom extensions to 'Recognized file types': 'XML'
Our project uses gradle as build tool
and my question is:
Is it possible to make same configuration via dsl of gadle 'idea' plugin?
The short answer is: No.
One could create a custom Gradle task that will modify IDE file type preferences XML file in the config directory. While it's possible to run such task automatically on the project refresh in IntelliJ IDEA, it will most likely not work since you can't modify IDE configuration when IDE is running (the changes will be reverted). So, you will have to run it from the command line, outside of IntelliJ IDEA when IDE is not running.
It's probably not what you want, but if documented, can be used by the team as the manual step to make this configuration change easier.
Using gradle idea is not recommended anyway.
A better way might be to provide your own IDE plug-in that will associate these file extensions with XML file type and instruct the team to install this plug-in.
To execute my application, or run or debug unit tests, I need to enable various VM options, include -javaagent:<aspectjweaver-path> or -Djava.library.path=<some native lib path>
I can see how to change these configurations manually in IntelliJ IDEA under "Edit Configurations..."
What, if anything, do I need to check in to my VCS to share these settings with other members of my team, and ensure they pick them up automatically whenever someone changes them in the VCS?
Alternatively is there a way to set these automatically in IntelliJ without even touching the edit configurations? Especially the aspectjweaver. When I build/test my project from the command line using maven this is all handled for me by specifying argLine arguments to the surefire plugin, but IntelliJ doesn't respect these settings. Perhaps there are alternative plugins that can help me out?
First, you need to share your run configuration. It's simply done by checking the Share box right to the configuration name in the run configuration dialog:
Your run configuration will then be saved to .idea/runConfiguration (or whatever your settings folder name is).
From Jetbrains Web Help:
If this check box is selected, the run/debug configurations become available to the other team members.
The shared run/debug configurations are kept in separate xml files under .idea\runConfigurations folder, while the local run/debug configurations are kept in the .idea\workspace.xml.
This field does not appear for the default run/debug configurations.
I have just set up three different configurations in my project for debug preview and release. No in Xcode there is an option to specify different .xconfig files per configuration. I am now wondering in what circumstances they should/could be used and what their advantages are over just editing the build settings per configuration.
Use xcconfig files if you find yourself changing the same build settings for each project you create. Place the build settings you're changing in the xcconfig file. By using a xcconfig file you can avoid editing those build settings every time you create a project.
Having the option to use different xcconfig files for each build configuration allows you to place the debug build settings you're constantly changing in one xcconfig file and place the release build settings you're changing in another xcconfig file. Use multiple xcconfig files if the build settings you're changing have different values for debug and release builds or if you change some build settings only for debug builds and other build settings only for release builds.
It's not me who you asked about an example #Besi but I would like to explain why the BundleId change is useful at least for me.
When I have different requirements for "Development", "Ad Hoc", "App Store", for example I need to send Push Notifications, so the push certificate will be different depending on the version.
In this case I can make 3 different XCode schemes and depending on the chosen scheme, when compiling the bundle identifier will change so a different kind of version will result.
Add to this the fact you can use you xcconfig to choose the "Code Sign Identity", and practically every build setting you can imagine. This way is more correct than having different targets for each version and with different plist files and build settings, because you avoid duplication and you can customize the way the settings should override each other.
Sorry if this is very convoluted, I tried responding the original question in the process.
One way I've used xcconfig files is to set up different BundleId's for iPhone apps. That way you can have different apps with different features/servers enabled. Very helpful. It involves using a variable name for the BundleId.