Issue 96 - fixes to setup an Eclipse IDE for contribution without Eclipse error markers

[mhoffrog]

After merging this pull request the procedure for setting up an Eclipse environment for contribution is as follows:

1. git clone this repo to a local directory named "pdt"
2. Install Eclipse IDE for Eclipse Committers
3. Start Eclipse IDE
4. Select File / Import ... / Maven / Existing Maven Projects
5. Browse/Select the cloned repo folder and click Finish
6. Expand project org.eclipse.php.target.current, double click "org.eclipse.php.target.current.target"
7. Click on "Set as active target platform" (upper right corner of the target editor)
8. Right click the "pdt" project
9. Select Run As / Maven / generate-sources
10. The IDE must now be ready for development without any error markers

[zulus]

In theory those files are from era without Maven Tycho.

You decide to remove .settings/org.eclipse.jdt.core.prefs, due this, due this if someone use not-default settings in eclipse (like me ;)), each edition will provoke new way of formatting.

Same for .settings/org.eclipse.jdt.ui.prefs, we will loose control on auto-fixes (on save), between workspaces.

Last problem, from my point of view is deletion of .project, especially plugins/org.eclipse.php.core/.project. This file force enable api change check (in compare tu launch configation), and force parse regeneration during eclipse-run. Did you solve this in different way?

[mhoffrog]

In theory those files are from era without Maven Tycho.

You decide to remove .settings/org.eclipse.jdt.core.prefs, due this, due this if someone use not-default settings in eclipse (like me ;)), each edition will provoke new way of formatting.

Same for .settings/org.eclipse.jdt.ui.prefs, we will loose control on auto-fixes (on save), between workspaces.

Last problem, from my point of view is deletion of .project, especially plugins/org.eclipse.php.core/.project. This file force enable api change check (in compare tu launch configation), and force parse regeneration during eclipse-run. Did you solve this in different way?

To be honest I did not have a detailed look into the one or other .settings file - same for .project.
The Maven import procedure did affect all of them, since Maven import is adding Maven nature to the .project files and it is creating particular .settings files containing e.g. absolute paths. So I made my life easy by removing all of them and let Maven import create the defaults.
I fully agree with your concern! so the solution would be to keep those .settings, that are essential for what you mentioned and to keep the .project files where needed. I would like to have a review then and update my pull request with additional commits to fix that.
@zulus If possible - can you let me know, what .settings files should be kept and what .project files (or all .project files?
I guess the .project files would be less critical just once to commit them after the Maven nature has been added).

[mhoffrog]

@zulus With the three subsequent commits I did revert the commit of the .project and .settings removal. I only did remove the .classpath files and added those to .gitignore. The .project files did have been committed with the Maven nature and Maven build spec added - this is performed automatically by m2e during Maven import.

Regarding the .settings adoptions made by my Eclipse runtime I found a lot of settings due to maybe newer Eclipse features than the one the current settings have been committed with.
So I did not commit any of those changes yet and I think that this will be a boring task all the time Eclipse is coming up with new features contributing into the settings - even by default.
My preference would be, to manage the settings by an appropriate Eclipse installer / oomph setup configuration maintained for this project, which could also be maintained in this or in a separate repo.
This would then guarantee that any setup is configured consistently, since we would be able to define the selectable Eclipse versions and all p2 bundles needed to be setup for a contributor. By that the initial setup could be fully automated including the git clone of this project, the Maven import, the selection of the effective target and the initial generate-sources task.
This would then allow to get rid of committing the .settings into this project and adding it to .gitignore. There would then also be no more git modification markers to the projects due to .settings modification only.