I think the need for a NoSQL standard in Java EE has been apparent for some time. Unfortunately this is an API where complete industry consensus is probably impossible to ever reach (the same can probably be said for JPA, JSF and CDI too). From what I can tell, Otavio seems to have at least a viable solution and he is willing to make this happen finally. What I would suggest for most is just help evolve that before it goes final in Jakarta EE. The review process in standardization is sometimes all the catalyst that is needed to help mature an API in an otherwise fairly well understood use case now. CDI is probably the best example of this one can cite.
And, obviously I agree on MicroProfile Configuration. It is the most stabilized API in MicroProfile for a long unmet requirement in Java EE.
Reza Rahman
Principal Program Manager
Java on Azure
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 9/24/19 3:42 AM (GMT-05:00)
Subject: Re: [jakarta.ee-community] FEEDBACK FOR ALL OF US Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
Hi all,
can someone more involved with this maybe cast some light on whether JNoSQL had ever been considered to incubate at MicroProfile rather than in JakartaEE right away in the first place? If so, what were the reasons that idea was dismissed? If not, why not?
The dependency on MicroProfile Config would be a non-issue in the first place. Also – and I have repeatedly mentioned this before on the JNoSQL list – I think there's quite a bit of risk involved in starting with a JakartaEE specification whose implementation has not seen very much real world use and the APIs design decisions are fundamentally at odds with design decisions an open-source library (disclaimer: which until recently I led the development for) that's been real-world tested for almost a decade and has seen wide-spread adoption has made.
MicroProfile looks like a great platform to move projects to that aspire to become a JakartaEE standard eventually but need a bit of time, user feedback and potentially refinements. There's a bit of irony that the MicroProfile Config module probably has seen way more usage in production around the globe, still is not standardized first.
It might be too late for a move like that and of course it would need the discussion and decisions by every party involved, but I think it's worth considering.
Cheers,
Ollie
> Am 23.09.2019 um 16:25 schrieb Reza Rahman <
Reza.Rahman@xxxxxxxxxxxxx>:
>
> To be fair to Sebastian, I think the only thing he was trying to do is start a much needed conversation that no one seemed too eager to have and he did try it in the best way that he could. I have always admired Sebastian just as much as I do you, Otavio, Arjan, Josh, Ryan and so many people that spend their blood, sweat and tears basically on their own time trying to make some kind of difference.
>
> I would certainly appreciate more of a formal review of what was done in MicroProfile Configuration through a more structured standardization process. I suspect I am not alone and you are correct.
>
> I do think it is best we stick to technical matters. Dealing with that at scale virtually in a reasonably calm and rational matter is already hard enough.
>
> Reza Rahman
> Principal Program Manager
> Java on Azure
>
> Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
>
> From:
jakarta.ee-community-bounces@xxxxxxxxxxx <
jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Werner Keil
> Sent: Monday, September 23, 2019 9:57 AM
> To: Jakara EE community discussions <
jakarta.ee-community@xxxxxxxxxxx>
> Cc: MicroProfile <
microprofile@xxxxxxxxxxxxxxxx>
> Subject: Re: [jakarta.ee-community] FEEDBACK FOR ALL OF US Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
>
> Reza,
>
> Thanks for trying to summarize this in a compact and constructive way.
>
> There need to be a lot more voices and requirements heard before a meaningful Jakarta Config spec may be inspired by what MP does right now. A simple carbon copy with a new package name is like going to fail or meet almost no real demand, a lot like Java.util.logging which is largely ignored in favor of SLF4J or Log4J outside the JDK or some "Core Java" libraries.
>
> I was not aware Otavio approached the MP folks because we spoke about it only briefly in the NoSQL tracker or list.
> However, remember it was Sebastian, who after JCrete demanded in these forums and elsewhere like Jakarta EE blogs or his own, that Microprofile should become a "Jakarta Sandbox" no later than Jakarta EE 9 or 10 and that MP Config shall become the new spec.
>
> Unloading this on Otavio who demanded no such drastic thing from all I saw is totally unfair, especially by someone who worked with him for the same company before :-/
>
> I mainly spoke to Emily or Sebastian around JCrete, I assume Mark was consulted and agreed when they withdrew it.
>
> Werner
>
>
>
>
> Reza Rahman <
reza_rahman@xxxxxxxxx> schrieb am Mo., 23. Sep. 2019, 15:15:
> I am refocusing my part of the conversation to where I believe the productive context best resides and BCCig the rest. If anyone feels otherwise, they can feel free to re-adapt the recipients.
>
> I wholly agree with Werner. Given the current situation we can all pretty much see, it is best to add MicroProfile Configuration as an implementation level integration with Jakarta NoSQL rather than anything in the specification itself. Since we only have one implementation in the foreseeable future this should go a long way to meeting user needs. At the same token, it avoids devaluing Jakarta EE as a credible open standard roughly on par with Java EE. This also gives the powers to be some more time to sort things out properly if that is ever going to happen.
>
> Reza Rahman
> Principal Program Manager
> Java on Azure
>
> Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
>
> P.S. #1: Otavio, I did not realize you had approached the MicroProfile folks about this. Given what I thought you had said about MicroProfile and Jakarta EE alignment, the initial email on this thread confused me a bit. I figured you had changed your mind for some reason. Now I think I am getting the intermediate context of what might have transpired that I did not know about. Obviously, I commend your effort. I don't think it is completely in vain, in the least it demonstrates a good faith initiative.
>
> P.S. #2: Werner, I noticed Mark was the co-lead for the original Configuration JSR. Do you know what his views are with regards to standardization via Jakarta EE? Just curious more than anything else.
>
> On 9/22/2019 5:54 PM, Werner Keil wrote:
> Amelia,
>
> The thing with the "small hat" is something that would be nice to also respect when sharing such a giant piece of multiple threads with multiple mailing lists. The hat(s) are just too many and it feels like the Mad Hatter from Alice in Wonderland instead of a decent "hat" someone can actually wear or get something out of.
>
> I can only repeat what I already stated in the Jakarta NoSQL/JNoSQL mailing list, that it seems perfectly fine for an IMPLEMENTATION like JNoSQL to use MP Config in its current form, but the Spec/API (Jakarta NoSQL) will not be able to use it until MP Config was ready to graduate into a Jakarta Specification as well. Or rather the remains of
https://jcp.org/en/jsr/detail?id=382 which clearly stated
> "The Specification Leads and Expert Group agreed to withdraw the JSR and move it to the Jakarta EE spec process."
>
> As long as that does not happen or it's delayed because the Spec Leads are The Servant of two Masters, there is no way Jakarta NoSQL or other Jakarta EE specifications can use a standardized configuration effort.
>
> While MP Config is one of the few MP features that are reused by a couple of others, it is far from a true standard.
> The de facto standards would be Apache Commons Config. Other very promising efforts by Netflix like Archaius (also based on Commons Config) were archived now and no longer get maintained, but there are other very versatile efforts that scratch a similar itch like Apache Tamaya or Helidon Config by Dmitry who also provided input to this thread. Helidon Config and Helidon as a whole have no dependency on MicroProfile except a small dedicated "microprofile bridge" that also uses MP config, but just in this module.
>
> For implementation projects like JNoSQL there is more than one option for configuration and MP Config is just one iof them, it is far from certain that it must be used. For the Spec until a Jakarta configuration effort is approved by the Spec Committee or even proposed there, Jakarta NoSQL will have to substitute any configuration elements on that level. Until that could be replaced with a standard, just like MicroProfile would if the config modules were superseded by a Jakarta Config standard.
>
> Werner
>
>
>
>
> On Sun, Sep 22, 2019 at 11:10 PM Amelia Eiras <
aeiras@xxxxxxxxxxxxx> wrote:
> Hola from home OSS Community,
>
> Otavio— as the author who started this thread, how can we help you be the VERY example of proper OSS outreach via the formal mediums utilized by the MicroProfile Community?
> You chose to send this msg to the Jakarta EE spec leads forum, do you actually think they get to decide the MicroProfile future?
> This thread started as a fail of an outreach from your part. I get it, OC1 travels and exhausting, it happens. NOW— you are a MP Committer, you are a Jakarta EE Committer— both communities have their formal outlets to discuss stuff. Therefore, let our future actions show that you/me/us, in both communities, are not only paying attention to how we communicate but most importantly that we are capable of growing with the feedback provided thus far and that our actions show care.
>
> To everyone else— who nicely participated in this thread created during the hectic OC1 Sept 15th, please add your questions & follow-ups to the working document titled: EF IP Flow Q&A [2] that the MicroProfile Community started on June 1st via the Community Hangout with forum thread [1] along side with the thread in the correct forum.
>
> • [1]MicroProfile Shared Folder and EFSP Q&A Doc for Mike Milinkovich:
https://groups.google.com/forum/#!topic/microprofile/WF-kgDaZycc> • [2] EF IP Flow Q&A:
https://docs.google.com/document/d/1dUSLIhAnx5GkU8opnDZIzdtH_DtV06FA4ncfQAoOaDY/edit#heading=h.nj23sjpj5u97>
> +1 to Mark follow up.
>
> Reza— it is ok to if you feel frustrated & may choose to checkout out of any project as stated when you write “...has been pretty futile. Hence, I fear I must decline your kind invitation because I do not see it as worthwhile at the current time personally.” Kudos on stating it via open forums- after all, it is your chosen voice and voices are welcomed.
> I have stated multiple times via diverse mediums and happy do so again, anyone reading this thread can hopefully smile:
>
> “if you want to keep everyone happy, you should be selling ice-cream instead of working as a Contributor in OSS”— I stand by this msg. :)
>
> After spending 10 days sharing much with many of the traveling and locals who form our amazing ecosystem, I want to remind each one of us one of my favorite OSS blogs by Rich Bowen written in 11/18 yet valid today b/c its core is our individual voices in OSS communities.
> QUOTE:
> "By wearing the smallest hat possible –i.e., speaking with the voice with the least authority– you allow other people to be free to express their own dissenting opinions without feeling that they have already been overruled. This is in line with our culture of providing a level playing field, where all voices are equal, and all opinions are weighed the same."
>
> Twitter reminder circulating again given ASF 20yrs and that with events like ApacheCon the week before OC1 and OC1 it is worth the reminder:
https://twitter.com/zahedab/status/1175782872273178624?s=20> Lastly, the MicroProfile project has a flat structure where everyone who actively participates, gets the merit and gets to directly influence the project.
> Titles and vendors are meaningless - b/c we have chosen to protect its flat structure from day zero to now.
> What matters is each Contributors’ actions. Her/his merit is owned and acknowledgments become true by other individuals, who prioritize showing up, those whose actions lead by example on getting shit done and moving way from potential “drama”.
> Therefore, in MP any individual “entitlement" is crushed at each turn. We grow as a stronger community each day b/c we choose to ask more questions and avoid throwing assumptions.
> The respect to protect our time and that of others is everything. After all, investment in OSS demands each individual owning and being responsible for debt-thrown. You, me, us affirm via projective-mode, our stands that are hopefully fluid and adjusted as we fail and stand up to make not only ourselves but others just a tiny bit better.
> THAT is what makes MicroProfile welcome anyone who wants to try helping out do so without barriers or glamouring BS.
> My take: MicroProfile continues to state that it is not ready to be part of the Jakarta EE project.
> the MP community and its amazing fluid progress won’t be halt nor forced to join any project.
> This has nothing to do with the current reality of the Jakarta EE. MP is a complement to Jakarta EE, therefore it is up to the Jakarta EE contributors to utilize the MP APIs as she/he see it fit.
> Lets first and foremost focus on the independent growth of both communities. Reminder that the management of both communities is not the same.
> MP is fully run by its Community without layers. — This is my voice as a Microprofile Contributor.
>
> Coffee at hand, wishing everyone a beautiful rest of a Sunday/Monday!
>
>
> Amelia Eiras
>
https://twitter.com/ameliaeiras> Tribe:
https://tomitribe.com https://tribestream.io> OSS:
https://tomitribe.io https://microprofile.io>
>
> On Sep 22, 2019, at 4:58 AM, reza_rahman <
reza_rahman@xxxxxxxxx> wrote:
>
> From what I have observed time and again, trying to initiate any discussion around any of this in the MicroProfile alias has been pretty futile. Hence, I fear I must decline your kind invitation because I do not see it as worthwhile at the current time personally. If others deem differently, I am sure they will try to initiate discussion once again and hope it will go somewhere this time around.
>
> As I said, at the current time, my outlook is mostly to wait and see what happens. I am afraid there comes a point when that is all one is motivated to utilize their personal bandwidth towards and simply hope things will sort themselves out (or not).
>
> That all said, if a discussion does start and appears to progress towards some kind of sensible path forward different from past patterns, it might find the motivation to chime in. I do fairly closely watch the goings on there.
>
> Reza Rahman
> Principal Program Manager
> Java on Azure
>
> Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: Mark Little <
markclittle@xxxxxxxxx>
> Date: 9/22/19 6:40 AM (GMT-05:00)
> To: JakartaEE Spec Project Leadership discussions <
jakartaee-spec-project-leads@xxxxxxxxxxx>
> Subject: Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
>
> Reza, as has been pointed out to you several times already, whilst it’s fine to have discussions and opinions about other efforts happening elsewhere here, the final decisions for those efforts (e.g., Config) need to be driven by those communities (e.g., MP) and not by Jakarta EE. Just as I wouldn’t expect the MP community, say, to try to determine the future of a Jakarta EE specification or an open source effort happening in ASF, for example. So please take those thoughts and opinions to the right communities and let’s continue to respect them accordingly.
>
> The notion that Oracle cannot contribute to MP due to issues around IP flow is not news to a number of individuals/groups within MP but it is good that it is now out in the open. I know that those discussions had already started within MP lists months ago anyway but had stalled due to the concerted effort by everyone to get Jakarta EE 8 out. Now I believe they will restart, so once again a great time for people (yourself included) to get involved in the right lists and with the correct community. However, I strongly suggest that statements like "if MicroProfile even can be said to have much of a defined process” be left behind because they can be too easily misinterpreted in the negative and lead to conflicts and defensive behaviours that won’t result in any easy resolution. Let’s all stick to the facts and behave accordingly.
>
> Thanks,
>
> Mark.
>
>
>
> On 21 Sep 2019, at 15:32, reza_rahman <
reza_rahman@xxxxxxxxx> wrote:
>
> As Oracle leadership correctly mentioned during Oracle Code One, there are even bigger issues besides the fact that these are fundamentally different processes (if MicroProfile even can be said to have much of a defined process) and that this will introduce complexity, inconsistency and confusion basically forever for everyone involved - especially people that will need to advocate for this technology as independents. The IP flow for MicroProfile is murky. As a result, I don't think Oracle can even legally accept just incorporating MicroProfile into Jakarta EE without further proper standardization. This is indeed why Oracle employees are not allowed to contribute to MicroProfile today.
>
> The fact that MicroProfile Configuration is stable is the very reason it makes sense to properly assimilate and harmonize it into Jakarta EE as opposed to keep it in MicroProfile any more. In my view, that cannot be said of many other if any other MicroProfile specifications.
>
> Reza Rahman
> Principal Program Manager
> Java on Azure
>
> Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: Guillermo González de Agüero <
z06.guillermo@xxxxxxxxx>
> Date: 9/21/19 7:16 AM (GMT-05:00)
> To: JakartaEE Spec Project Leadership discussions <
jakartaee-spec-project-leads@xxxxxxxxxxx>
> Subject: Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
>
> One problem I see with Jakarta EE depending on MP specs is the different backward compatibility policies. MP only allows breaking compatibility on major versions while I expect Jakarta EE to stay even more conservative (similar to Java EE).
>
> In that sense, moving the Config spec to Jakarta EE (keeping the package) would basically stabilize its processes to the same level as Jakarta EE. The Config spec is pretty mature so this move wouldn't hurt it.
>
> But for the time being, and given that we all agree we don't want to change packages, I think it's reasonable for Jakarta NoSQL to depend on MP Config while we decide how to handle this situation. In the end, the API will be the same.
>
> El sáb., 21 sept. 2019 12:38, Emily Jiang <
emijiang6@xxxxxxxxxxxxxx> escribió:
> Scott,
> Jakarta JNoSQL needs to rely on MP Config. The discussion is to make MP Config adopted by Jakarta Specs without any package name changes. Jakarta specs are available to MP specs already. Personally, I would like to see MP specs to be adopted by Jakarta specs.
> Thanks
> Emily
>
>
>
> On Sep 19, 2019 at 3:38 pm, <Scott Kurz> wrote:
>
> As I'm reading this I'm trying to understand why there'd need to be a Jakarta Config spec in order for individual Jakarta specs like NoSQL, etc. to use MicroProfile Config.
>
> Is this fundamentally different from the individual Jakarta specs evolving to use new Java language features (a process not controlled by Jakarta).
>
> If it gets to the point that there are a set of special cases for Jakarta applications then maybe that would be a good time to launch a Jakarta Config spec, but for now couldn't individual specs just start using MP Config and see where it goes?
>
> That said.. I think it's smart to discuss first and get a consensus this isn't a completely wrong direction to head down..
>
> ------------------------------------------------------
> Scott Kurz
> WebSphere Batch and Compute Grid
> Development and Level 3 Team Lead
>
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102544>
skurz@xxxxxxxxxx> --------------------------------------------------------
>
> Mark Little ---09/19/2019 10:16:21 AM---+1 > On 18 Sep 2019, at 20:35, Josh Juneau <
juneau001@xxxxxxxxx> wrote:
>
> From: Mark Little <
markclittle@xxxxxxxxx>
> To: JakartaEE Spec Project Leadership discussions <
jakartaee-spec-project-leads@xxxxxxxxxxx>
> Date: 09/19/2019 10:16 AM
> Subject: [EXTERNAL] Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
> Sent by:
jakartaee-spec-project-leads-bounces@xxxxxxxxxxx>
>
>
>
> +1
> On 18 Sep 2019, at 20:35, Josh Juneau <
juneau001@xxxxxxxxx> wrote:
>
> I agree that the Jakarta EE Platform should adopt MicroProfile Config as a standard spec. However, I do not feel that there should be any need for renaming or changing the MicroProfile Config project. MicroProfile should still be able to continue evolving separately.
>
> Is it possible for Jakarta EE to adopt MicroProfile Config as the reference implementation for a "Jakarta EE Config" spec? In my mind, this would be much like Weld is the reference implementation for CDI, although namespaces are different between the two.
>
> Thanks
>
> Josh Juneau
>
juneau001@xxxxxxxxx>
http://jj-blogger.blogspot.com>
https://www.apress.com/us/search?query=Juneau> On Sep 18, 2019, at 7:35 PM, Emily Jiang <
emijiang6@xxxxxxxxxxxxxx> wrote:
>
>
> My preference is to go through a lightweight boarding process. I am against the idea of renaming packages.
> Thanks
> Emily
>
> On Sep 18, 2019 at 2:50 pm, <Kevin Sutter> wrote:
>
> Correct. Do not assume that just because we have to change javax to "jakarta" that it applies to all projects that might someday be associated with Jakarta EE. The javax rename is a special case due to Oracle requirements. As Dmitry points out this whole area needs further discussion.
>
> ---------------------------------------------------
> Kevin Sutter
> STSM, MicroProfile and Jakarta EE architect
> e-mail:
sutter@xxxxxxxxxx Twitter: @kwsutter
> phone: tl-553-3620 (office), 507-253-3620 (office)
> LinkedIn:
https://www.linkedin.com/in/kevinwsutter>
>
>
> From: "dmitry.kornilov" <
dmitry.kornilov@xxxxxxxxxx>
> To: JakartaEE Spec Project Leadership discussions <
jakartaee-spec-project-leads@xxxxxxxxxxx>
> Date: 09/18/2019 12:31 PM
> Subject: [EXTERNAL] Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
> Sent by:
jakartaee-spec-project-leads-bounces@xxxxxxxxxxx>
>
>
>
> It doesn't mean it. Where is an option to keep
microprofile.io namespace. We need to discuss it.
>
> - Dmitry
>
>
> -------- Исходное сообщение --------
> От: Otavio Santana <
otaviopolianasantana@xxxxxxxxx>
> Дата: 18.09.2019 10:56 (GMT-08:00)
> Кому: JakartaEE Spec Project Leadership discussions <
jakartaee-spec-project-leads@xxxxxxxxxxx>
> Тема: Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
>
> If move Eclipse MicroProfile into Jakarta EE process means a new package name such as jakarta.config.
> I don't think that is a good idea, because several people use Eclipse MicroProfile in production. So, we are going to have two projects to the same thing (one as MicroProfile and a second one as Jakarta), and sometimes it might mean copy/paste from/to projects. Therefore, smell code on both projects.
>
> On Wed, Sep 18, 2019 at 10:36 AM Dmitry Kornilov <
dmitry.kornilov@xxxxxxxxxx> wrote:
> Emily,
>
> I have a better idea. Let's make MP Config the first spec which follows Jakarta EE spec process. It will make it a full Jakarta EE citizen and open doors to other specs to use it. :)
>
> Thanks,
> Dmitry
>
> On 18 Sep 2019, at 05:38, Emily Jiang <
emijiang6@xxxxxxxxxxxxxx> wrote:
>
> Hi Otavio,
>
> As promised via our chat, I would share my view here.
> I totally agree that Configuration is very important for developing cloud-native microservices. It is a best practice in 12-Factor App to make microservice configurable. MicroProfile Config exists for exactly that reason. I strongly recommend to use it.
>
> As for your question of whether it is ok for Jakarta EE to depend on Eclipse MicroProfile Config, I think it is a good idea. Since many people including Adam Bien, myself, etc, seriously think Jakarta EE + MicroProfile are very powerful together and most of time they are needed at the same time, I strongly think it makes sense for Jakarta EE specs also utlising MicroProfile specs such as MicroProfile Config, etc. MicroProfile specs already pull in Jakarta EE specs, such as CDI, JAX-RS, JSON-B and JSON-P. Technically Jakarta EE should be able to pull in MicroProfile specs.
>
> If a lightweight onboarding process is needed to enable MicroProfile specs to be used in Jakarta Specs, I am ok with that. It is very important that MicroProfile and Jakarta continue complementing with each other not competing with each other.
>
> My 2cents.
> Emily
>
>
> On Sun, Sep 15, 2019 at 9:07 PM Otavio Santana <
otaviopolianasantana@xxxxxxxxx> wrote:
>
> Hello everyone, I have one question about the integration between Jakarta and Eclipse MicroProfile.
> As you know, Jakarta EE has the goal of the cloud-native application, so we tend to use good practices on that.
> There is the twelve-factor of an Appthat has the good practices of delivery your application in the cloud, and the third item there is the configuration.
>
> My whole point here is that need to have one API to all Jakarta EE project to use related to configuration. We might use this API on several projects such as JPA, JMS, and so on. Right now, we're facing this discussion on Jakarta NoSQL.
>
> My question is: Do we have plans to integrate Jakarta EE with Eclipse MicroProfile Configuration?
> I'm not happy with a copy/paste approach from a feature that already exists, because that means two points to maintain; furthermore, that is not good code practices.
>
> In the cloud, the perspective configuration will be like CDI, because several specifications are going to use it. Right now, my best shot to Jakarta NoSQL is to use only in the Reference implementation and put it as optional.
> --
> Otávio Santana
>
>
> twitter:
http://twitter.com/otaviojava> site:
http://about.me/otaviojava> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
>
ejiang@xxxxxxxxxx> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads>
>
>
> --
> Otávio Santana
>
>
> twitter:
http://twitter.com/otaviojava> site:
http://about.me/otaviojava> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads>
>
>
> _______________________________________________ jakartaee-spec-project-leads mailing
listjakartaee-spec-project-leads@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://
www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads>
>
>
> _______________________________________________ jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://
www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads>
> _______________________________________________
> jakartaee-spec-project-leads mailing list
>
jakartaee-spec-project-leads@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads>
> _______________________________________________
> jakarta.ee-community mailing list
>
jakarta.ee-community@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> <a href="" href="https://www.eclipse.org/mailman/listin" target="_blank" rel="noreferrer">https://www.eclipse.org/mailman/listin
> _______________________________________________
> jakarta.ee-community mailing list
>
jakarta.ee-community@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_mailman_listinfo_jakarta.ee-2Dcommunity&d=DwICAg&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=7iLfhC17FN-CWhuzo2HX1g0LRD1P0huXh9Zkd3m6MZ0&m=2DpzxscBv2w2DpJMqFH8a6ePkRML0awBuhTaoF-ylsM&s=ge90izvRUFVRXNOLXczQuGh_TTALIs2s2wbmDneKzwA&e=_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community