Nice! You are in. - Anatole
2014-11-08 14:22 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > +1, interested to be part of the project as well. > Hi all, > > Thanks for the feedback thus far on the Tamaya proposal. Based on prior > discussion, I'd like to present the proposal found at > https://wiki.apache.org/incubator/TamayaProposal as well as copied below. > > Please take a look and let me know what you think. Please don't hesitate > to make any changes as seen fit on the wiki. > > -- > *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 andinjectable > 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 bein 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 andinjectable 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 itseems currently most sensible to > start an OSS project on the topic to join forces that activelywant to > contribute to the project. It is highly probably that standardization will > be restartedat a later point once we have a widely used Apache standard.For > further information you may look at http://javaeeconfig.blogspot.com > <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 duringbuild > time of the deployed artifacts. Especially dynamic provisioning of > resources or runtime configurationis 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 orlittle 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 > <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 > <https://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 withJSR 354, were people throughout the world helped us to get the > RI/TCK at a very good level. Similarly, wheneverpossible, we encouraged > people to join the expert group, so they also would be capable of > contributing to theAPI directly. In all cases we discussed all questions > amd feedback transparently regardless if it was an EG memberor 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 willraise 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,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 toOpen 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 theinitiatives 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 ensurethis initiative will evolve > hopefully rather quickly to a key component in the Java eco-system, both in > SE, as well as MEand EE. Additionally all stakeholders involved (companies, > as well as individuals/JUGs) have direct benefits of thefunctionality > provided.== Inexperience with Open Source ==Starting point will be the > experimental repository at https://github.com/java-config > <https://github.com/java-config>. Additionally the talks given byAnatole > (e.g. at Javaone 2014) and the blogs under > http://javaeeconfig.blogspot.com > <http://javaeeconfig.blogspot.com> help to give a good starting pointon > some of the concepts implemented/contributed. Nevertheless the idea is that > the ideas are further evolved, basicallysimilar 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 alreadyare members of the ASF.== Homogenous Developers ==The current > list of committers includes developers from severaldifferent companies plus > many independent volunteers. The committersare 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 tothis > project, but given the anticipation from the Java community fora powerful > Configuration implementation and the committers' sense ofownership for the > code, the project would continue without issue if nosalaried developers > contributed to the project. Anatole, as the maincommitter and driver of the > initiative currently, is paid only partiallyand basically drives the > initiative as part of his community engagementin 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 morecan 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 frameworksand 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 conflictingconfiguration 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 standardfor configuration. At a > later stage, if successful, standardizing itwithin 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 > <http://javaeeconfig.blogspot.com> [2] Java Configuration Experimental > Repo: https://github.com/java-config <https://github.com/java-config> > [3] The JavaOne Presentation Slideset: > http://de.slideshare.net/AnatoleTresch/a-first-drat-to-java-configuration > <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/ > <http://commons.apache.org/proper/commons-configuration/> [5] Apache > Deltaspike Configuration: > https://deltaspike.apache.org/documentation/configuration.html > <https://deltaspike.apache.org/documentation/configuration.html> [6] > Spring Configuration: http://projects.spring.io/spring-framework/ > <http://projects.spring.io/spring-framework/> > > http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/annotation/PropertySource.html > < > > 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 > <https://github.com/TNG/config-builder> [8] JFig: > http://jfig.sourceforge.net/ <http://jfig.sourceforge.net/> [9] Owner: > http://owner.aeonbits.org/ <http://owner.aeonbits.org/>== Initial Source > ==Initial source will be from https://github.com/java-config > <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 thanthe 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 <priv...@tamaya.incubator.apache.org > >` > will be used for confidential PPMC discussions. * > `d...@tamaya.incubator.apache.org <d...@tamaya.incubator.apache.org>` is > used > for public discussions and support. * Commits for Tamaya will be emailed to > `comm...@tamaya.incubator.apache.org > <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, under the following directory: * `incubator/tamaya/`== > Issue Tracking ==The following JIRA project would be required to track > issues for the Apache DeltaSpike project: * `DELTASPIKE`== 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)== > 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.* > -- *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*
