Hi Antoine,
I think that's a great plan!
For <SPI enhancement for integration>, container monitoring could be considered. For
<Java 8 enhancement>, I'd add parameter names support. And for <Interceptor
& Decorator> we may want to revise the proxying strategies / limitations.
Can't wait to get started.
Antonin
________________________________________
From: cdi-dev-bounces(a)lists.jboss.org <cdi-dev-bounces(a)lists.jboss.org> on behalf of
Pete Muir <pmuir(a)redhat.com>
Sent: Friday, August 29, 2014 1:19 PM
To: Antoine Sabot-Durand
Cc: cdi-dev
Subject: Re: [cdi-dev] Working method for CDI 2.0 (a proposal)
Looks like a good approach to me.
On 29 Aug 2014, at 10:49, Antoine Sabot-Durand <antoine(a)sabot-durand.net> wrote:
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.
_______________________________________________
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.