tian-zhihui / caas

Automatically exported from code.google.com/p/caas
GNU General Public License v3.0
0 stars 0 forks source link

caas.conf file lookup #6

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Feature I would like to see:

One of the enhancement or change that I wanted to do to caas framework is to 
look up of caas.conf file. 
 Currently it looks at user home directory. But I wanted to change to look 
First at current directory
If not then look at user's home directory
The main reason for this change is, ideally when cordys has to be configured in 
multiple environments, then all the configurations files along with the 
libraries can be zipped and give it to the configuration team.
Then the files will not be scattered in multiple places. 

Impact if not implemented:
Files scattered in Multiple places

Alternatives:

Keep the caas.conf file in user's home directory

Original issue reported on code.google.com by phanisri...@gmail.com on 14 Mar 2011 at 4:02

GoogleCodeExporter commented 8 years ago
I agree that the current mechanism is not optimal, especially not on windows. I 
wanted to improve it for some time, so glad to see you take it up. I had a bit 
different idea though, but it might be combined. The idea is based on ho I 
perceive many UNIX tools work. There would be several levels which use 
configuration:

1. User can provide specific options on the command line, similar to java -D 
option. These take precedence over other options, since they are specific for 
this single execution.

2. User can specify a specific config file to be used on the command line (e.g. 
a --config option). 

3. The User home directory can be checked for a config file.

4. The System (/etc) directory van be checked for a global config file.

If at position 2 a config file is specified, one should be able in this config 
file to disable the user specific config file, or enable it (e.g. by loading 
it). 

The suggestion made in issue 6, using the current directory, would be between 
option 2 and 3. I would prefer providing an explicit commandline option, but 
this might be a matter of taste.

Original comment by hooijk...@gmail.com on 16 Mar 2011 at 4:25

GoogleCodeExporter commented 8 years ago
Please note that the entire properties/configuration/startup design is up for 
improvement.

I now have a properties file which specifies connection details and there also 
is a groovyrc, which will be used for interactive groovy shells. I really have 
to rethink a bit how an ideal situation should be designed. I am open for 
suggestions.

Original comment by hooijk...@gmail.com on 16 Mar 2011 at 4:36

GoogleCodeExporter commented 8 years ago
I also thought about having it as command line option, but was worried about 
having too many command line options would be difficult to remember. But as 
config file is a important we can have command line option. But I was not up 
for -D option, the reason  being both -config and -D are command line option. 
So may be one is good enough to provide. And -config is good, so that through 
shell scripts or any other scripts it looks common. 

I agree, if there is a unified approach for looking up of these files would 
make the tool very user friendly. 

To keep it common between, windows /Linux users it would be best to take the 
best of both. Here is my opinion

1. User can specify a specific config file to be used on the command line (e.g. 
a --config option) else

2. Current directory else

3. User home directory (common to linux and windows).

Especially for such tools, as it will be common to share as zipped or 
downloadable, scattering config files to multiple locations will be make it 
difficult to manage various files. 

Original comment by phanisri...@gmail.com on 16 Mar 2011 at 4:56

GoogleCodeExporter commented 8 years ago

Original comment by psrinivas2@cordys.com on 27 Feb 2012 at 11:43