Wow!! Thanks for the very detailed answer!
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.
ok.
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.
This is what I have already done. I'm using Merlins code to resolve all the properties - which works fine. The problem here is, that within MerlinDeveloper I'm not only reading the properties but also updating them. That means, that I have to match back changed values to the appropriate property files, which is not done right now by the code.
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?
Great! We should integrate "write/update" capabilities to those builders
too.
But how to go from here? On one side, I would like to get the
functionality in MerlinDeveloper as fast as possible done and on the
other hand I would like to see this area worked out cleanly. Hm - What is your priority on this item? Would you go with me through
the requirements and design so that I could implement the stuff?
I've just committed some stuff I put together this morning before your reply and I'll hopefully get to answer these questions tommorow.
Cheers, Steve.
Thanks again for your detailed answer!
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]
