Re: [VOTE] Apache Tamaya for Incubation
+1 Regards, Alan On Nov 10, 2014, at 4:19 PM, Anatole Tresch atsti...@gmail.com wrote: Hi all, Thanks for the feedback thus far on the Tamaya proposal. Based on prior discussion, I'd like to start the vote for Tamaya to be accepted as a new incubator project. The proposal can be found here https://wiki.apache.org/incubator/TamayaProposal as well as copied below. Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC [ ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Thanks and Best Regards 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* = = Apache Tamaya - Proposal = == Abstract == Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments. ''Tamaya'' hereby translates into ''in the middle'', which is exactly, what configuration should be. It should be in the middle between your code and your runtime. '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''. == Proposal == Tamaya is a highly flexible configuration API based on an modular, extensible and injectable key/value based design. The basic building blocks hereby are: * ''property providers'' implementing a small and easily implementable subset of a `MapString,String`. * support for configuration injection * a type-safe configuration template mechanism * serializable and remote configuration support * a JMX/Rest based management console * Configuration will follow the GoF composite pattern and support several combination strategies. * An extendible and adaptable environment model, so configuration can be provided dependent of the environment currently active. * extension points and a powerful SPI to seamlessly add additional logic to the API, such as secured views, multi-valued validation schemes, en-/decryption etc. * Configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe and performant to configuration. * Configuration changes can be observed by listening on `ConfigChange` events. The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8. Additionally Apache Tamaya will provide * A Java SE based implementation with minimal features and dependencies. * A Java EE extension module for integration with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas, default methods, method references and functional interfaces an implementation targeting Java ME should be provided as well. * Extension modules for different features. * Adapter/inter-operation modules for other configuration solutions including Apache commons-config == Background == There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point once we have a widely used Apache standard. For further information you may look at http://javaeeconfig.blogspot.com . == Rationale == Configuration is one of the most cross-cutting concerns, which still lacks of a standard. Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand, that is flexible enough, so * it can be used in Java SE, EE and ME * it can support contextual behaviour (like in Java EE and multi-tenancy/SaaS scenarios) * it provides a uniform API, regardless, if its used in SE or EE scenarios * it supports existing APIs, e.g. `System.getProperties, java.util.preferences` in SE and `CDI, JNDI` in Java EE * it supports service location pattern like access as well as ''injection'' of configured values. * it is simple in use and easily extensible. * it support integration with existing configuration solutions
Re: [VOTE] Apache Tamaya for Incubation
+1 (binding) LieGrue, strub On Tuesday, 11 November 2014, 12:20, John D. Ament john.d.am...@gmail.com wrote: Anatole, Actually the name suitability is a long, drawn out process. i started it here just now for the project: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 You can read the details here: http://incubator.apache.org/guides/names.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Tamaya for Incubation
+1 regards, gerhard 2014-11-13 9:16 GMT+01:00 Mark Struberg strub...@yahoo.de: +1 (binding) LieGrue, strub On Tuesday, 11 November 2014, 12:20, John D. Ament john.d.am...@gmail.com wrote: Anatole, Actually the name suitability is a long, drawn out process. i started it here just now for the project: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 You can read the details here: http://incubator.apache.org/guides/names.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Tamaya for Incubation
+1 On Thu, Nov 13, 2014 at 9:56 AM, Gerhard Petracek gpetra...@apache.org wrote: +1 regards, gerhard 2014-11-13 9:16 GMT+01:00 Mark Struberg strub...@yahoo.de: +1 (binding) LieGrue, strub On Tuesday, 11 November 2014, 12:20, John D. Ament john.d.am...@gmail.com wrote: Anatole, Actually the name suitability is a long, drawn out process. i started it here just now for the project: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 You can read the details here: http://incubator.apache.org/guides/names.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Tamaya for Incubation
[ X ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Cheers Daniel S. Haischt On Thu, Nov 13, 2014 at 3:49 PM, David Blevins david.blev...@gmail.com wrote: +1 On Thu, Nov 13, 2014 at 9:56 AM, Gerhard Petracek gpetra...@apache.org wrote: +1 regards, gerhard 2014-11-13 9:16 GMT+01:00 Mark Struberg strub...@yahoo.de: +1 (binding) LieGrue, strub On Tuesday, 11 November 2014, 12:20, John D. Ament john.d.am...@gmail.com wrote: Anatole, Actually the name suitability is a long, drawn out process. i started it here just now for the project: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 You can read the details here: http://incubator.apache.org/guides/names.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Tamaya for Incubation
Hi, On Tue, Nov 11, 2014 at 1:19 AM, Anatole Tresch atsti...@gmail.com wrote: I'd like to start the vote for Tamaya to be accepted as a new incubator project +1 ...'''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''... Note that if there are plans to change the project name it's much better to do so before creating its infrastructure. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Tamaya for Incubation
Definitively! The alternatives only show other things I have considered. If nobody see's any problem with the name, we should keep it ;) 2014-11-11 10:40 GMT+01:00 Bertrand Delacretaz bdelacre...@apache.org: Hi, On Tue, Nov 11, 2014 at 1:19 AM, Anatole Tresch atsti...@gmail.com wrote: I'd like to start the vote for Tamaya to be accepted as a new incubator project +1 ...'''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''... Note that if there are plans to change the project name it's much better to do so before creating its infrastructure. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- *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: [VOTE] Apache Tamaya for Incubation
Anatole, Actually the name suitability is a long, drawn out process. i started it here just now for the project: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 You can read the details here: http://incubator.apache.org/guides/names.html - John On Tue, Nov 11, 2014 at 4:50 AM, Anatole Tresch atsti...@gmail.com wrote: Definitively! The alternatives only show other things I have considered. If nobody see's any problem with the name, we should keep it ;) 2014-11-11 10:40 GMT+01:00 Bertrand Delacretaz bdelacre...@apache.org: Hi, On Tue, Nov 11, 2014 at 1:19 AM, Anatole Tresch atsti...@gmail.com wrote: I'd like to start the vote for Tamaya to be accepted as a new incubator project +1 ...'''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''... Note that if there are plans to change the project name it's much better to do so before creating its infrastructure. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- *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: [VOTE] Apache Tamaya for Incubation
+1 binding On Nov 10, 2014 7:21 PM, Anatole Tresch atsti...@gmail.com wrote: Hi all, Thanks for the feedback thus far on the Tamaya proposal. Based on prior discussion, I'd like to start the vote for Tamaya to be accepted as a new incubator project. The proposal can be found here https://wiki.apache.org/incubator/TamayaProposal as well as copied below. Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC [ ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Thanks and Best Regards 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* = = Apache Tamaya - Proposal = == Abstract == Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments. ''Tamaya'' hereby translates into ''in the middle'', which is exactly, what configuration should be. It should be in the middle between your code and your runtime. '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''. == Proposal == Tamaya is a highly flexible configuration API based on an modular, extensible and injectable key/value based design. The basic building blocks hereby are: * ''property providers'' implementing a small and easily implementable subset of a `MapString,String`. * support for configuration injection * a type-safe configuration template mechanism * serializable and remote configuration support * a JMX/Rest based management console * Configuration will follow the GoF composite pattern and support several combination strategies. * An extendible and adaptable environment model, so configuration can be provided dependent of the environment currently active. * extension points and a powerful SPI to seamlessly add additional logic to the API, such as secured views, multi-valued validation schemes, en-/decryption etc. * Configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe and performant to configuration. * Configuration changes can be observed by listening on `ConfigChange` events. The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8. Additionally Apache Tamaya will provide * A Java SE based implementation with minimal features and dependencies. * A Java EE extension module for integration with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas, default methods, method references and functional interfaces an implementation targeting Java ME should be provided as well. * Extension modules for different features. * Adapter/inter-operation modules for other configuration solutions including Apache commons-config == Background == There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point once we have a widely used Apache standard. For further information you may look at http://javaeeconfig.blogspot.com . == Rationale == Configuration is one of the most cross-cutting concerns, which still lacks of a standard. Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand, that is flexible enough, so * it can be used in Java SE, EE and ME * it can support contextual behaviour (like in Java EE and multi-tenancy/SaaS scenarios) * it provides a uniform API, regardless, if its used in SE or EE scenarios * it supports existing APIs, e.g. `System.getProperties, java.util.preferences` in SE and `CDI, JNDI` in Java EE * it supports service location pattern like access as well as ''injection'' of configured values. * it is simple in use and easily extensible. * it support integration with existing configuration solutions currently in
Re: [VOTE] Apache Tamaya for Incubation
What is the Sponsors: section of this proposal? I believe the proposal would like to have Apache Incubator to sponsor the project? - Henry On Mon, Nov 10, 2014 at 4:19 PM, Anatole Tresch atsti...@gmail.com wrote: Hi all, Thanks for the feedback thus far on the Tamaya proposal. Based on prior discussion, I'd like to start the vote for Tamaya to be accepted as a new incubator project. The proposal can be found here https://wiki.apache.org/incubator/TamayaProposal as well as copied below. Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC [ ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Thanks and Best Regards 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* = = Apache Tamaya - Proposal = == Abstract == Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments. ''Tamaya'' hereby translates into ''in the middle'', which is exactly, what configuration should be. It should be in the middle between your code and your runtime. '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''. == Proposal == Tamaya is a highly flexible configuration API based on an modular, extensible and injectable key/value based design. The basic building blocks hereby are: * ''property providers'' implementing a small and easily implementable subset of a `MapString,String`. * support for configuration injection * a type-safe configuration template mechanism * serializable and remote configuration support * a JMX/Rest based management console * Configuration will follow the GoF composite pattern and support several combination strategies. * An extendible and adaptable environment model, so configuration can be provided dependent of the environment currently active. * extension points and a powerful SPI to seamlessly add additional logic to the API, such as secured views, multi-valued validation schemes, en-/decryption etc. * Configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe and performant to configuration. * Configuration changes can be observed by listening on `ConfigChange` events. The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8. Additionally Apache Tamaya will provide * A Java SE based implementation with minimal features and dependencies. * A Java EE extension module for integration with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas, default methods, method references and functional interfaces an implementation targeting Java ME should be provided as well. * Extension modules for different features. * Adapter/inter-operation modules for other configuration solutions including Apache commons-config == Background == There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point once we have a widely used Apache standard. For further information you may look at http://javaeeconfig.blogspot.com . == Rationale == Configuration is one of the most cross-cutting concerns, which still lacks of a standard. Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand, that is flexible enough, so * it can be used in Java SE, EE and ME * it can support contextual behaviour (like in Java EE and multi-tenancy/SaaS scenarios) * it provides a uniform API, regardless, if its used in SE or EE scenarios * it supports existing APIs, e.g. `System.getProperties, java.util.preferences` in SE and `CDI, JNDI` in Java EE * it supports service location pattern like access as well as ''injection'' of
Re: [VOTE] Apache Tamaya for Incubation
Henry, I believe what Anatole was going for there was who recommended him to bring this to ASF. We are in fact looking for the incubator to be the sponsoring entity. John On Mon, Nov 10, 2014 at 7:39 PM, Henry Saputra henry.sapu...@gmail.com wrote: What is the Sponsors: section of this proposal? I believe the proposal would like to have Apache Incubator to sponsor the project? - Henry On Mon, Nov 10, 2014 at 4:19 PM, Anatole Tresch atsti...@gmail.com wrote: Hi all, Thanks for the feedback thus far on the Tamaya proposal. Based on prior discussion, I'd like to start the vote for Tamaya to be accepted as a new incubator project. The proposal can be found here https://wiki.apache.org/incubator/TamayaProposal as well as copied below. Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC [ ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Thanks and Best Regards 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* = = Apache Tamaya - Proposal = == Abstract == Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments. ''Tamaya'' hereby translates into ''in the middle'', which is exactly, what configuration should be. It should be in the middle between your code and your runtime. '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''. == Proposal == Tamaya is a highly flexible configuration API based on an modular, extensible and injectable key/value based design. The basic building blocks hereby are: * ''property providers'' implementing a small and easily implementable subset of a `MapString,String`. * support for configuration injection * a type-safe configuration template mechanism * serializable and remote configuration support * a JMX/Rest based management console * Configuration will follow the GoF composite pattern and support several combination strategies. * An extendible and adaptable environment model, so configuration can be provided dependent of the environment currently active. * extension points and a powerful SPI to seamlessly add additional logic to the API, such as secured views, multi-valued validation schemes, en-/decryption etc. * Configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe and performant to configuration. * Configuration changes can be observed by listening on `ConfigChange` events. The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8. Additionally Apache Tamaya will provide * A Java SE based implementation with minimal features and dependencies. * A Java EE extension module for integration with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas, default methods, method references and functional interfaces an implementation targeting Java ME should be provided as well. * Extension modules for different features. * Adapter/inter-operation modules for other configuration solutions including Apache commons-config == Background == There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point once we have a widely used Apache standard. For further information you may look at http://javaeeconfig.blogspot.com . == Rationale == Configuration is one of the most cross-cutting concerns, which still lacks of a standard. Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand, that is flexible enough, so * it can be used in Java SE, EE
Re: [VOTE] Apache Tamaya for Incubation
Yep. The section is there in the proposal (the last one) ;) - Anatole Tresch Glärnischweg 10 8620 Wetzikon Tel +41 (43) 317 05 30 - Send from Mobile Am 11.11.2014 um 01:39 schrieb Henry Saputra henry.sapu...@gmail.com: What is the Sponsors: section of this proposal? I believe the proposal would like to have Apache Incubator to sponsor the project? - Henry On Mon, Nov 10, 2014 at 4:19 PM, Anatole Tresch atsti...@gmail.com wrote: Hi all, Thanks for the feedback thus far on the Tamaya proposal. Based on prior discussion, I'd like to start the vote for Tamaya to be accepted as a new incubator project. The proposal can be found here https://wiki.apache.org/incubator/TamayaProposal as well as copied below. Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC [ ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Thanks and Best Regards 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* = = Apache Tamaya - Proposal = == Abstract == Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments. ''Tamaya'' hereby translates into ''in the middle'', which is exactly, what configuration should be. It should be in the middle between your code and your runtime. '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''. == Proposal == Tamaya is a highly flexible configuration API based on an modular, extensible and injectable key/value based design. The basic building blocks hereby are: * ''property providers'' implementing a small and easily implementable subset of a `MapString,String`. * support for configuration injection * a type-safe configuration template mechanism * serializable and remote configuration support * a JMX/Rest based management console * Configuration will follow the GoF composite pattern and support several combination strategies. * An extendible and adaptable environment model, so configuration can be provided dependent of the environment currently active. * extension points and a powerful SPI to seamlessly add additional logic to the API, such as secured views, multi-valued validation schemes, en-/decryption etc. * Configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe and performant to configuration. * Configuration changes can be observed by listening on `ConfigChange` events. The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8. Additionally Apache Tamaya will provide * A Java SE based implementation with minimal features and dependencies. * A Java EE extension module for integration with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas, default methods, method references and functional interfaces an implementation targeting Java ME should be provided as well. * Extension modules for different features. * Adapter/inter-operation modules for other configuration solutions including Apache commons-config == Background == There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point once we have a widely used Apache standard. For further information you may look at http://javaeeconfig.blogspot.com . == Rationale == Configuration is one of the most cross-cutting concerns, which still lacks of a standard. Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand, that is flexible enough, so * it can be used in Java SE, EE and ME * it can support contextual behaviour (like in Java EE and multi-tenancy/SaaS scenarios) * it provides a uniform API, regardless, if
Re: [VOTE] Apache Tamaya for Incubation
Ah, John already answered as well ;) - Anatole Tresch Glärnischweg 10 8620 Wetzikon Tel +41 (43) 317 05 30 - Send from Mobile Am 11.11.2014 um 05:09 schrieb Anatole Tresch atsti...@gmail.com: Yep. The section is there in the proposal (the last one) ;) - Anatole Tresch Glärnischweg 10 8620 Wetzikon Tel +41 (43) 317 05 30 - Send from Mobile Am 11.11.2014 um 01:39 schrieb Henry Saputra henry.sapu...@gmail.com: What is the Sponsors: section of this proposal? I believe the proposal would like to have Apache Incubator to sponsor the project? - Henry On Mon, Nov 10, 2014 at 4:19 PM, Anatole Tresch atsti...@gmail.com wrote: Hi all, Thanks for the feedback thus far on the Tamaya proposal. Based on prior discussion, I'd like to start the vote for Tamaya to be accepted as a new incubator project. The proposal can be found here https://wiki.apache.org/incubator/TamayaProposal as well as copied below. Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC [ ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Thanks and Best Regards 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* = = Apache Tamaya - Proposal = == Abstract == Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments. ''Tamaya'' hereby translates into ''in the middle'', which is exactly, what configuration should be. It should be in the middle between your code and your runtime. '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''. == Proposal == Tamaya is a highly flexible configuration API based on an modular, extensible and injectable key/value based design. The basic building blocks hereby are: * ''property providers'' implementing a small and easily implementable subset of a `MapString,String`. * support for configuration injection * a type-safe configuration template mechanism * serializable and remote configuration support * a JMX/Rest based management console * Configuration will follow the GoF composite pattern and support several combination strategies. * An extendible and adaptable environment model, so configuration can be provided dependent of the environment currently active. * extension points and a powerful SPI to seamlessly add additional logic to the API, such as secured views, multi-valued validation schemes, en-/decryption etc. * Configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe and performant to configuration. * Configuration changes can be observed by listening on `ConfigChange` events. The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8. Additionally Apache Tamaya will provide * A Java SE based implementation with minimal features and dependencies. * A Java EE extension module for integration with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas, default methods, method references and functional interfaces an implementation targeting Java ME should be provided as well. * Extension modules for different features. * Adapter/inter-operation modules for other configuration solutions including Apache commons-config == Background == There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point once we have a widely used Apache standard. For further information you may look at http://javaeeconfig.blogspot.com . == Rationale == Configuration is one of the most cross-cutting concerns, which still lacks of a standard. Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand,
Re: [VOTE] Apache Tamaya for Incubation
+1 [binding] On Tue, Nov 11, 2014 at 01:19AM, Anatole Tresch wrote: Hi all, Thanks for the feedback thus far on the Tamaya proposal. Based on prior discussion, I'd like to start the vote for Tamaya to be accepted as a new incubator project. The proposal can be found here https://wiki.apache.org/incubator/TamayaProposal as well as copied below. Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC [ ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Thanks and Best Regards 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* = = Apache Tamaya - Proposal = == Abstract == Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments. ''Tamaya'' hereby translates into ''in the middle'', which is exactly, what configuration should be. It should be in the middle between your code and your runtime. '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''. == Proposal == Tamaya is a highly flexible configuration API based on an modular, extensible and injectable key/value based design. The basic building blocks hereby are: * ''property providers'' implementing a small and easily implementable subset of a `MapString,String`. * support for configuration injection * a type-safe configuration template mechanism * serializable and remote configuration support * a JMX/Rest based management console * Configuration will follow the GoF composite pattern and support several combination strategies. * An extendible and adaptable environment model, so configuration can be provided dependent of the environment currently active. * extension points and a powerful SPI to seamlessly add additional logic to the API, such as secured views, multi-valued validation schemes, en-/decryption etc. * Configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe and performant to configuration. * Configuration changes can be observed by listening on `ConfigChange` events. The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8. Additionally Apache Tamaya will provide * A Java SE based implementation with minimal features and dependencies. * A Java EE extension module for integration with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas, default methods, method references and functional interfaces an implementation targeting Java ME should be provided as well. * Extension modules for different features. * Adapter/inter-operation modules for other configuration solutions including Apache commons-config == Background == There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point once we have a widely used Apache standard. For further information you may look at http://javaeeconfig.blogspot.com . == Rationale == Configuration is one of the most cross-cutting concerns, which still lacks of a standard. Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand, that is flexible enough, so * it can be used in Java SE, EE and ME * it can support contextual behaviour (like in Java EE and multi-tenancy/SaaS scenarios) * it provides a uniform API, regardless, if its used in SE or EE scenarios * it supports existing APIs, e.g. `System.getProperties, java.util.preferences` in SE and `CDI, JNDI` in Java EE * it supports service location pattern like access as well as ''injection'' of configured values. * it is simple in use and easily extensible. * it support integration with existing configuration solutions
Re: [VOTE] Apache Tamaya for Incubation
+1 (binding) jan I On Nov 11, 2014 1:21 AM, Anatole Tresch atsti...@gmail.com wrote: Hi all, Thanks for the feedback thus far on the Tamaya proposal. Based on prior discussion, I'd like to start the vote for Tamaya to be accepted as a new incubator project. The proposal can be found here https://wiki.apache.org/incubator/TamayaProposal as well as copied below. Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC [ ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Thanks and Best Regards 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* = = Apache Tamaya - Proposal = == Abstract == Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments. ''Tamaya'' hereby translates into ''in the middle'', which is exactly, what configuration should be. It should be in the middle between your code and your runtime. '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''. == Proposal == Tamaya is a highly flexible configuration API based on an modular, extensible and injectable key/value based design. The basic building blocks hereby are: * ''property providers'' implementing a small and easily implementable subset of a `MapString,String`. * support for configuration injection * a type-safe configuration template mechanism * serializable and remote configuration support * a JMX/Rest based management console * Configuration will follow the GoF composite pattern and support several combination strategies. * An extendible and adaptable environment model, so configuration can be provided dependent of the environment currently active. * extension points and a powerful SPI to seamlessly add additional logic to the API, such as secured views, multi-valued validation schemes, en-/decryption etc. * Configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe and performant to configuration. * Configuration changes can be observed by listening on `ConfigChange` events. The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8. Additionally Apache Tamaya will provide * A Java SE based implementation with minimal features and dependencies. * A Java EE extension module for integration with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas, default methods, method references and functional interfaces an implementation targeting Java ME should be provided as well. * Extension modules for different features. * Adapter/inter-operation modules for other configuration solutions including Apache commons-config == Background == There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point once we have a widely used Apache standard. For further information you may look at http://javaeeconfig.blogspot.com . == Rationale == Configuration is one of the most cross-cutting concerns, which still lacks of a standard. Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand, that is flexible enough, so * it can be used in Java SE, EE and ME * it can support contextual behaviour (like in Java EE and multi-tenancy/SaaS scenarios) * it provides a uniform API, regardless, if its used in SE or EE scenarios * it supports existing APIs, e.g. `System.getProperties, java.util.preferences` in SE and `CDI, JNDI` in Java EE * it supports service location pattern like access as well as ''injection'' of configured values. * it is simple in use and easily extensible. * it support integration with existing configuration solutions
Re: [VOTE] Apache Tamaya for Incubation
+1 Le 11 nov. 2014 08:20, jan i j...@apache.org a écrit : +1 (binding) jan I On Nov 11, 2014 1:21 AM, Anatole Tresch atsti...@gmail.com wrote: Hi all, Thanks for the feedback thus far on the Tamaya proposal. Based on prior discussion, I'd like to start the vote for Tamaya to be accepted as a new incubator project. The proposal can be found here https://wiki.apache.org/incubator/TamayaProposal as well as copied below. Vote is open until at least Saturday, 15th November 2014, 23:59:00 UTC [ ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Thanks and Best Regards 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* = = Apache Tamaya - Proposal = == Abstract == Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments. ''Tamaya'' hereby translates into ''in the middle'', which is exactly, what configuration should be. It should be in the middle between your code and your runtime. '''NOTE:''' Alternative names could be ''Mahkah=earth, Dakota=friend'' or ''Orenda=magic force''. == Proposal == Tamaya is a highly flexible configuration API based on an modular, extensible and injectable key/value based design. The basic building blocks hereby are: * ''property providers'' implementing a small and easily implementable subset of a `MapString,String`. * support for configuration injection * a type-safe configuration template mechanism * serializable and remote configuration support * a JMX/Rest based management console * Configuration will follow the GoF composite pattern and support several combination strategies. * An extendible and adaptable environment model, so configuration can be provided dependent of the environment currently active. * extension points and a powerful SPI to seamlessly add additional logic to the API, such as secured views, multi-valued validation schemes, en-/decryption etc. * Configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe and performant to configuration. * Configuration changes can be observed by listening on `ConfigChange` events. The API's focus is on simplicity and ease of use. Developers should only have to know a minimal set of artifacts to work with the solution. The API is built on latest Java 8 features and therefore fit perfectly with the functional features of Java 8. Additionally Apache Tamaya will provide * A Java SE based implementation with minimal features and dependencies. * A Java EE extension module for integration with Java EE and Apache Deltaspike. * Once Java ME supports Lambdas, default methods, method references and functional interfaces an implementation targeting Java ME should be provided as well. * Extension modules for different features. * Adapter/inter-operation modules for other configuration solutions including Apache commons-config == Background == There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point once we have a widely used Apache standard. For further information you may look at http://javaeeconfig.blogspot.com . == Rationale == Configuration is one of the most cross-cutting concerns, which still lacks of a standard. Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand, that is flexible enough, so * it can be used in Java SE, EE and ME * it can support contextual behaviour (like in Java EE and multi-tenancy/SaaS scenarios) * it provides a uniform API, regardless, if its used in SE or EE scenarios * it supports existing APIs, e.g. `System.getProperties, java.util.preferences` in SE and `CDI, JNDI` in Java EE * it supports service
