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.
1. Isn't HK2 development led by employees that are paid by Oracle, at
least in some part?
2. 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.
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 :)
>>> 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?
> 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