Apology accepted;-)
Actually now that Java ME 8 introduced very fine grained modularity and the
concept of Liblets, I would not even say Java SE must be the the bottom
level of where the JSR 330.next would make sense. This is a strong argument
to try keep the two existing JSRs as separate entities and not merge them
into a single one.
Knowing how sensible Antoine and his collaborators at Agorava treated
modularity and being open to different platforms or environments, I trust
we'd also find a good path in this case.
Werner
On Thu, Jul 3, 2014 at 12:31 PM, Martijn Verburg <martijnverburg(a)gmail.com>
wrote:
Hi Antoine,
My apologies - I'm like a Bull in a China shop when it comes to trying to
get people together - I always figure that if its a "No" then we should get
to the "No" quickly :-).
I think CDI 2.0 is important to the community at large - it may pivot
slightly from the original intent, but context aware DI for Java SE would
be a powerful tool in the toolbox (e.g. Oh look I'm writing a Java SE app
that uses websockets......, now I just need to inject a....).
Cheers,
Martijn
On 3 July 2014 11:15, Antoine Sabot-Durand <antoine(a)sabot-durand.net>
wrote:
> Martijn,
>
> I started this thread to discuss wether we should do what you’ve just
> done or not . I’d have liked to have Pete input before stepping like this.
> I guess the decision is taken now ;).
> Anyway, thanks for your enthusiasm. It gives good vibes for the coming
> JSR ;).
>
>
> Antoine
>
>
> Le 3 juil. 2014 à 11:02, Martijn Verburg <martijnverburg(a)gmail.com> a
> écrit :
>
> 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(a)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(a)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(a)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?<329.gif>
>>>> )
>>>>
>>>> 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(a)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/>
>>>
>>
>>
>
>