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 `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. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
