Community
Participate
Working Groups
We should define a Java code formatter profile to be used for all BPMN2 code. If we use this profile as a project-specific setting for all our Eclipse projects, everyone will automatically use the formatter. Furthermore, we could define an on-save action (Java-Editor->Save Actions) that formats the code upon save. This would avoid unnecessary reformatting when generating code and make it easier to identify what really changed. At the moment, we use the default Eclipse formatter with the following modifications: spaces instead of tabs for indentation and varying values for line width (160, 9900?). I'd say we keep the spaces and would propose 100 charactes as line width. Furthermore, the formatting differs between files in minor areas like indentation of statements within 'switch' and whitespace after cast - I would use the default settings here. Any comments? Otherwise I'd go ahead and define and apply the settings.
Created attachment 174376 [details] Proposed code formatting profile
As Reiner pointed out on the mailing list, we also need consistency regarding line endings (Windows vs. Unix). This can be configured via project specific settings, too. I have no preference and suggest that we use whatever is used at the time of enabling the settings (to avoid unnecessary changes).
OK with me. I recommend making those profiles at project level and committing the .settings directories. I also recommend creating a .gitattributes file. Profiles won't be enough to fix the problem at the git level.
OK, I will commit a .gitattributes file that will take care of converting eol characters. Git doesn't like CRLF line endings. We will have to use LF line endings - which means we will need to convert most of the files in the repository right now.
Done in 8b188b810dd33fc4181cf41c9bb63e6c501f192e. I haven't touched anything concerning line breaks. Antoine, is that still necessary, now that we have the gitattributes file? Do I have to set core.autocrlf or anything else in my local repo in order that it takes effect?
I'm -1 regarding .settings in the repo. A source code repository has nothing to do with IDE configuration files. They will change every time a developer changes any settings. That makes tracking actual changes to the "common .settings" really hard. I wouldn't even add the formatter settings to the actual source projects. I'd rather create a org.eclipse.bpmn2.settings project, that just contains all the setting files. After we have agreed on a common formatter settings file, we can think about checkstyle and findbugs configurations.
