Convention over configuration for formatter files

[markiewb]

trafficstars

How about autodetect configuration files?

Like it is done with for CI/CD using Jenkinsfile, gitlab-ci.yml or .travis.yml, which are files in the root of the project. Jenkins/Gitlab/Travis look for these files and use them as their pipeline definition, if they exist.

If

• .settings\org.eclipse.jdt.ui.prefs
• .settings\org.eclipse.jdt.core.prefs
• ...

exist in the root of the project/module, use them without any configuration in this plugin. The plugin should pick them up automatically and use it as configuration.

This way after opening a project (with the file(s) in the proper location(s) and the plugin installed) the dev can develop, without configuring the plugin itself. It would simplify the workflow for new developers in the team or contributors to OSS-projects. It is even portable between Eclipse and IDEA, because the plugin uses the file paths defined by Eclipse (.settings/...pref)

@krasa: What do you think?

[krasa]

Sounds good, will you implement it?

[markiewb]

Yes, I will propose a PR.

I am not 100% sure about handling mixed modules in one IDEA project from different git repos. I can think of a preference mechanism, where the nearest configuration wins

Example

Shop-Multimodule (from Git-Repo 1)
+--.settings/*.prefs    [B]   
+--Shop-API-Module
   +--.settings/*.prefs [A]
   +--src/main/java/Shop.java 
Catalog-Multimodule (from Git-Repo 2)
+--.settings/*.prefs    [C]
+--Catalog-API-Module
   +--src/main/java/Catalog.java 
Customer-Multimodule  (from Git-Repo 3)
+--Customer-UI-Module
   +--src/main/java/Customer.java 

If Shop.java needs to be formatted, then use A rather than B If Catalog.java needs to be formatted, then use C If Customer.java needs to be formatted, then use the configuration from the plugin options or show an error notification of missing configuration (= current implementation)

Does it sound reasonable?

[krasa]

yes, that makes sense.