incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <john.d.am...@gmail.com>
Subject Re: [VOTE] Apache Tamaya for Incubation
Date Tue, 11 Nov 2014 00:29:31 GMT
+1 binding
On Nov 10, 2014 7:21 PM, "Anatole Tresch" <atsticks@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:
>
>  * `private@tamaya.incubator.apache.org` will be used for confidential
> PPMC discussions.
>  * `dev@tamaya.incubator.apache.org` is used for public discussions and
> support.
>  * Commits for Tamaya will be emailed to `
> commits@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.
>
>
> ​
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message