Solves nothing in context of system-level settings. Hard to imagine more than 1 person designated
as the deployment manager at any one single time. Even if we are dealing with change sets that
contain more than a few change locations, it's just a simple matter of programming the UI to do
all that in a single step.
But the Xindice thing sounds great. Especially when dealing with huge config files that contain
enormous XML content.
I did mine with just a simple hack. No Xindice, nothing. Purpose: make it easier for me to deploy
hundreds of varied OFBiz instances per month.
Jonathon
David E Jones wrote:
The transactional nature sounds wonderful, but what problem does it
actually solve?
-David
On Dec 14, 2007, at 10:32 PM, Chris Howe wrote:
d) Load the config files into an XML database (Apache Xindice)
manipulate with a UI/wizzard to your heart's content, verify the
structure against an xsd, flush it to the original filename. The
benefit of using an xml database as opposed to just reading/writing
the original file is that you're able to make the changes in a
transaction manner. For instance changing the http port, you can
change url.properties and ofbiz-containers simultaneously.
----- Original Message ----
From: Jacopo Cappellato <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, December 14, 2007 11:08:01 PM
Subject: Re: OfBiz System Configuration Wizard
I think that system settings should stay in config files, not in the
database; if the goal is to simplify the configuration steps described
in the production setup guide, then there are probably different ways
of
addressing this:
a) deliver a separate set of config files already configured for a
"standard" production (cache enabled, verbose logs disabled etc...); we
may also consider to deliver these settings in the release branch, and
maintain the dev settings in the trunk
b) implement an ant-based wizard (to be run during the installation of
OFBiz) that prompts the user for some common settings (http port, https
port, mail server address, db used, db user/password, db url etc...)
and
then modify the OFBiz's files (or, we could prapare *one* simple file
where the user can enter all these values, then run the ant script that
places then in all the relevant OFBiz files)
c) clean up the existing config files; for example, the
entityengine,xml
contains the settings for a lot of different databases; we could keep
the settings for just one of them and move the others into a separate
file, or create one file per database etc...
Of course, for more complex (real World) setups, you'll have to follow
the steps of the production setup guide... but for simpler ones it
could
work.
just my 2 cents
Jacopo
