ecco.properties should not be loaded from the class path

[arcanefoam]

Currently, when the Ecco Service is initiated the properties files is read form the class path. This means that if you want to provide a different configuration you need to change the ecco.properties file in the service project.
This file should be either:

1. Read from the repository folder, so the user can put it there. The issue with this is that the Ecco service is initiated once, and if the repository is changed then the different settings wont be changed
2. Read from an argument in the command line. This makes it possible to provide a properties file anywhere in the system. However, it suffers from the same issue that the service is initiated once.
3. If the above fail, then fall back to the class loader mechanism, effectively starting the service with a set of default options, i.e. all plugins loaded.. should this be the default?

Since you try to emulate a CVS repository, the above fit into the git approach: specific properties per repository (in the .ecco folder), global properties in the .git (.ecco) folder in the user home, default settings loaded from the service class.

[meik99]

The file could be watched using a WatchService and the Ecco service reinitialised as soon as it changes (and is valid).

I'd suggest having the properties file in the classpath as a template, which is written to a file in the .ecco directory which is then subsequently used. If the file changes are noticed by the WatchService, the Ecco service is reloaded, if the file is deleted or invalid at the point of opening the repo in the GUI it is regenerated.