Repository navigation
Allow Eclipse project-specific settings to be merged #444
Description
The Eclipse plugin allows custom project-specific settings to be provided. I'd like to customise a single setting (org.eclipse.jdt.ui.importorder in org.eclipse.jdt.ui.prefs) to align with configuring Checkstyle with a custom project root package. However, any custom settings file is used instead of the plugin's default org.eclipse.jdt.core.prefs and org.eclipse.jdt.ui.prefs files so I have to copy the plugin's defaults and modify them as needed. This has to be redone each time the plugin is upgraded to avoid missing changes to the defaults.
I'd like to be able to provide an Eclipse settings file that is merged on to the plugin's defaults. This should make it easier to use the plugin's defaults across upgrades and also make it clear exactly which settings are being customised.
Activity
GollapudiSrikanth commentedon Apr 28, 2026
Hi @wilkinsona
I’d also be happy to help with this enhancement if it’s still available.
My understanding is that the goal would be to merge project-specific Eclipse settings on top of the plugin defaults so users can override only selected preferences while continuing to benefit from default updates across plugin releases.
Please feel free to assign it to me if additional help is needed.
wilkinsona commentedon May 7, 2026
Thanks for the offer, @GollapudiSrikanth. Merging is a potentially complex topic and, when I opened the issue, I wasn't sure where to strike the balance between capabilities and complexity.
I think there are four things that someone might want to do:
1 is supported today and we ought to keep that functionality in case someone's relying on it. We'd then need to provide a way to opt in to merging. Perhaps a custom file suffix like
.mergeor.overlay? Once we have that, 2 and 3 are straightforward as they can be implemented by overlaying user-provided settings on top of the plugin's settings as you proposed in #472. 4 is harder and would require some way of indicating removal. I'm not sure if there's a concrete need for it so we may not want to support 4 for now. However, I think it would be good for 2 and 3 to be implemented in such a way that 4 could be supported in the future without breaking the way in which 2 and 3 work.