File is parsed, but no settings applied.

[ams-tschoening]

I'm pretty sure to use your plugin as described and can see on Windows that .editorconfig is parsed by some Java process. Additionally I see different behaviour of Java in case root = true is present in the file vs. when it is not: If it's present only one .editorconfig is parsed, if it's not the directory tree is searched upwords for additional files until C:\.editorconfig, which is not found in the end.

Running the task cleanEclipse as well deletes all your managed files, while the task eclipse generates all of those containing the line with the version number only. I've already compared behaviour of both tasks with/without your plugin and there's a difference as well, because some of the prefs-files are only created by your plugin, not the one name eclipse already.

But whatever I put into .editorconfig, besides root = true nothing seems to be recognized and I already only copied the examples from you. I don't even get any errors logged, it simply seems that all statements are completely ignored, not with wrong values.

Any idea what could be the problem? Are there any logs available for EditorConfig?

Thanks!

[stempler]

Hi,

the plugin converts the settings in the EditorConfig file to settings in the Eclipse project. So you can check in the .settings folder if everything is configured as it should. You might have to refresh your project in Eclipse for it to take effect.

For example, indentation settings should land in org.eclipse.jdt.core.prefs, in case of the configuration in this repo, there should be settings like these in there:

org.eclipse.jdt.core.formatter.tabulation.size=2
org.eclipse.jdt.core.formatter.tabulation.char=space
org.eclipse.jdt.core.formatter.indentation.size=2

You can also verify the project settings in Eclipse (first refresh) in the project properties, in different sections there (e.g. Resource for the file encoding and line delimiter, Java Editor/Save Actions for removal of trailing whitespace).

The root setting should always be true if you do not have any editorconfig files in the parent folders. Apart from that, it is important to what files you apply your settings, here it is to any file. Unlike other EclipseConfig plugins here we can't do a per-file configuration, as the project settings don't support that. So the EclipseConfig configuration for a Java file in the project root is used to determine the settings - but with the example from this project that should work without problem.

[ams-tschoening]

I was able to get EditorConfig to throw an exception because of malformed keys in the section [*]:

09:54:35.263 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] > Failed to apply plugin [id 'org.standardout.eclipseconfig']
09:54:35.263 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]    > charset  utf-8

So not only the file is parsed, but the section as per your documentation as well properly recognized and the line for the charset is read and most likely parsed and stored.

[ams-tschoening]

the plugin converts the settings in the EditorConfig file to settings in the Eclipse project. So you can check in the .settings folder if everything is configured as it should.

I'm looking at your files already and they are deleted and created as necessary, depending on the task I execute in Gradle. But the important content is missing, the only thing written to the files is the following:

eclipse.preferences.version=1

The only files with additional content are the following, not managed by your plugin:

org.eclipse.buildship.core.prefs
org.eclipse.jdt.core.prefs

It seems that simply all settings of .editorconfig are ignored by your plugin, but properly parsed by EditorConfig itself, because of the formerly mentioned exception for test purposes.

Some tracing output for the settings retrieved by EditorConfig might have been a good idea to see if anything is available at all. I e.g. don't get error messages from your plugin because of a wrong charset if I use values like murks for those. That can only happen if I look at the wrong place for that error message or if charset is simply not part of the settings you work on for some reason.

[ams-tschoening]

I've finally found the problem: I'm using Windows, your plugin passes native Windows paths using \ as separator and EditorConfig doesn't support that and seems to match no section. Changing \ to / before passing the path to EditorConfig works as expected.

11:01:56.533 [ERROR] [org.gradle.api.Project] C:\[...]\Dummy.java -> C:/[...]/Dummy.java
11:01:56.535 [ERROR] [system.err] .*/[^/]*
11:01:56.538 [ERROR] [system.err] .*/[^/]*
11:01:56.538 [ERROR] [org.gradle.api.Project] [:] -> [charset:utf-8, trim_trailing_whitespace:true, indent_style:space, indent_size:2, tab_width:2]
11:01:56.543 [ERROR] [system.err] .*/[^/]*

The outputs on STDERR are from EditorConfig by setting the following on the shell:

set JAVA_OPTS=-Deditorconfig.debug=true

These are the regular expressions matched against the paths and as you can see, those are using / instead of \, but there doesn't seem to be any code normalizing paths to use that.

https://github.com/editorconfig/editorconfig-core-java/blob/master/src/main/java/org/editorconfig/core/EditorConfig.java#L224

Should I create a PR for you and report the problem to EditorConfig or only the latter? In my opinion EditorConfig needs to handle such things more compatible, but you might be able to release sooner.