You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Andreas Oberhack <de...@softwarefabrik.biz> on 2004/02/15 08:51:00 UTC
DefaultCriteria
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?
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: DefaultCriteria
Posted by andreas oberhack <de...@softwarefabrik.biz>.
I went again through your mail. To much for me for one reading :-)
>
> 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)
>
ok
> * user properties (located in ${user.dir} and overriding
> definitions from the installation)
>
ok
> * dir properties (located in an application defined working
> directory - e.g. ${merlin.dir} and overriding user properties
>
I'm not really clear about the use of that properties set!?
> * system properties (from the jvm representing properties that
> exists relative to an instance of the application and override
> the dir properties)
ok.
In addition to that, I'm planning to add a "launch configuration", so
that you can store different "preconfigured" application properties and
call them by name.
What do you think?
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: DefaultCriteria
Posted by Stephen McConnell <mc...@apache.org>.
andreas oberhack wrote:
> 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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: DefaultCriteria
Posted by andreas oberhack <de...@softwarefabrik.biz>.
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
Re: DefaultCriteria
Posted by Stephen McConnell <mc...@apache.org>.
Andreas Oberhack wrote:
> 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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org