You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Leo Simons (JIRA)" <ge...@gump.apache.org> on 2005/05/01 13:37:07 UTC

[jira] Commented: (GUMP-125) Flexible way to configure gump in modern unix-like fashion

     [ http://issues.apache.org/jira/browse/GUMP-125?page=comments#action_64198 ]
     
Leo Simons commented on GUMP-125:
---------------------------------

Mailing list thread at

http://mail-archives.apache.org/mod_mbox/gump-general/200504.mbox/%3cBE9309D1.26C4D%25mail@leosimons.com%3e

There was more discussion about this further back in the archives as well.

> Flexible way to configure gump in modern unix-like fashion
> ----------------------------------------------------------
>
>          Key: GUMP-125
>          URL: http://issues.apache.org/jira/browse/GUMP-125
>      Project: Gump
>         Type: New Feature
>   Components: Python-based Gump
>     Versions: Gump3-alpha-6
>     Reporter: Leo Simons
>      Fix For: Gump3-alpha-6

>
> Gump2 is configured in the <workspace/> just like Java-Gump was. Gump3 is currently configured through environment variables and the command line (sourcing a shell script for custom settings).
> We should provide a logical and modern way to configure gump through
>   /etc/gump3
> and
>   $HOME/.gump3
> directories where you can safely store configuration data related to the machine or the environment (ie, database to use, JAVA_HOME to use, ...).
> A nice example of an application with flexible configuration support is exim, another one is spamassassin, yet another one is apache2 as provided for debian. Things I would like to see:
>  * conf.d directories to allow spliting config
>  * per-profile config as well as per-machine config
>  * use python's features as much as possible for config features and intelligence
>  * installation of default config files with lots of comments so no RTFM is needed
> One advantage of the gump3 "gump" script is that it has no particular trouble firing up jetty (for dynagump) or apache (for webgump). We really need to keep that flexibility, meaning it might make sense to have the configuration parsing set up almost totally seperately from the rest of gump. We could even consider something that reads the environment and the config files and then generates a really-long-commandline or temporary-shell-script. It could be a reusable python tool :-)
> Or maybe that's a bad idea. We'll see.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org