On 08 Nov 2013, at 17:30, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> On 08/11/2013 6:12 AM, Marek Potociar wrote:
>>
>>> Marek,
>>>
>>> I understand. I have no desire for you to provide your own injection framework, but depending *directly* on HK2 is no different than depending on Guice or Spring directly. I'm simply asking for Jersey to depend on an interface instead of a concrete implementation.
>> Actually, it is very different for us. When we ask for anything from Guice folks, we get rejected. When we ask for anything from HK2, our requests get almost always accepted. Also, we have commit rights in HK2 and are able to get a quick review & approval from HK2 team for any last-minute fixes if necessary. Also, HK2 is core part of GlassFish which makes our GF integration a lot easier.
>
> Isn't HK2 development led by employees that are paid by Oracle, at least in some part?
Yes. Does the question relate to this discussion?
> Just because you get rejected when speaking to Guice doesn't mean I'll get a different response when I ask. I don't think they are treating you any different from anyone else. From their point of view, Guice is a mature product that doesn't require any major changes. More practically, Guice is "good enough" for Google's own development so they have less incentive to add any more features. I agree with you that there is plenty of remaining problems with Guice and they should be more receptive to issues brought up by the community.
Our major problem with Guice is that we (or, more precisely, the HK2 team) are not able to figure out how to convince Guice to delegate injection of some of the @Inject-annotated injection points to a 3rd party provider (HK2). This use case does not seem to be covered, IIUC.
> I'm just telling you how things are: *if* we develop an extension of JSR-330, prove that it works, then come to Guice and ask them to implement it... that's one thing. If we come to them and ask for multiple features individually that together add up to an extension of JSR-330 they're going to have much less incentive to go with it. It's kind of like Jersey development, you are much more receptive to pull requests than bug reports :)
I am certainly not trying to stop you from implementing a Guice extension. :)
>>>> Talk to Guice guys and convince them to give up their JSR-330 ownership. JCP community is in a stale mate currently wrt. DI spec - we cannot extend the existing DI API with a new, standard (long needed) injection binding API without having the ownership of JSR-330, but the current owners do not seem to be willing to give up that ownership and neither they seem to have any plans to for making any updates to the spec. (FYI, the current plan is to deliver these missing APIs as part of CDI 2.0)
>>> That's a non-starter. If you couldn't do it, I won't be able to either. I don't think we really need this though.
>> Well, I have no more influence on JSR-330 owners than you. JCP is an open, democratic community, not a dictatorship. You cannot force people to give up control of their own work and intellectual property if they do not want to.
>
> So we are in agreement then.
>
>>> What prevents us from forking JSR-330 into a private namespace and, if this experiment works out, publish a separate JSR which standardizes this work?
>> The JCP rules and the license terms which you accept when you download JSR-330 APIs. This is btw. good thing - the rules protect the JSR owner from people who would try to fork a standard API. However if the owner is inactive, then the JSR suffers.
>
> I think you misunderstood what I am proposing. I'm not asking you to fork JSR-330 and then publish a new version of it in spite of the original author's wishes. I'm asking you to fork JSR-330 and publish it as JSR-9231 (changing package names and everything, if needed). Do JCP rules really prevent this?
Yes, IIUC. Otherwise JSR-299 (CDI) would have done it and would not need to "invent" their own javax.enterprise.inject package...
Marek
>
>> Anyway, we're getting side-tracked. I do not want to discuss JSR-330 & JCP issues in this mailing list. Let's cut it here.
>
> I don't see how else we can resolve this issue, otherwise I would. Anyway, I've begun a separate thread for my proposal. Let's move the discussion there.
>
> Thanks,
> Gili