Hi guys,
adding on the discussion of that is the Event mechanism. It would be
interesting if we could have the Event injecting mechanism to be injectable
by any JSR component. Imagine for example I have a JNDI resource(Another
added value here would be allowing JNDI resource handling via annotations)
and registering for light CDI events. A pub sub pattern that would imitate
something like a bus event mechanism where "components" can register for
firing base on events published. The CDI container should provide this
lightweight mechanism also in an standalone mode. This would allow for
building some nice eventing frameworks on top of CDI that would be
available and could integrate really easily with other enterprise
components. My 0.00005$ on the discussion.
regards
Nick
On Fri, Jul 4, 2014 at 11:46 AM, Pete Muir <pmuir(a)redhat.com> wrote:
The CDI spec lead (Red Hat)’s official position for the CDI
specification
is clearly covered on
http://www.cdi-spec.org/download/
If you have any questions regarding this, you will need to contact Red Hat
legal.
On 3 Jul 2014, at 19:33, Werner Keil <werner.keil(a)gmail.com> wrote:
> I must correct you in the sense, that the license (that "Accept and
Download" page) for the Spec is not Apache, though there is practically no
spec here for these 6 annotations.
> So it is a bit of a grey zone, and even EC Members with a large legal
department are in ongoing discussions over that. The "Spec" and its
Software Manifestation (normally all artifacts under "javax.something" or
"java.something" (for the few JSRs like 310 that changed their package name
in the course of the lifecycle) in Oracle's (the PMO) understanding is
under the Spec License.
>
> So strictly speaking annotations under "javax.inject" are the
"Spec",
not RI or TCK, and therefore they don't fall under Apache 2. Google Guice
and the TCK did and still do.
>
> Looking at JSRs like 107
https://github.com/jsr107/jsr107spec or 354,
you'll notice they all have this in common.
> Especially the JavaDoc as manifestation of the Spec (and for 330 that
is all there is of a Spec) therefore naturally fall under the Spec License,
too.
>
> Just see Java EE 7:
http://docs.oracle.com/javaee/7/api/ the JavaDoc
(for all JSRs within that umbrella) is therefore covered by the EE 7 Spec
License
> >Copyright © 1996-2013, Oracle and/or its affiliates. All Rights
Reserved. Use is subject to license terms.
> see the link under "license terms"<329.gif>
>
> JSR 352 poses a stubbern dilemma as its EG and Spec Leads insist on a
different license footer in the standalone distribution (Apache 2) as in
the overall Java EE 7 umbrella.
> Which is a nightmare for users, a reason I voted against the MR or
abstained from this particular JSR as it denies what is reality at least
for the Spec and artifacts like the JavaDoc.
>
> CDI refrains from this breach. At least there is no contradicting
JavaDoc license pointer.
>
> Red Hat considers a "Dual Licensing" option for the Spec, but from all I
heard so far, this is not how Oracle and the JCP PMO (or at least Oracle's
lawyers) see this.
> With the proposal of the ULA Oracle tries to get all future JSRs to use
a single license for RI and TCK.
>
> There's an ongoing discussion over details, but unless Oracle's legal
department and PMO make a dramatic turn on these matters, JSRs filed in the
near future (including CDI 2 or beyond) would likely fall under Spec and
ULA license.
>
> Cheers,
> Werner
>
> On Thu, Jul 3, 2014 at 8:00 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
> As far as I know the history (and I have been tracking and contributing
to JSR-330 back then) most of the people were fed up _because_ they got
pushed to change the license from ALv2 to something else (cannot remember
anymore what exactly).
>
> The original Apache v2 licensed work can be found here:
>
https://code.google.com/p/atinject/
>
> I have no clue why Oracle added the 'accept license' radio button on
their JSR-330 download page. Maybe just a copy&paste error? The text in
this license window is in fact not ALv2 but something else which is wrong
information at best.
>
> The good news: ALL the assets in JSR-330 still are ALv2!
> Thus anyone can take it and enhance it.
> Of course it would be good to have Bob and Jürgen on board, but legally
it might not even be necessary.
>
> LieGrue,
> strub
>
>
>
> On Thursday, 3 July 2014, 17:35, Werner Keil <werner.keil(a)gmail.com>
wrote:
>
>
> I guess with only 5 or 6 annotations (and that's all the JSR consists
of;-) if changing/improving only one or two of these was what's needed,
this could be easiest as MR, otherwise 330 is history as it would require a
new JSR. JSR 330 was under JCP 2.7 and for final JSRs they normally stay
there, I don't think it can move to a newer version of the JCP:
https://jcp.org/en/resources/guide-maintenance#2_7
>
> The trouble is, both Spec Leads seem unresponsive or no longer around
(Rod Johnson left Pivotal, Pivotal in its current form does not even seem
JCP member and VMware may not be able or interested to step in for them)
maybe Pete knows best if Bob was, as until JSR 364 or even a new version of
the JSPA are finalized he could probably do it if he wants and has the time
for this right now (especially if another JSR like CDI 2 depends on it,
that can't be delayed even if this JSR may technically still be unaffected
by JCP 2.8+)
>
> Except for active corporate members Oracle, Red Hat or IBM the whole EG
practically disintegrated. Doug Lea and Tim Peirls may be involved
elsewhere (mostly OpenJDK from all I heard) but they have not been active
in the JCP or active JSRs recently. Google, we heard gave up the Spec Lead
in the first place, so it is unlikely under the current circumstances it
will play an active role. Jason VanZyl and Maven I know they at least use
JSR 330 quite a bit, so they should at least be interested in its future
direction. Thoughtworks I don't recall them to be involved and Martin
Fowler himself told me of his "allergy" against such form of
standardization, so I would not count on them here either.
>
> So assuming a separate @Inject spec shall be maintained there are 3
options:
> • Bob Lee (or the other Spec Lead) responds in a timely manner to
contact attempts by Antoine and ultimately the PMO (who needs to handle
such situations) in which case a simple MR was possible
> • A replacement of Maintenance Lead, along the lines of
https://jcp.org/ja/introduction/faq-speclead#slresigns (it is rarely the
case for an MR, but should work pretty much the same way here, so the main
candidates to replace a Spec Lead would be in that EG, hence Red Hat, IBM
or Oracle for most part;-) If such condition can't be resolved, both PMO
and JCP EC would be able to help find a suitable replacement, too
> • A whole new JSR is filed. Although it is often the case that the
Spec Lead(s) are the same, that is not necessary, especially if the old
ones moved on or can't do this any more right now.
> HTH,
> Werner
>
>
> On Thu, Jul 3, 2014 at 5:00 PM, Kito Mann <kito-public(a)virtua.com>
wrote:
> My $0.02 is that it's worth the effort to evolve JSR-330 for the
community as a whole. I've been on projects where they tend to use those
annotations even in a CDI environment, and it makes it much easier to
switch between Spring and CDI if necessary.
>
>
> On Wed, Jul 2, 2014 at 4: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
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev