This has been discussed before and decided against.
An easier solution would be to just put all of the configuration
properties in a single file, except that:
1. different components need different configuration and we don't want
to assume in this way which components or combinations of them will be
used
2. the file would become enormous unless we trim down available
configuration options, and doing that effectively would require
knowing more or less exactly what the system is to be used for (ie
limit the scope and exclude part of the current OFBiz user base)
What we do at Hotwax, and I think what most do (though I don't know)
is create a patch for each server if differences between the servers
are needed. However, in the common case of a pool of servers running
together to create a large instance of OFBiz these per-server
configurations are generally not needed because all of the URLs that
need to be configured are the external/outside URLs that hit the load
balancer, and those are the same for all instances in the pool.
On side note I should mention that the direction has been discussed
and generally agreed on that application level properties should be
done away with (like payment.properties, and many others) and that
information should go into the database. The main reason behind that
is to support differing initial data for common setups that can simply
be loaded into the system when it is run and you can get started
quickly and without having to dive into files... oh and also that you
can maintain things through a UI instead of through editing properties
files.
-David
On Jun 10, 2008, at 2:45 AM, Michael Brohl wrote:
Hi all,
we have changed the OFBiz configuration mechanism for our latest
projects
and I think this change could be useful also for the OFBiz standard.
The problem:
Our customers often have several server systems for one project, at
least
a development, a test and a production server. Some of them have even
more, up to five systems.
All servers have different IP addresses, sometimes different port
settings, different cache settings etc. This is hard to handle and
it is
error-prone to edit the configuration sets for every system after the
project is checked out to the target server. Additionally it would
be more
convenient to edit the settings at a central place instead of many
different files in the project.
So we thought about a more elegant solution for it.
The solution:
The solution is simple and implemented with the tools the project
already
contains: Ant and some template configuration files.
We have moved all necessary configuration files from their origin to a
special folder called templates and removed the values from them. The
values are written in a separate build.properties file. A new Ant
target
creates the target configuration files from the templates an the
build.properties file and copies them to the original location. These
files are in the svn ignore list so that they are not checked in by
accident.
For every system we have additional property files like
test.properties,
live.properties etc. If we want a configuration other than the default
from build.properties, the ant configuration target ist executed
with the
corresponding machine name (e.g. ant -Dmachine.name=live build.xml
configure-and-build). These files only contain the changes from the
build
properties file.
If a property file local.properties exists, it will be processed after
build.properties to have a local developers configuration available.
The following changes have to be made:
1. create a new folder configure and the folders templates and
properties
under it
2. create the configuration templates and corresponding
build.properties
file from the original configuration files
3. delete the original files after adding them to svn:ignore to avoid
checking them back in
4. create a new build file in the configure folder to do the
configuration.
5. add a new configuration target to the main build file
This is a simple but powerful solution and we are quite happy with
it. We
would like to contribute this solution as a patch if you find it as
useful
as we do.
I appreciate your feedback!
Regards,
Michael Brohl
Michael Brohl
Leitung Consulting eCommerce
Agrenon GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 36 64 918
Company and Management Headquarters:
Agrenon GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland,
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.agrenon.com
Court Registration: Amtsgericht Bielefeld HRB 36795
Chief Executive Officer: Dirk Osterkamp
----------------------------------------------------------------------------------------------------
This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail
in error, you are hereby notified that any review, copying, or
distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for your
cooperation.
----------------------------------------------------------------------------------------------------
Besuchen Sie uns!
[EMAIL PROTECTED]:
Releasewechsel SAP BI 7.0 &
Produktroadmap SAP
19. Juni 2008
Beginn: 15.00 Uhr
Geschäftsstelle Bielefeld
