Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Being able to choose which configuration files are loaded #64

Closed
capitancambio opened this issue Oct 30, 2012 · 4 comments
Closed

Being able to choose which configuration files are loaded #64

capitancambio opened this issue Oct 30, 2012 · 4 comments

Comments

@capitancambio
Copy link

@capitancambio capitancambio commented Oct 30, 2012

Dear Norman,
We are trying to build a system based on calabash. We noticed that when the user has a custom .calabash in their home directory it clashes with our configuration files. In order to solve this I've introduced three system properties which are checked before loading the jar config fle, the home config file and the cwd cofig file.
com.xmlcalabash.config.home
com.xmlcalabash.config.jar
com.xmlcalabash.config.cwd
A pull request is being submitted in case you're interested in adding this feature.

Thanks.

@ndw
Copy link
Owner

@ndw ndw commented Jan 29, 2013

Flags to suppress the ~/.calabash and ./.calabash configuration files seem reasonable, I guess. Though I'm tempted to make properties that contain the names of the files. So, maybe com.xmlcalabash.config.user which defaults to ~/.calabash if it isn't set and com.xmlcalabash.config.local which defaults to ./.calabash. Setting them to the empty string would suppress them.

I'm a little surprised by the requirement to be able to suppress the configuration file from the jar. Do you need to specify an alternate configuration? If you don't load something, you won't have implementations for any of the steps!

@capitancambio
Copy link
Author

@capitancambio capitancambio commented Jan 29, 2013

Thanks for the reply. Having both ~/.calabash and ./.calabash as you described is exactly what we were looking for . I don't have a strong point of view regarding the configuration file from the jar, it's true that you need all the declarations for steps, but they can be also feed from another configuration file or dynamically allowing clients of calabash gain more control over the internals. Anyway, that's beside the point of the reason of the patch ...
thanks a million

ndw added a commit that referenced this issue Jan 30, 2013
system properties.

If the global property is set, its value is treated as a filename and
the global configuration will be read from that file instead of from
the configuration stored in the jar file. (This is not recommended.)
The global property value is resolved relative to the current working
directory.

If the user property is set, its value is treated as a filename and
the user configuration will be read from that file. If it is not set,
the value ".calabash" is assumed. The user property value is resolved
relative to the user's home directory. If the user property is the
empty string, no user configuration is loaded.

The local property is interpreted the same way as the user property
except that it is resolved relative to the current working directory.
@ndw
Copy link
Owner

@ndw ndw commented Jan 30, 2013

There you go! :-)

@ndw ndw closed this Jan 30, 2013
@capitancambio
Copy link
Author

@capitancambio capitancambio commented Jan 30, 2013

:) greats!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.