Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 319957

Summary: Define code formatting profile
Product: [Modeling] MDT.BPMN2 Reporter: Henning Heitkoetter <hheitkoetter>
Component: CoreAssignee: Project Inbox <mdt-bpmn2-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3 CC: antoine, beneritter
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Proposed code formatting profile none

Description Henning Heitkoetter CLA 2010-07-15 05:08:29 EDT 
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.
Comment 1 Henning Heitkoetter CLA 2010-07-15 05:12:00 EDT 
Created attachment 174376 [details]
Proposed code formatting profile
Comment 2 Henning Heitkoetter CLA 2010-07-15 08:56:32 EDT 
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).
Comment 3 Antoine Toulmé CLA 2010-07-15 10:18:01 EDT 
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.
Comment 4 Antoine Toulmé CLA 2010-07-15 10:42:35 EDT 
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.
Comment 5 Henning Heitkoetter CLA 2010-07-17 09:17:01 EDT 
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?
Comment 6 Benedikt Ritter CLA 2012-03-25 07:47:10 EDT 
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.