For what it's worth, there is no proposal to retire Concurrency
from Jakarta EE, or to cease evolution of this API. An alternative
proposal that could be voiced, could be to keep an implementation
project separate, for Concurrency. Moving it into GlassFish
Implementation project is, but one possible outcome here -- the
one that Steve is proposing. I am not offering any opinion on this
and I respect Steve's initiative and leadership. So long as we
have a consensus ... "make it so!"
(PS to avoid mixing up the +1's I will forward this separately to
the cu-dev list.)
I would like to see Jakarta Concurrency move forward. For
what it is worth, +1 for me.
Reza Rahman
Principal Program Manager
Java on Azure
Please note views expressed here are my own as an individual
community member and do not represent the views of my employer.
Sent via the
Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 6/7/19 4:39 AM (GMT-05:00)
Subject: [glassfish-dev] Jakarta Concurrency RI GitHub repo
All,
The Jakarta Concurrency project needs to be
converted into a specification project consisting of the API,
TCK and Spec document. Therefore the concurrency-api repo will
move to the new Jakarta Concurrency spec project. However
this leaves the concurrency-ri repo, it has been suggested
that as it is likely that the only user is GlassFish that the
repo be moved to the GlassFIsh project.
I am therefore calling a committer vote as
to whether the concurreny-ri repo should be accepted into to
the GlassFish project if the concurrency project votes in
favour.
+1 if you agree
0 to abstain
-1 to veto
I am +1
Thanks
Steve
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/glassfish-dev
