+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 `Map<String,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 use, both OSS as well as customized in-house proprietary > > solutions > > > > > > == Initial Goals == > > > > The initial goals of the Apache Tamaya project are to: > > > > * Setup the governance structure of the project > > * Receive code donations from https://github.com/java-config > > * Ensure all donated code is appropriately licensed under the Apache > License > > * Merge and rename code to reflect new project name > > * Define the project modules and structure (API, implementation > > modules, adapter modules, examples) > > * Provide examples demonstrating feature usage > > * Produce release/s based on a schedule created by the PMC > > * Attract contributions from the greater Java community > > * Setup collaboration with other projects and the JCP to bring in > > ideas and enhancement proposals, e.g. to Java EE 8 > > > > == Current Status == > > There is an existing running code base implementing a significant part > > of the features mentioned already athttps://github.com/java-config and > > licensed under Apache v2.0, which will be contributed into the > > incubator. > > The separation between API and implementation hereby should stay > enforced, since > > > > * it reflects the structure also required for later JSRs > > * it helps focusing discussions on the core API artifacts before dive > > into implementation details. > > * it helps to ensure the core API is simple and overall comprehensive. > > * it enables to provide different implementations, especially also a > > Java ME compatible solution. > > > > == Meritocracy == > > We plan to do everything possible to encourage an environment that > > supports a meritocracy. We did the same as well with > > JSR 354, were people throughout the world helped us to get the RI/TCK > > at a very good level. Similarly, whenever > > possible, we encouraged people to join the expert group, so they also > > would be capable of contributing to the > > API directly. In all cases we discussed all questions amd feedback > > transparently regardless if it was an EG member > > or just a member of Hackday, Hackergarten. > > > > == Community == > > The project initiative already is significantly supported by JUGs such > > as SouJava, LJC, iJUG, Berlin Brandenburg JUG, > > JUG Zurich, as well as companies such as Credit Suisse and Walmart. It > > is expected that support will > > raise very quickly so the library will evolve and be widely used as well. > > > > == Core Developers == > > The core team will be a set of well known experts from the Java SE and > > EE area (in random order): > > > > * '''Anatole Tresch''' (Lead) is employed at Credit Suisse. He leads > > JSR 354 (Money & Currency) and also was planned as cospec lead for > > Java EE configuration JSR together with Oracle. He also is a member of > > the CDI 2.0 expert group and is actively driving the configuration > > topic. > > * '''Gerhard Petracek''' is Apache MyFaces und DeltaSpike PMC chair. > > * '''Andres Almiray''': Groovy aficionado, Griffon project lead, Java > Champion. > > * '''Joe Pullen''' is a known expert, especially for JPA and Batch > > and also former EC member of the corresponding JSRs. > > * '''Mark Struberg''' acts as PMC and Committer for Apache > > OpenWebBeans, BatchEE, MyFaces, Maven, OpenJPA, BVal, DeltaSpike and > > other projects > > * '''Werner Keil''' aka "Java Godfather" is individual JCP EC member > > and member of the Advisory Board of Developer Week contributing to > > several JSR's in the SE and EE area. He is spec lead of the Units and > > Measurements JSR. Werner is already a committer of ASF. > > * '''Otávio Gonçalves de Santana''' Member of ''SouJava'' and OpenJDK > > committer. He contributes regularly to several JSRs and recently was > > awarded in 2014 as most valuable JCP member. > > * '''Marco Zurmühle''': Member of Credit Suisse working in the Core > > Frameworks Area, which is also responsible for application > > configuration management, and a regular member of the Zurich > > Hackergarten. > > * '''Oliver B. Fischer''': Leader of the JUG Berlin Brandenburg and > > conference speaker. > > * '''David Blevins''': Founder of the Apache TomEE, OpenEJB and > > Geronimo projects. JCP participant in JavaEE and EJB. > > * '''John D. Ament''': Author of Arquillian Testing Guide an > > Enterprise software architect, > > * '''Romain Manni-Bucau''': Developer convinced by Open Source, > > highly active on Apache TomEE, Sirona and other Apache projects > > (OpenEJB, Camel, CXF, Sirona, BatchEE, OpenWebBeans...). > > > > It is expected that more people will join the incubator once it's > running: > > > > * We are already in contact with several companies from Europe and > > US, that are heavily interested in contributing to this initiative. > > * '''LJC (London Java Community), SouJava,JUG Chennai''' will do > > Hackdays and provide feedback. > > * '''JUG Berlin Brandenburg''' is one of the bigger JUGs in Germany > > and would probably also actively contribute to this project. > > * '''JUG Zurich''' organizes regular (monthly) Hackergarten and will > > as well contribute to this project. > > > > == Alignment == > > Credit Suisse, which lead the initiative through Anatole Tresch during > > the last year, has a strong commitment to > > Open Source Software. As a consequence also their first JSR (354, > > Money & Currency) was released under Apache v2. > > The same is the case for all other core contributors and supporters. > > > > == Known Risks == > > Main Risk could be that main committers could cease the project before > > it is possible to build up a public community. > > Nevertheless the wide support of JUGs and companies involved already > > as well as the engagement of main drivers of the > > initiatives during the last year makes this not a very probable scenario. > > > > == Orphaned products == > > See main risks. Basically the engagement of all stakeholders (Credit > > Suisse, JUGs, other companies) should ensure > > this initiative will evolve hopefully rather quickly to a key > > component in the Java eco-system, both in SE, as well as ME > > and EE. Additionally all stakeholders involved (companies, as well as > > individuals/JUGs) have direct benefits of the > > functionality provided. > > > > == Inexperience with Open Source == > > Starting point will be the experimental repository at > > https://github.com/java-config. Additionally the talks given by > > Anatole (e.g. at Javaone 2014) and the blogs under > > http://javaeeconfig.blogspot.com help to give a good starting point > > on some of the concepts implemented/contributed. Nevertheless the idea > > is that the ideas are further evolved, basically > > similar to a JSR, to ensure all relevant views and aspects will be > included. > > > > All of the core committers have already experience working on open > > source projects or JSRs. Many of them even already > > are members of the ASF. > > > > == Homogenous Developers == > > The current list of committers includes developers from several > > different companies plus many independent volunteers. The committers > > are geographically distributed across the U.S., Brazil, Europe, and Asia. > > They are experienced with working in a distributed environment. > > > > == Reliance on Salaried Developers == > > Some of the developers are paid partially by their employer to contribute > to > > this project, but given the anticipation from the Java community for > > a powerful Configuration implementation and the committers' sense of > > ownership for the code, the project would continue without issue if no > > salaried developers contributed to the project. Anatole, as the main > > committer and driver of the initiative currently, is paid only partially > > and basically drives the initiative as part of his community engagement > > in general already as of now. > > > > == Relationships with Other Apache Products == > > The project's core API will be independent of any other projects, because > > * The API should be implementable by different third party providers, > > modules using defined SPIs. > > * The API should if possible have minimal dependencies (or even be > > standalone), so it is highly portable to different environments. > > > > Tamaya will provide a minimal standalone implementation as well. > > Nevertheless it will be possible that other solutions implement the > > API as well, > > e.g. ''Apache Commons Configuration'' (especially version 2). The > > API/SPI should be build in a way, so features from other solutions > > such as > > > > * Apache Commons Configuration > > * Spring Property Sources > > * JFig > > * Configuration Builder > > * and more > > > > can be used or even be leveraged (e.g. by adding environment dependent > > configuration instance management). > > > > Tamaya will also provide adapter modules for other > > technologies/projects, so the solution can inter-operate with existing > > frameworks > > and solutions as a provider similarly. This explicitly also includes > > the possibility to use Tamaya as a configuration/property source > > for. > > > > * Spring > > * System Properties > > * ... > > > > Integration into Java EE has to be coordinated with Apache Deltaspike > > Configuration, to avoid two conflicting > > configuration standards for Java EE. > > > > == An Excessive Fascination with the Apache Brand == > > While we expect the Apache brand may help attract more contributors, > > our interests is in establishing a powerful and widely used standard > > for configuration. At a later stage, if successful, standardizing it > > within a JSR also may be an option. > > We believe this process starts with growing a strong and self-managed > > community that can someday lead the charge in any future > > standardization efforts. Furthermore, we have been enthusiastic users > > of Apache and feel honored at getting the opportunity to join and learn. > > > > == Documentation == > > References to further reading material. > > > > [1] Java (EE) Configuration Blog: > > http://javaeeconfig.blogspot.com > > > > [2] Java Configuration Experimental Repo: > > https://github.com/java-config > > > > [3] The JavaOne Presentation Slideset: > > > http://de.slideshare.net/AnatoleTresch/a-first-drat-to-java-configuration > > > > Links to some other existing solutions: > > > > [4] Apache Commons Configuration: > > http://commons.apache.org/proper/commons-configuration/ > > > > [5] Apache Deltaspike Configuration: > > https://deltaspike.apache.org/documentation/configuration.html > > > > [6] Spring Configuration: http://projects.spring.io/spring-framework/ > > > > http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/annotation/PropertySource.html > > > > [7] Java Configuration Builder: https://github.com/TNG/config-builder > > > > [8] JFig: http://jfig.sourceforge.net/ > > > > [9] Owner: http://owner.aeonbits.org/ > > > > == Initial Source == > > Initial source will be from https://github.com/java-config . Most of > > the functionalities are already fully functional, > > documentation must be improved. > > > > It is already licensed under Apache v2. > > > > > > == External Dependencies == > > > > The following external dependencies have been identified: > > > > The core functionality will be dependent on/use > > * Apache Maven - Java based build tool - Apache License 2.0, > (non-runtime) > > * Shrinkwrap - Java deployment packaging - Apache License 2.0 > (non-runtime) > > > > The parts requiring EE will probably make us of > > * Arquillian - Java EE integration testing framework - Apache License > > 2.0, (non-runtime) > > * various Java EE API packages - all Apache License 2.0 (non-runtime) > > > > The API part of the current initial source is completely standalone > > (it does not have any further dependencies than > > the JDK). The SE 8 based part does mainly depend on Apache > > commons-logging for logging. > > > > > > == Cryptography == > > The framework will not bring along additional cryptographic algorithms. > > > > == Required Resources == > > * The project's build currently is based on Maven, it might be moved to > gradle. > > * Continuous build and integration is important. Depending on the > > integration and third party solutions/versions supported this may > > require several external solutions to be loaded. All of them must be > > available as OSS projects or freely accessible. > > * Continuous quality control with SonarSource would be important as > > well to guarantee very high quality. This is important to have a good > > adoption rate as well. > > > > == Mailing lists == > > We initially would like to start with the minimum required lists: > > > > * `priv...@tamaya.incubator.apache.org` will be used for confidential > > PPMC discussions. > > * `d...@tamaya.incubator.apache.org` is used for public discussions and > support. > > * Commits for Tamaya will be emailed to ` > comm...@tamaya.incubator.apache.org`. > > > > == Git Repository == > > It is proposed that the source code for the Apache Tamaya project be > > hosted in the Apache Git repository: > > > > * https://git-wip-us.apache.org/repos/asf/incubator-tamaya.git > > > > == Issue Tracking == > > The following JIRA project would be required to track issues for the > > Apache Tamaya project: > > > > * `TAMAYA` > > > > == Other Resources == > > None. > > > > == Initial Committers == > > * Anatole Tresch (atsticks at gmail dot com, anatole dot tresch at > > credit dash suisse dot com) > > * Mark Struberg (struberg at apache dot org) > > * Gerhard Petracek (gpetracek at apache dot org) > > * John D. Ament (johndament at apache dot org) > > * Joe Pullen (joe dot pullen at espalier dot com) > > * David Blevins (dblevins at apache dot org) > > * Andres Almiray (aalmiray at gmail dot com) > > * Werner Keil (werner dot keil at gmail dot com) > > * Otávio Gonçalves de Santana (otaviopolianasantana at gmail dot com) > > * Marco Zurmühle (marco dot zurmuehle at gmail dot com ) > > * Oliver B. Fischer (o dot b dot fischer at swe dash blog dot net) > > * Romain Manni-Bucau (rmannibucau at gmail dot com) > > > > == Affiliations == > > * Anatole Tresch - Credit Suisse > > * Marco Zurmühle - Credit Suisse > > * Joe Pullen - Espalier > > * Andres Almiray - Canoo > > > > == Sponsors == > > Champion: > > * David Blevins (dblevins at apache dot org) > > > > Sponsors: > > * David Blevins > > * Mark Struberg > > * Gerhard Petracek > > > > == Nominated Mentors == > > * John D. Ament (johndament at apache dot org) > > * Mark Struberg (struberg at apache dot org) > > * Gerhard Petracek (gpetracek at apache dot org) > > > > == Sponsoring Entity == > > We would like Apache Incubator to sponsor this project. > > > > > > >
