Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
Reply-To: <develop@softwarefabrik.biz>
From: "andreas oberhack" <develop@softwarefabrik.biz>
To: "'Avalon Developers List'" <dev@avalon.apache.org>
Subject: RE: DefaultCriteria
Date: Sun, 15 Feb 2004 15:35:25 +0100
Organization: Softwarefabrik GmbH
Message-ID: <011f01c3f3d0$f9069090$0200a8c0@lappydevelop>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <402F5D2A.3010607@apache.org>
Importance: Normal

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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org