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.
Related
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.
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 need to turn Eclipse fragments into plug-ins. Haven't found any wizard to support this.
So I've created a plugin.xml and edited the MANIFEST.MF to look exactly like a plug-in project does. Still, Eclipse somehow detects it's not a plug-in: for example it asks for a Host-plugin.
Also checked .project file, nothing seems to indicate "fragmentness".
Why I need this:
Fragments were used for Unit-testing; but they're rather inconvenient: any modification in them triggers a chain of builds, and they block the exporting of individual plug-ins, unless their project is closed.
Solution
As Greg suggested it was the 'Fragment-Host:' option that did the trick. And as Rüdiger wrote; the project had to be closed/reopened for eclipse to acknowledge the change.
The fragment host is specified in the fragment's MANIFEST.MF:
Fragment-Host: host.plug.in
you will need to remove that.
However many fragments rely on code from their host plugin so it may not be possible to just convert the fragment.
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.
As the title suggests, is there any documentation that describes what the content of the configuration files should be? anything from an xsd to a reference manual regarding it's structure would be helpful.
I am researching how to automate the setup of my idea workspace using gradle's idea plugin.
After some correspondence with JetBrains Staff, I discovered that the XSD files are not available for public viewing.
an excerpt from the email:
"There is no complete references or XSD for these files. The format is internal and is not > designed for others to reuse."
If you want to generate projects, consider using Maven or Gradle, generate the files for these tools that IDEA will be able to import them.
Either that means JetBrains don't want you playing with their configuration files (I don't know how Gradle knows what to do) or the structure is subject to change and shouldn't be modified for backwards compatibility purposes (Say intellij updates their IDE and the config files are modified with a new structure, any programs designed to modify according to a previous structure may be invalid).