<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi All,<div class=""><br class=""></div><div class="">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).</div><div class="">I’ve been thinking for a while how to lead such a vast project with the following constraints:</div><div class="">- Keep the big picture of the spec in mind while working on all detail of each new / modified features</div><div class="">- Have the right balance between the ideal specification and the implementation only driven specification approaches</div><div class="">- Be able to welcome new contributors without loosing them in spec history or advance technical details at the beginning</div><div class="">- Give visibility to third party (other JSR or future implementor) of the spec without forcing them to follow our ML, IRC, JIRA</div><div class="">- Get feedback from the community easily while designing the spec</div><div class=""><br class=""></div><div class="">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)</div><div class=""><br class=""></div><div class=""><div class="">- Modularity (Parts / Profiles) : how we can make CDI more modular by extracting sub part in the spec, like CDI light and events subparts</div><div class="">- 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</div><div class="">- Events enhancement : bringing asynchronicity or ordering to events. Can it be extended to all Java EE</div><div class="">- Interceptor & Decorator : AOP support on produced or custom bean. Work with interceptor spec to add AOP on inner call</div><div class="">- 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</div><div class="">- Contexts enhancement : go beyond the the thread-bound request-response model used by context today to support new application architecture</div></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">If you have other ideas they are welcome.</div><div class=""><br class=""></div><div class="">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.</div><div class="">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.</div><div class=""><br class=""></div><div class="">Depending of the workshop and the group I can think of 2 ways to create the funnel</div><div class=""><br class=""></div><div class="">— Long workflow</div><div class="">1) <b class="">Brain storm</b>. 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.</div><div class="">2) <b class="">Sorting ideas. </b>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</div><div class="">3) <b class="">Blueprint draft</b>. The workshop lead uses the ideas to create a draft document describing how the new feature or enhancement. Ideas not used are kept</div><div class="">4) <b class="">Draft discussion</b> The draft is commented, amended, enhanced by the group and when people feel ready by the EG</div><div class="">5) <b class="">Spec enhancement</b>. When an agreement is accepted on the doc, one of the EG member translate it for the spec (with all the rules)</div><div class=""><br class=""></div><div class="">— Short workflow for smaller groups or on narrower subject</div><div class="">1) <b class="">Blueprint draft : </b>the workgroup lead propose a draft document describing his global idea of how the future should work</div><div class="">2) <b class="">Draft discussion</b> 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</div><div class="">3) <b class="">Spec enhancement</b>. When an agreement is accepted on the doc, one of the EG member translate it for the spec (with all the rules)</div><div class=""><br class=""></div><div class="">Draft could be written on Google Drive or in Github (directly in Asciidoc format). Each solution has its pros and cons.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks for your feedback on this proposal,</div><div class=""><br class=""></div><div class="">Antoine</div><div class=""><br class=""></div></body></html>