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?
Thanks again for your detailed answer!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
