[INTERNAL] Ignore encoding configuration files

[tobous]

Amends the Saros/E and Saros/I resource implementation to ignore files defining the encoding for shared resources. This was done to prevent issues caused by differing base-encoding settings which could cause the desynchronization of such files.

The encoding management of shared files that are created during the session is completely done by Saros, meaning we are not reliant on such configuration files.

The encoding management of files created as part of the project negotiation has not been adjusted yet and is therefore not managed by Saros. See issue #912.

[tobous]

The logic in this PR should be valid, but I still have to do some more testing in which cases sharing the encoding files leads to problems.

If it only leads to problems if the users don't have a default encoding set and their system encoding differs, this might be an acceptable usage restriction.

If, however, issues also occur in a setup where both participants have the same project encoding set, this filter is necessary.

[tobous]

Any plans regarding .project file, classpath etc ? I know this will upset some people as you will have to manually configure the project after receiving it. Of course we could add a feature that will share such information on initial project setup.

Kind of. The current plan was to introduce a version control system integration (mainly git but extendable to support other systems) for the logic to determine what to share (which is currently determined by the "derived"/"excluded" IDE flag). This would allow us to follow the versioning system in what to share, which is especially important for the IDE configuration files. But it looks like I won't have time for it as part of my master's thesis, so it will be moved back.

In general, it is not that easy to determine whether such files (like .project and .classpath files) should be shared or not. They don't necessarily have to be under versioning but rather can be generated dynamically when needed. The Saros project is a good example for this. Such configuration files are ignored by git and are rather generated by gradle when calling prepareEclipse. So, if I am sharing the project from Saros/I to Saros/E, those files don't necessarily have to exist, meaning the receiving user will have to do some local setup anyways. And this is a relatively simple case. With the plethora of possible (potentially more complex) build/integration setups, I don't think it is a viable option to offer IDE integration.

The big question would be whether Eclipse detects and uses such configuration files on its own or whether they have to be manually loaded (by Saros or the user).