[cdi-dev] About JSR 330.Next and CDI 2.0

Thu Jul 3 05:49:35 EDT 2014

P.s.:

The list of JCP Members after the renewal could be a little outdated, but
given Pivotal looks like a completely independent company now, not a
department of VMWare, they do not even seem to be a JCP Member at the
moment, so Pivotal reviving JSR 330 or becoming MR might require them
joining[?]

On Thu, Jul 3, 2014 at 11:34 AM, Werner Keil <werner.keil at gmail.com> wrote:

> @Martijn/all,
>
> Thanks for reaching out to Pivotal/Google. You know best, Google may be a
> bit tricky considering the lawsuit.
>
> And please cool down about non-responsive or inactive peopple in the JCP
> or elsewhere. As you know best (though you are not the primary rep for LJC
> there any more), the JSR 364 EG EC and other JCP.next initiatives were keen
> to get people involved, but we don't want "Vanity Members" who just claim
> they are on a list or get their "pin stripe" full of JSR or other Open
> Source "memberships" without ever contributing more than to say "Hello" or
> "Goodbye" in a mailing list. Regardless of his or Interface
> 21's/SpringSource's contribtion to the larger Java ecosystem, the former Co
> Spec Lead or JSR 330 Rod Johnson was exactly that case (I personally
> whitnessed his "15 min. of Fame" in a single EC F2F where he then vanished
> and was never seen)
> And especially in JSR 354 Crazy Bob has been equally invisible. Which is
> why Anatole wanted to have a word with him about still being on the EG or
> not.
>
> We need people like Antoine who try to get things done now, not
> "filibusters" or some "bust" in a "Hall of Fame" (well, to some extent
> that's what the "Rock Stars" are for[?]), neither in this JSR nor others.
> There could be other roles for them from "Observer" to "Contributor" (if
> JSR 364 concludes) so please try your best to get 364 or 358 out, but spare
> this here.
>
> Cheers,
> Werner
>
> On Thu, Jul 3, 2014 at 11:02 AM, Martijn Verburg <martijnverburg at gmail.com
> > wrote:
>
>> FYI - I've sent a note to the various folks from Google, Pivotal et al,
>> I'll let Antoine explain the CDI 2.0 proposal to them and I'm sure they'll
>> either join this mailing list / discussion or we'll quickly find out
>> there's no appetite and we can move on.
>>
>> Cheers,
>> Martijn
>>
>>
>> On 3 July 2014 09:51, Martijn Verburg <martijnverburg at gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> To be blunt, this is a social/community issue - not a technical one.  We
>>> simply need to get hold of the folks at Pivotal, Google (and other 330 EG
>>> members) and get them around the virtual table.  If they subsequently
>>> aren't interested then fine, you should forge your own path.
>>>
>>> There's an absolute mega ton of 330 based DI code out there and 330
>>> compliant containers, if CDI 2.0 wants to be the defacto std going forwards
>>> it simply can't afford ignore that.
>>>
>>> @Antoine - let's put our heads together and see who we need to get hold
>>> of in the 330 group, I think CDI 2.0 has strong merits and should be
>>> explored.
>>>
>>> @Werner - your comments about Bob's commitment (considering what he's
>>> done for the tech community at large, let alone Java) are highly
>>> inappropriate, please refrain from personal attacks on this or any other
>>> public forum.
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>>
>>> On 3 July 2014 09:02, Antonio Goncalves <antonio.goncalves at gmail.com>
>>> wrote:
>>>
>>>> > To sum up, as a Java EE user (like I have been for 10 years) I’d be
>>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could
>>>> lead us in a trap (going to scenario 1 or consuming precious time on
>>>> AtInject+1 instead of CDI 2.0)
>>>>
>>>> Well, I'm not spec lead, I'm just a Java EE user... so I like scenario
>>>> 2 ;o)
>>>>
>>>> But on the other hand, I think there is so much work to be done around
>>>> CDI 2.0, parts, and taking those parts to other specifications that
>>>> battling with JSR 330 might be time consuming. I would go for scenario
>>>> 1.... and cross fingers
>>>>
>>>>
>>>> On Wed, Jul 2, 2014 at 11:18 PM, Werner Keil <werner.keil at gmail.com>
>>>> wrote:
>>>>
>>>>> Dear Antoine/all,
>>>>>
>>>>> Thanks for the detailed overview and trying to reach out to the former
>>>>> Spec Leads and EG of JSR 330. I also copied Anatole, Spec Lead of JSR 354,
>>>>> since Bob Lee is officially in his EG, but has practically never provided
>>>>> input there either (like we tend to see sometimes from others considered
>>>>> "Rock Stars" of the Java Community but since then seemingly resting on
>>>>> their laurels or just too busy counting their stock options?[?])
>>>>>
>>>>> Given CDI already was the public perception of "javax.inject" for most
>>>>> parts, I don't necessarily see that it had to be an MR to the original JSR,
>>>>> though as those involved in the EC (Martijn, Badr/MoroccoJUG,..) could
>>>>> probably check with the PMO how to handle a case where the Maintenance Lead
>>>>> of a JSR was not in the position to continue. I last met Jürgen Höller
>>>>> about a year ago in Copenhagen, so for Pivotal's part as Co Spec Lead, I
>>>>> guess he or the likes of Josh Long could be best to speak to. Happy to get
>>>>> you in touch with them if you want.
>>>>>
>>>>> Red Hat was also EG member of JSR 330, so Pete, Gavin or whoever else
>>>>> was there (I remember him from conversations where Mike Keith and I took
>>>>> part in synergy discussions between 330 and CDI 1.0) at the time could also
>>>>> help you with this.
>>>>>
>>>>> In theory this could also be part of a new JSR (CDI 2) as long as none
>>>>> of the enhancements you have in mind break the existing API of JSR 330. The
>>>>> scope of CDI 2 to work in an SE/standalone or more lightweight environment
>>>>> than Java EE environment raises a good question of package names like "
>>>>>  javax.enterprise.inject.*" So maybe there is room for synergies in a
>>>>> package namespace other than "javax.enterprise" at least for new things you
>>>>> have in mind.
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>>  Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
>>>>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>>>>>
>>>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social
>>>>> | #DevOps
>>>>>  Skype werner.keil | Google+ gplus.to/wernerkeil
>>>>>
>>>>> * Developer Week: 14/15 Jul 2014, Nürnberg, Germany. Werner Keil, JCP
>>>>> EC Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E'
>>>>> class Continuous Delivery", "JSR 363 and IoT" (GER)
>>>>>
>>>>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP EC
>>>>> Member, JSR 363 Spec Lead will present "JSR 363 - The Answer to Life
>>>>> Science and the Internet of Everything"
>>>>>
>>>>> * JavaOne 2014: Sep 28-Oct 2 2014, San Francisco, USA, Werner Keil,
>>>>> JCP EC Member, JSR 354 EG Member will host "Java and Digital Currencies,
>>>>> Friend or FOE"
>>>>>
>>>>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner Keil, JCP EC
>>>>> Member, JSR 363 Spec Lead, DevOps Guy will present "Triple-E' class
>>>>> DevOps", "JSR 363"
>>>>>
>>>>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg, Germany.
>>>>> Werner Keil, JCP EC Member, Apache DeviceMap Committer will present "Apache
>>>>> DeviceMap" (GER)
>>>>>
>>>>>
>>>>> On Wed, Jul 2, 2014 at 10:43 PM, Antoine Sabot-Durand <
>>>>> antoine at sabot-durand.net> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Since the first mention of CDI 2.0 preparation work, we've received a
>>>>>> lot of comment about JSR 330 evolution. With the release of the proposal
>>>>>> draft yesterday, this topic came up again. So let me give my point of view
>>>>>> on this subject to have an open discussion here.
>>>>>>
>>>>>> When we started to discuss about modularity with Pete in last
>>>>>> november, my first idea was to go see what we could add in JSR 330 to make
>>>>>> it a true specification that could be the first module of CDI. My idea at
>>>>>> that time was to discuss with JSR 330 owner to see if we could bring basic
>>>>>> concept we have in CDI to AtInject spec. In my mind the main features would
>>>>>> have been:
>>>>>>  - Enhance the javax.inject.Provider<T> interface to bring it at the
>>>>>> same level than javax.enterprise.inject.Instance<T>. That would have
>>>>>> included support for AnnotationLiteral and TypeLiteral as well
>>>>>>  - Add a Container interface (a very light BeanManger) in JSR 330 to
>>>>>> be able to resolve beans instance from outside managed beans
>>>>>>  - Add a mechanism to get this Container from non managed beans (like
>>>>>> we get access to BeanManager from JNDI or CDI class)
>>>>>>
>>>>>> At that time, I contacted Bob Lee without success (didn’t tried
>>>>>> Pivotal since I don’t have contact there). I checked with JCP what could be
>>>>>> done if we’d like to see an evolution of JSR 330 and the owner doesn’t
>>>>>> care, there seems to have solutions but I let it aside since we were in the
>>>>>> middle of CDI 1.2 MR at that time.
>>>>>>
>>>>>> Today I’m a bit torn about this point. Working on opening JSR 330
>>>>>> could be like opening pandora box, since I see 2 scenarios :
>>>>>>
>>>>>> 1) former JSR 330 owners wake up and are ok to get for a new spec
>>>>>> version they lead:
>>>>>> Knowing the history of JSR 330 vs JSR 299 I’m not sure everything
>>>>>> we’d need would be heard and even if the people leading this would be
>>>>>> cooperative, a lot of discussion and negotiation would be needed to be sure
>>>>>> that this new AtInject wouldn’t contain features incompatible with CDI. So
>>>>>> it’d be very time consuming with no guarantee to get what we’d need at the
>>>>>> end.
>>>>>>
>>>>>> 2) former JSR 330 owner don’t mind others take ownership of their
>>>>>> spec to enhance it and we (Red Hat) are the one to take this ownership to
>>>>>> secure CDI:
>>>>>> The best solution to minimize risk. But leading a new specification
>>>>>> is a lot more work than just deciding that we have a specific basic inject
>>>>>> « part » in  CDI 2.0. Leading a spec is very time consuming, so it could be
>>>>>> better on the paper but will impact CDI 2.0 new features.
>>>>>>
>>>>>> To sum up, as a Java EE user (like I have been for 10 years) I’d be
>>>>>> happy to see this (scenario 2), but as CDI spec lead I fear that it could
>>>>>> lead us in a trap (going to scenario 1 or consuming precious time on
>>>>>> AtInject+1 instead of CDI 2.0)
>>>>>>
>>>>>> Your input, solutions or comment would be appreciated on this point.
>>>>>>
>>>>>> Antoine
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Antonio Goncalves
>>>> Software architect, Java Champion and Pluralsight author
>>>>
>>>> Web site <http://www.antoniogoncalves.org> | Twitter
>>>> <http://twitter.com/agoncal> | LinkedIn
>>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/15dee426/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 257 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140703/15dee426/attachment-0001.gif 