incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anatole Tresch <atsti...@gmail.com>
Subject Re: [VOTE] Apache Tamaya for Incubation
Date Tue, 11 Nov 2014 04:13:30 GMT
Ah, John already answered as well ;)

-
Anatole Tresch
Glärnischweg 10
8620 Wetzikon
Tel +41 (43) 317 05 30
-
Send from Mobile

> Am 11.11.2014 um 05:09 schrieb Anatole Tresch <atsticks@gmail.com>:
> 
> 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.saputra@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 <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
>> 

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


Mime
View raw message