incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [VOTE] Apache Tamaya for Incubation
Date Tue, 11 Nov 2014 07:44:29 GMT
+1
Le 11 nov. 2014 08:20, "jan i" <jani@apache.org> a écrit :

> +1 (binding)
> jan I
>
> On Nov 11, 2014 1:21 AM, "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