Re: [cdi-dev] Working method for CDI 2.0 (a proposal)

Hi All, So we are ready to start work on CDI 2.0. As you know or guess, CDI 2.0 is a great challenge : we have to enhance the existing spec (without breaking existing features), add new features and get the spec ready for new platform (Java SE mainly). I’ve been thinking for a while how to lead such a vast project with the following constraints: - Keep the big picture of the spec in mind while working on all detail of each new / modified features - Have the right balance between the ideal specification and the implementation only driven specification approaches - Be able to welcome new contributors without loosing them in spec history or advance technical details at the beginning - Give visibility to third party (other JSR or future implementor) of the spec without forcing them to follow our ML, IRC, JIRA - Get feedback from the community easily while designing the spec So I came to the idea of creating different workshop on big different CDI features and goals. I identified these (the descriptions are only suggestions of task in the workshop, they should’ be discussed now) - Modularity (Parts / Profiles) : how we can make CDI more modular by extracting sub part in the spec, like CDI light and events subparts - Java SE features : how CDI should work in Java SE and what SPI should we add or standardise to ease its integration in home brewed stacks - Events enhancement : bringing asynchronicity or ordering to events. Can it be extended to all Java EE - Interceptor & Decorator : AOP support on produced or custom bean. Work with interceptor spec to add AOP on inner call - SPI enhancement for integration : give access to all metadata produced by the container, give control of CDI from outside code, support Bean addition / modification @ Runtime - Contexts enhancement : go beyond the the thread-bound request-response model used by context today to support new application architecture - Java 8 enhancement : see how new features in java 8 (type annotation, annotation repetition, lambdas, streams, default methods, type inference…) could enhance CDI in existing and new features. If you have other ideas they are welcome. A workshop should be leaded by a contributor who has a good knowledge of the current spec. It would be composed by a group of contributors. The goal of these workshop is to create ideas funnel to start from high level and go to details after wrong or impossible ideas had been filtered. The best way to avoid missing a new idea. Depending of the workshop and the group I can think of 2 ways to create the funnel — Long workflow 1) Brain storm. Use an online meeting, JIRA, mail exchange or shared doc, to have every workshop give ideas on the topic. Ideally there shouldn’t be censorship at this level. 2) Sorting ideas. All the ideas should be discussed by the group (JIRA is probably the best place to do that). At the end the group will have a bunch of refined ideas to work on 3) Blueprint draft. The workshop lead uses the ideas to create a draft document describing how the new feature or enhancement. Ideas not used are kept 4) Draft discussion The draft is commented, amended, enhanced by the group and when people feel ready by the EG 5) Spec enhancement. When an agreement is accepted on the doc, one of the EG member translate it for the spec (with all the rules) — Short workflow for smaller groups or on narrower subject 1) Blueprint draft : the workgroup lead propose a draft document describing his global idea of how the future should work 2) Draft discussion The draft is commented, amended, enhanced by the group which can react to the doc by proposing new ideas. and When people feel ready by the EG 3) Spec enhancement. When an agreement is accepted on the doc, one of the EG member translate it for the spec (with all the rules) Draft could be written on Google Drive or in Github (directly in Asciidoc format). Each solution has its pros and cons. Existing tickets in Jira could be injected in the workflows below. Some that couldn’t (clarification or spec bugs) will be treated in the classical way. Thanks for your feedback on this proposal, Antoine _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.