Bug 373205 - Project-specific Members Sort Order
Summary: Project-specific Members Sort Order
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.8   Edit
Hardware: PC All
: P3 enhancement with 3 votes (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-04 14:58 EST by Alexander Karatarakis CLA
Modified: 2019-01-26 13:07 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Karatarakis CLA 2012-03-04 14:58:07 EST
Build Identifier: Version: Indigo Service Release 2 Build id: 20120216-1857

Window->Preferences->Java->Appearance->Members Sort order

The settings in this menu define the order of the members in the code when you apply cleanup/Save_actions.
However, they are not project specific, which means that problems arise when:
- Various developers with different settings work on the same class (reorderings are constantly applied)
- You need different settings for each of your projects
- You want to share those settings with other developers through version control

It would be nice if this could be project-specific like many other settings relevant to code-style/conventions/etc already are.

Reproducible: Always

Steps to Reproduce:
N/A
Comment 1 bjarne Boström CLA 2017-02-16 02:33:29 EST
+1, still a problem (Neon 4.6.1)

It is possible to export clean up formatter as xml with the members sort order active, however how that it applied depends on the global Members Sort order setting. Assuming anything others than the defaults are used (and that defaults would never change), this requires that each developer must know to change the setting. If different projects use different settings then developers must switch this setting when working on a different project.
Comment 2 Emmanouil Trypakis CLA 2019-01-26 13:07:20 EST
I'd like to add my support to this. Every time you start a new workspace you have to remember to configure that, otherwise your coding conventions are breached and you just pollute your commit history in a constant back and forth between developers with different workspace settings.