Harmonizing Java Compile and Save Action Settings

[azoitl]

In the last days I noticed that each project in GEF Classic seems to have their own Java compiler as well as own save action clean-up settings. These are partly different between the projects and in general a bit outdated.

I'm now considering to harmonize and update these. For that I'm not sure what would be the best way. One option we are using in Eclipse 4diac is to have no project specific settings at all and have the workspace settings exported (epf file) which every developer can then import. For us this works nice but I'm not sure if this is a good idea.

But maintaining the same settings over all our projects to be seems also not a good approach.

What are other best practices? Did I miss anything?

\cc @vogella @pcdavid @Phillipus @Destrolaric @ptziegler

[ptziegler]

I'm usually not a fan of redundancy, so having a global configuration sounds preferable to a configuration for each project. However, I also don't like to manually set the project settings.

I wonder if it's possible to create an epf file and load it as part of the Oomph setup tasks... 🤔

[pcdavid]

OTOH, preferences are global to the workspace, so this means if one has multiple projects (say, GEF Legacy and GMF Runtime) in the workspace, the settings in the .epf would apply the GEF Classic preferences to all other projects.

Although I'm not a fan of redundancy either, this is why for most/all the projects I maintain I use project-specific settings and commit them in the repo. They do not change that often, and usually when they do I make the changes needed in one project and copy its whole .settings to all the others.

[azoitl]

@pcdavid these are important and good points. Thanks for pointing out the combination problem. I definitely would have that in may daily workflow.

I also was not aware that I just can simple copy the .settings files. This looks as a very simple and straight forward approach. If no one objects I would go with that after I clarified the status of my pending PRs and the few I have in the pipeline.

[azoitl]

I forgot to mention the issue in my PR. With PR #228 this issues is addressed and can be closed.