Hi all,
I just started to implement a preference page in MerlinDeveloper to ease the configuration of all the startup options of Merlin.
Diving into that, I found that there many redundancies in how to configure things. (System properties, merlin.properties, avalon.properties, kernel.xml, command line etc.). The possibility to have those files in different locations makes the situation even more complex.
The rational to have command line options is quite clear to me. But why don't we use kernel.xml p.ex., which is located in the startup directory, to centralize all those configuration tasks?
Multipart answer ...
First off - kernel.xml versus a chain of property files. The reason is that the properties model and the kernel configuration are dealing with two different abstractions.
The property model is all about the establishment of a set of default values using a a flexible property chain is model. Whereas the kernel configuration is an application specific configuration that is used to further qualify information based on a context established by the defaults.
The benefits of this approach really shows up when your automating merlin deployment - in effect your customize the deployment by changing one or two properties locally relative to the set of defaults derived from the chain.
However - some comments on the current implementation:
* currently we have avalon.properties in use by repo and
merlin.properties in use by merlin - these need to be
consolidated down to a single chain which in turn will
simplify code dealing with property aggregation * currently we have multiple install locations - avalon
repo uses ${avalon.home} and merlin uses ${merlin.home}
- this needs to be refactored such that we have a single
install home - which in turn means a single anchor to
the property chain (which is partly in place under 3.3) * code dealing with property aggregation is based on the
avalon util defaults package - however lots of bits of
code exist in different systems doing higher level
chain building - in effect a higher level properties builder
needs to be added to the defaults package that specifically
deals with chain building relative to the following:I think that within an IDE the default property values need to be consolidated down to the presentation of the following views:
* installation (taking into account static properties, env
symbol resolution and the root application properties file) * user properties (located in ${user.dir} and overriding
definitions from the installation) * dir properties (located in an application defined working
directory - e.g. ${merlin.dir} and overriding user properties * system properties (from the jvm representing properties that
exists relative to an instance of the application and override
the dir properties)Anyway - the important thing is that both the IDE and the Merlin factory criteria code are using the same mechanisms to establish values. I think we achieve this with the following:
* a generalized installation properties builder * a generalized property chain builder
From here - the existing criteria/factory classes in merlin, repo, logging, and runtime can be refactored to use these utilities and we can apply the same solutions inside the IDE.
How does this sound?
Stephen.
Andreas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
