incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [VOTE] Apache Tamaya for Incubation
Date Sat, 15 Nov 2014 00:28:23 GMT
+1


Regards,
Alan

On Nov 10, 2014, at 4:19 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.
> 
> 
> ​


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message