avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "andreas oberhack" <deve...@softwarefabrik.biz>
Subject RE: DefaultCriteria
Date Sun, 15 Feb 2004 14:35:25 GMT
Wow!! Thanks for the very detailed answer!

> Multipart answer ...
> First off - kernel.xml versus a chain of property files.  The reason
> that the properties model and the kernel configuration are dealing
> two different abstractions.


> 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
> 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
> apply the same solutions inside the IDE.
> How does this sound?

Great! We should integrate "write/update" capabilities to those builders
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!


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message