You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tamaya.apache.org by Anatole Tresch <at...@gmail.com> on 2014/11/27 21:58:55 UTC

Tamaya Project Discussion

Dear all

I would suggest to try to ramp up the discussions (and along with it
implementations) in the following way:

*1. Use Cases and Requirements*

*2. Core Concepts*
*2.1 Environment, Stage*
*2.2 PropertyProvider, Configuration and composite design*
*2.3 Change Listeners and Mutability*
*2.4 Extension Points*
*2.5 Additional Services (default provider implementations, combining and
filtering providers)*

*3. Advanced Concepts*

*3.1 Multi-Environment-Support*
*3.2 Configuration Providers*
*3.3 Freezing, Serialization, Remoting*

*4. Modules*
*4.1 CDI/EE Integration*
*4.2 Other Java EE Support*
*4.3 JMX Management ?*
*4.4 Default Java EE Configuration (EE ready solution working OOTB)*
*4.3 ???*

*5. Extensions*
*5.1 Configuration Client/Server...?*
*5.2 Configuration Server Setup UIs?*

I propose to setup an asciidoc document for each part. That way we can
compose a comprehensive design documentation easily step by step and also
keep good focus on the aspects. As a starting I will try to update/split
the existing document here (mirrored):

https://github.com/apache/incubator-tamaya/blob/master/api/src/main/asciidoc/JavaConfigSpecification.adoc

Without bigger objections I will try to setup the document parts
accordingly.

Additionally I would propose to move them from
 *api/src/main/asciidoc  *
up to
* api/doc/*

So they are more easily accessible.

Do you think this is a good way to start?

Best,
Anatole



-- 
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

*Switzerland, Europe Zurich, GMT+1*
*Twitter:  @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*

*Google: atsticksMobile  +41-76 344 62 79*

Re: Tamaya Project Discussion

Posted by Romain Manni-Bucau <rm...@gmail.com>.

+1 + IMO system data should surely be an extension but not part of the
core. In particular since we can hope from a config solution to work
in a cluster *too* so it wouldn't mean anything anymore.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2014-11-29 21:27 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> before we continue - please have a look at the suggestion at [1].
>
> regards,
> gerhard
>
> [1] http://s.apache.org/JpU
>
>
>
> 2014-11-29 21:08 GMT+01:00 Otávio Gonçalves de Santana <
> otaviopolianasantana@gmail.com>:
>
>> If we added the *system configurations* like number of processors, System
>> Operation, WDYT?
>>
>> Obs: I am consideration the next CDI, CDI 2.0, can run in Java SE, so it
>> will be useful.
>>
>>
>> @System("processor")
>>
>> private Integer processors;
>>
>>
>>
>>
>> On Thu, Nov 27, 2014 at 6:58 PM, Anatole Tresch <at...@gmail.com>
>> wrote:
>>
>> > Dear all
>> >
>> > I would suggest to try to ramp up the discussions (and along with it
>> > implementations) in the following way:
>> >
>> > *1. Use Cases and Requirements*
>> >
>> > *2. Core Concepts*
>> > *2.1 Environment, Stage*
>> > *2.2 PropertyProvider, Configuration and composite design*
>> > *2.3 Change Listeners and Mutability*
>> > *2.4 Extension Points*
>> > *2.5 Additional Services (default provider implementations, combining and
>> > filtering providers)*
>> >
>> > *3. Advanced Concepts*
>> >
>> > *3.1 Multi-Environment-Support*
>> > *3.2 Configuration Providers*
>> > *3.3 Freezing, Serialization, Remoting*
>> >
>> > *4. Modules*
>> > *4.1 CDI/EE Integration*
>> > *4.2 Other Java EE Support*
>> > *4.3 JMX Management ?*
>> > *4.4 Default Java EE Configuration (EE ready solution working OOTB)*
>> > *4.3 ???*
>> >
>> > *5. Extensions*
>> > *5.1 Configuration Client/Server...?*
>> > *5.2 Configuration Server Setup UIs?*
>> >
>> > I propose to setup an asciidoc document for each part. That way we can
>> > compose a comprehensive design documentation easily step by step and also
>> > keep good focus on the aspects. As a starting I will try to update/split
>> > the existing document here (mirrored):
>> >
>> >
>> >
>> https://github.com/apache/incubator-tamaya/blob/master/api/src/main/asciidoc/JavaConfigSpecification.adoc
>> >
>> > Without bigger objections I will try to setup the document parts
>> > accordingly.
>> >
>> > Additionally I would propose to move them from
>> >  *api/src/main/asciidoc  *
>> > up to
>> > * api/doc/*
>> >
>> > So they are more easily accessible.
>> >
>> > Do you think this is a good way to start?
>> >
>> > Best,
>> > Anatole
>> >
>> >
>> >
>> > --
>> > *Anatole Tresch*
>> > Java Engineer & Architect, JSR Spec Lead
>> > Glärnischweg 10
>> > CH - 8620 Wetzikon
>> >
>> > *Switzerland, Europe Zurich, GMT+1*
>> > *Twitter:  @atsticks*
>> > *Blogs: **http://javaremarkables.blogspot.ch/
>> > <http://javaremarkables.blogspot.ch/>*
>> >
>> > *Google: atsticksMobile  +41-76 344 62 79*
>> >
>>
>>
>>
>> --
>> Otávio Gonçalves de Santana
>>
>> blog:     http://otaviosantana.blogspot.com.br/
>> twitter: http://twitter.com/otaviojava
>> site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
>> 55 (11) 98255-3513
>>

Re: Tamaya Project Discussion

Posted by Gerhard Petracek <ge...@gmail.com>.

before we continue - please have a look at the suggestion at [1].

regards,
gerhard

[1] http://s.apache.org/JpU



2014-11-29 21:08 GMT+01:00 Otávio Gonçalves de Santana <
otaviopolianasantana@gmail.com>:

> If we added the *system configurations* like number of processors, System
> Operation, WDYT?
>
> Obs: I am consideration the next CDI, CDI 2.0, can run in Java SE, so it
> will be useful.
>
>
> @System("processor")
>
> private Integer processors;
>
>
>
>
> On Thu, Nov 27, 2014 at 6:58 PM, Anatole Tresch <at...@gmail.com>
> wrote:
>
> > Dear all
> >
> > I would suggest to try to ramp up the discussions (and along with it
> > implementations) in the following way:
> >
> > *1. Use Cases and Requirements*
> >
> > *2. Core Concepts*
> > *2.1 Environment, Stage*
> > *2.2 PropertyProvider, Configuration and composite design*
> > *2.3 Change Listeners and Mutability*
> > *2.4 Extension Points*
> > *2.5 Additional Services (default provider implementations, combining and
> > filtering providers)*
> >
> > *3. Advanced Concepts*
> >
> > *3.1 Multi-Environment-Support*
> > *3.2 Configuration Providers*
> > *3.3 Freezing, Serialization, Remoting*
> >
> > *4. Modules*
> > *4.1 CDI/EE Integration*
> > *4.2 Other Java EE Support*
> > *4.3 JMX Management ?*
> > *4.4 Default Java EE Configuration (EE ready solution working OOTB)*
> > *4.3 ???*
> >
> > *5. Extensions*
> > *5.1 Configuration Client/Server...?*
> > *5.2 Configuration Server Setup UIs?*
> >
> > I propose to setup an asciidoc document for each part. That way we can
> > compose a comprehensive design documentation easily step by step and also
> > keep good focus on the aspects. As a starting I will try to update/split
> > the existing document here (mirrored):
> >
> >
> >
> https://github.com/apache/incubator-tamaya/blob/master/api/src/main/asciidoc/JavaConfigSpecification.adoc
> >
> > Without bigger objections I will try to setup the document parts
> > accordingly.
> >
> > Additionally I would propose to move them from
> >  *api/src/main/asciidoc  *
> > up to
> > * api/doc/*
> >
> > So they are more easily accessible.
> >
> > Do you think this is a good way to start?
> >
> > Best,
> > Anatole
> >
> >
> >
> > --
> > *Anatole Tresch*
> > Java Engineer & Architect, JSR Spec Lead
> > Glärnischweg 10
> > CH - 8620 Wetzikon
> >
> > *Switzerland, Europe Zurich, GMT+1*
> > *Twitter:  @atsticks*
> > *Blogs: **http://javaremarkables.blogspot.ch/
> > <http://javaremarkables.blogspot.ch/>*
> >
> > *Google: atsticksMobile  +41-76 344 62 79*
> >
>
>
>
> --
> Otávio Gonçalves de Santana
>
> blog:     http://otaviosantana.blogspot.com.br/
> twitter: http://twitter.com/otaviojava
> site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
> 55 (11) 98255-3513
>