FEEDBACK FOR ALL OF US Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration

[Amelia Eiras]

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. [1]MicroProfile Shared Folder and EFSP Q&A Doc for Mike Milinkovich: https://groups.google.com/forum/#!topic/microprofile/WF-kgDaZycc
2. [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_...@lycos.com> 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 <markc...@gmail.com>

Date: 9/22/19 6:40 AM (GMT-05:00)

To: JakartaEE Spec Project Leadership discussions <jakartaee-spec...@eclipse.org>

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_...@lycos.com> 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.gu...@gmail.com>

Date: 9/21/19 7:16 AM (GMT-05:00)

To: JakartaEE Spec Project Leadership discussions <jakartaee-spec...@eclipse.org>

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 <emij...@googlemail.com> 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
sk...@us.ibm.com
--------------------------------------------------------

Mark Little ---09/19/2019 10:16:21 AM---+1 > On 18 Sep 2019, at 20:35, Josh Juneau <june...@gmail.com> wrote:

From: Mark Little <markc...@gmail.com>
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec...@eclipse.org>
Date: 09/19/2019 10:16 AM
Subject: [EXTERNAL] Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
Sent by: jakartaee-spec-pro...@eclipse.org

---

+1

On 18 Sep 2019, at 20:35, Josh Juneau <june...@gmail.com> 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
june...@gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/us/search?query=Juneau

On Sep 18, 2019, at 7:35 PM, Emily Jiang <emij...@googlemail.com> 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: sut...@us.ibm.com Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From: "dmitry.kornilov" <dmitry....@oracle.com>
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec...@eclipse.org>
Date: 09/18/2019 12:31 PM
Subject: [EXTERNAL] Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
Sent by: jakartaee-spec-pro...@eclipse.org


---




It doesn't mean it. Where is an option to keep microprofile.io namespace. We need to discuss it.

- Dmitry


-------- Исходное сообщение --------
От: Otavio Santana <otaviopoli...@gmail.com>
Дата: 18.09.2019 10:56 (GMT-08:00)
Кому: JakartaEE Spec Project Leadership discussions <jakartaee-spec...@eclipse.org>
Тема: 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....@oracle.com> 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 <emij...@googlemail.com> 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 <otaviopoli...@gmail.com> 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...@eclipse.org
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
eji...@apache.org
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec...@eclipse.org
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...@eclipse.org
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...@eclipse.org
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...@eclipse.org 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...@eclipse.org
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...@eclipse.org
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...@eclipse.org
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...@eclipse.org 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...@eclipse.org
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...@eclipse.org
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...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads

[Werner Keil]

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 

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org

To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[Werner Keil]

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_...@lycos.com> 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.

<a href="https://www.eclipse.org/mailman/listin

[Guillermo González de Agüero]

I totally agree MP future needs to be decided by the MP community. But IMHO here we are talking about two important Jakarta EE concerns:

- Is is acceptable for Jakarta EE to depend on MP specs?

- Do we want to ask MP to move their Config spec to Jakarta? (Wether they would like to do it or not is part of another discussion which would only take place if we decide we want to request them it in the first place).

I don't think Otavio's mail was out of scope for the original list given we has only trying to bootstrap a discussion about how Jakarta EE would like to proceeed regarding MP.

Regards,

Guillermo González de Agüero

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4C35BA48-F582-438D-B948-F758915E8F8D%40tomitribe.com.

[Guillermo González de Agüero]

Thanks Mike, to be honest I didn't expect a reply to the question :). It's absolutely great you provided it. That definitely clarifies things.

On Mon, Sep 23, 2019 at 7:24 PM Mike Milinkovich <mike.mil...@eclipse-foundation.org> wrote:

On 2019-09-23 11:29 a.m., Guillermo González de Agüero wrote:

- Is is acceptable for Jakarta EE to depend on MP specs?

Ultimately this is a decision of the Jakarta EE Steering Committee. But purely from a legal analysis the answer is no. It is not acceptable for a Jakarta EE specification to depend upon or include by reference one or more MicroProfile specifications. Of course, an implementation of a Jakarta EE spec could choose to do so, but I am pretty sure you're asking about specs.

The licensing and IP regimes are very different between Jakarta EE and MicroProfile. We cannot see a legal way that a Jakarta EE specification could be made available under the Eclipse Foundation Specification License, including complying with the patent requirements of the Eclipse Foundation IP Policy, while relying upon MicroProfile specs. In addition to IP concerns, MicroProfile specs are explicitly allowed to make breaking changes while Jakarta EE specs are not.

I hope a clear answer to that specific question is helpful to this discussion.

--

Mike Milinkovich

Executive Director | Eclipse Foundation, Inc.

mike.mil...@eclipse-foundation.org

@mmilinkov

+1.613.220.3223 (m)

[Werner Keil]

Thanks Mike for confirming what at least those who also work in the Spec Committee or similar groups assumed to be the case.

Werner 

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org

To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[Werner Keil]

Reza,

This was caught in a spam filter, but Mike gave the ultimate answer to the question, whether a Jakarta EE spec might use something like Spring or MicroProfile, which unsurprisingly was "no".

Most of those questions including a possible "graduation" or approval of something like "Jakarta Config" or similar are not only based on technical feasibility, but a lot more on license and legal terms like IP, etc. 

You mentioned a couple of names and some were involved with Java EE and Jakarta EE since EE 6 or earlier, while others may not even have worked with Java then or left High School. I don't blame either Sebastian or Otavio for their youth or "high spirits" but it seemed very unfair to bash Otavio for a fairly harmless question while the same who did seem to have at least ignored Sebastian's more radical proposals.

Those who have been around in the industry a bit longer know, that most things take a while. Oracle Developer Studio being based on NetBeans also took decades while then Sun CEO Scott McNeally and Larry Ellison announced it would happen "within weeks" after a round table discussion they once had ;-D

Werner

On Mon, Sep 23, 2019 at 4:25 PM Reza Rahman <Reza....@microsoft.com> wrote:

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.

https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[Oliver Drotbohm]

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....@microsoft.com>:
>
> 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-com...@eclipse.org <jakarta.ee-com...@eclipse.org> On Behalf Of Werner Keil
> Sent: Monday, September 23, 2019 9:57 AM
> To: Jakara EE community discussions <jakarta.ee...@eclipse.org>
> Cc: MicroProfile <microp...@googlegroups.com>

> Mark Little ---09/19/2019 10:16:21 AM---+1 > On 18 Sep 2019, at 20:35, Josh Juneau <june...@gmail.com> wrote:
>
> From: Mark Little <markc...@gmail.com>
> To: JakartaEE Spec Project Leadership discussions <jakartaee-spec...@eclipse.org>
> Date: 09/19/2019 10:16 AM
> Subject: [EXTERNAL] Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
> Sent by: jakartaee-spec-pro...@eclipse.org
>
>
>
>

> _______________________________________________ jakartaee-spec-project-leads mailing listjakartaee-sp...@eclipse.org 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...@eclipse.org
> 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...@eclipse.org
> 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...@eclipse.org
> 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...@eclipse.org 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...@eclipse.org
> 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...@eclipse.org
> 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...@eclipse.org
> 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...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> <a href="https://www.eclipse.org/mailman/listin
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee...@eclipse.org
> 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=

[Oliver Drotbohm]

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....@microsoft.com>:
>
> 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-com...@eclipse.org <jakarta.ee-com...@eclipse.org> On Behalf Of Werner Keil
> Sent: Monday, September 23, 2019 9:57 AM
> To: Jakara EE community discussions <jakarta.ee...@eclipse.org>
> Cc: MicroProfile <microp...@googlegroups.com>

> Mark Little ---09/19/2019 10:16:21 AM---+1 > On 18 Sep 2019, at 20:35, Josh Juneau <june...@gmail.com> wrote:
>
> From: Mark Little <markc...@gmail.com>
> To: JakartaEE Spec Project Leadership discussions <jakartaee-spec...@eclipse.org>
> Date: 09/19/2019 10:16 AM
> Subject: [EXTERNAL] Re: [jakartaee-spec-project-leads] Jakarta NoSQL and Eclipse MicroProfile Configuration
> Sent by: jakartaee-spec-pro...@eclipse.org
>
>
>
>

> _______________________________________________ jakartaee-spec-project-leads mailing listjakartaee-sp...@eclipse.org 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...@eclipse.org
> 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...@eclipse.org
> 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...@eclipse.org
> 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...@eclipse.org 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...@eclipse.org
> 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...@eclipse.org
> 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...@eclipse.org
> 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...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> <a href="https://www.eclipse.org/mailman/listin
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee...@eclipse.org
> 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=

[ali al]

Hello,

I'm new to this group. But I have a strong feeling that jee+mp works will not change spring-jee market share ( 80/20 something)( a metric for success)( note:I have been trying to convince my group to use jee +mp)

Would you please put all 'legal"/community things a step back ( different communities  but almost the same players/vendors) and focus on user expectations/requirements.

Elasticity/configurability/flexibility of presented "tool"s is very important. 

MP itself could not be successful with monolithic oriented processes and minds.

Neither jee nor mp would provide required achievement ( success metric) but together ( elastic jee+mp).

Configuration tool as part of elasticity is very important and as a simple user I want it in the framework's I work with. 

For the moment NSQL is not my concern but I should be sure that when it is my concern my framework already provided it or will be the first to provide it.

Hope this is not a distraction for you.

Ali

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAAGawe31tGPRui%2B%3D5KG_ddOAaH5yZD2mjETDDOzqOsvxs3qAFQ%40mail.gmail.com.

[Alex Lewis]

I'd like to think that Jakarta EE is currently in a window of opportunity to effect change and microprofile could still be considered a young project. As such, could we consider what would the ideal if we ignored the Legal, IP, etc. constraints initially and then see what needs to change to make that ideal a reality, knowing full well that compromises will need to be made by the communities on the way; we just need to be diligent and pragmatic on what those compromises are. I don't think this need be a lengthy process as long as everyone can commit to getting through that process positively and as quickly as possible.

Suggested ideals could be as follows, at least to start things off:

• A spec process that enables a fast evolution to meet real-world demands.
• Certain guarantees on portability and backwards compatibility. 
• A community-driven process that promotes contribution, enabling cognitive diversity; the wisdom of the crowd.
• An inclusive community where the individual is welcome regardless of which company they belong to. Where "money" is not a contributing factor.
• A single package structure. A single set of Documentation, to be able to use code-completion to search for what I may need "I.e. jakarta.<complete>", etc. "Java is the core, Jakarta is the framework".

Where I personally believe things may be going wrong right now, is this process is invoking an emotional, defensive stance on both sides. I can see how those in the MP community could be hearing a message of "We're Jakarta EE and obviously the good bits of MP must belong to Jakarta EE, hand it over" with the response being "Nope, nothing entitles Jakarta EE to MP, Jakarta EE can use it like anyone else". There is also a possible, or perceived, discounting of the emotional connection the MP community have to what they have created; even if that's not the intention from the Jakarta EE folks. To move projects into Jakarta EE, under the Jakarta EE process, could be seen as stealing their projects away from them and to remove or diminish their ability to readily contribute; a "thanks for all your hard work, we'll take it from here". 

I think if the message from Jakarta EE was: "Lets discuss what MP would need to fit nicely into Jakarta EE without losing the obvious positives that the MP community has created, its ecosystem and sense of inclusion, and not impede the MP community's ability to contribute", a change to the package name may become less contentious. Right now, if the message is effectively "Except assimilation or face competition", I'm not sure that's going to benefit Jakarta EE or MicroProfile and in general and may only go down in history as in-fighting that stifled both; whilst the industry is going wholesale on Spring.

HTH

p.s. I'm not suggesting Spring is bad :)

[Werner Keil]

Oli,

That was also discussed same as a possible JSR, but you see with the Config or MVC efforts, that both cause difficulties being used by other Jakarta EE specs. 

Mike stated here, that MP libraries may not be used by other specs for IP and compatibility reasons. 

JNoSQL and Jakarta NoSQL are both where Hibernate or TopLink used to be around 2001. A lot has changed there, but after Jboss hired Gavin and others they worked full time on it. Currently while Jakarta NoSQL is already used in production by a few companies, there is no full time developer like that, neither Otavio, nor others. As long as vendors don't get more involved, it may be slower than Hibernat and JPA, but while the Spring Framework uses that a lot, Hibernate was never merged into Spring itself either. Nor does the abstraction over multiple NoSQL paradigms and approaches belong to Microprofile. 

MP gathers patterns and best practices for Microservice development, a bit like Spring did from 2002 or 2003 on. 

Despite the fast version change driven entirely by PR folks in a few companies, it is on the level of Spring 1.2 rather than 2.0 at most. Do you think any Microprofile part has been downloaded over a Million times like Spring until 2.0?

I don't think so, thus it's evolution can be seen at a ore 2.0 Spring level now, even though the industry is more diverse now than 15+ years ago.

There are other NoSQL efforts at  Eclipse, Vert.x or Jetty, but all I saw the latter supports as of now is MongoDB. 

If some of the contributors to those projects were interested to help Jakarta NoSQL they would be able to benefit just like they and many others do from Servlet or other mature Jakarta EE specs. If they don't, then maybe it won't leave the incubator. JSRs were also withdrawn or went dormant for various reasons. 

I'm not in the PMC, but other than that I wear multiple hats regarding Jakarta EE and NoSQL, so I know several aspects of this discussion and decision making.

Werner 

https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[m.reza.rahman]

To be honest, it is impossible to completely figure out whether what is going on is driven by emotions, deliberate product strategy, budget/resourcing realities at some of these vendors or a bit of all of the above.

What I can confidently agree with is that I do think if the current situation persists, I don't see how it would not accelerate the migration to Spring for many legitimate reasons. Maybe in the end that was inevitable anyway and OK. Either way, I don't regret trying to do the right thing in advancing Java EE the past some years. I will still try to do what I can at least for a little while longer.

Reza Rahman

Principal Program Manager

Java on Azure

Please note views expressed here are my own and not represent the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6f9db4f7-ae84-4bb9-96d5-3ec111cf38ad%40googlegroups.com.

[Werner Keil]

Reza,

Thanks for the further arguments in each of these. 

In fact even EclipseLink added NoSQL support, but the how to reads utterly complex and requires a JCA Resource Adapter for each NoSQL database :-O

That's certainly not something you would like to use in a  "serverless" Microservice accessing one or more NoSQL data sources.

Werner 

reza_rahman <reza_...@lycos.com> schrieb am Di., 24. Sep. 2019, 14:56:

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.

https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[Oliver Drotbohm]

Hi all, Reza, Werner,

thanks for your comments. A couple of replies to some key points inline.

> Am 24.09.2019 um 13:08 schrieb Werner Keil <werne...@gmail.com>:
>
> JNoSQL and Jakarta NoSQL are both where Hibernate or TopLink used to be around 2001.

I don't agree with that analogy as it's completely ignoring the point I made: JPA did not start with a completely different design approach than the already existing and established open source projects. Even if the current implementation is in use at a few companies (is there actual data on this?), there's still a huge imbalance to the usage of something that has been used in production for almost *a decade*. That difference wouldn't be that significant if there wasn't such a difference in the fundamental design.

To quote Adam from a different thread:

> Am 25.09.2019 um 08:30 schrieb Adam Bien <ab...@adam-bien.com>:
>
> I also consider Jakarta EE 8 as the stable base, the "boring OS" with less frequent releases.
> For me MicroProfile is the reflection of current e.g. CNCF, also upcoming, standards with faster release cadence.

Given that attitude, why would you start a NoSQL spec in Jakarta EE? Or any new spec ever? In fact, you could almost consider MicroProfile an incubator for specs to eventually end up in Jakarta EE. I don't really want to get involved into discussions about where each group sees their purpose but I have yet to see a technical reason why jNoSQL should start in Jakarta EE, not MicroProfile. Unless you consider this…

> Am 24.09.2019 um 14:55 schrieb reza_rahman <reza_...@lycos.com>:
>
> I think the need for a NoSQL standard in Java EE has been apparent for some time.

That is the impression I get as well. "Need" as in "we need to have something to tackle this space, because it's a widely discussed topic". There's no technical need in Jakarta EE anywhere to build dedicated support into it *right away*. MicroProfile modules are in use in a lot of Java EE projects around the world. They're just doing fine. I guess most Java EE developers don't even bother.

As to the opposite, I think *a lot* of existing specifications would benefit from something like MP Config being a Jakarta EE standard as it's a cross cutting concern, just like CDI is. Following Adam's train of thought here, shouldn't new Jakarta EE specs naturally grow out of MicroProfile modules as those have seen different implementations and usage reports from different vendors.

> Am 24.09.2019 um 13:08 schrieb Werner Keil <werne...@gmail.com>:
>
> There are other NoSQL efforts at Eclipse, Vert.x or Jetty, but all I saw the latter supports as of now is MongoDB.

An interesting nuance here: Spring Data has shipped CDI extensions for most of its modules for over 8 years and people living in the Java EE universe use it. Intensively. It's not like there is no current solution to this problem.

> Am 24.09.2019 um 14:55 schrieb reza_rahman <reza_...@lycos.com>:
>
> What I would suggest for most is just help evolve that before it goes final in Jakarta EE.

That's been the gist of the responses I got so far, but that's a tricky and easy thing to do. Easy, because one just postpones the question, i.e. doesn't give an answer and we all now how much more expensive it is to fix consequences of early decisions downstream.

It's tricky, because the spec effort doesn't start with a clean slate. A lot of debatable questions are already answered in a way that we're in already in the "Oh, we've come such a long way with this already, let's not change this, as it's a lot of work" mode. And we're getting more and more into this mode each time someone says: bring this up during the actual spec work.

Especially as it's the first planned specification added to Jakarta EE, the way it gets handled sets the tone for what to expect from the process and the setup of the work between involved parties. I have huge admiration in the work that everyone does both for Jakarta EE in general as well as jNoSQL in particular (Kudos, Otavio!) but the overall process leaves a bit of a marred impression.

Cheers,
Ollie

> 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=iZTZWaRj9FSmPqw0BeDjNtlTvHZU-swK2uEUrSrvpnM&s=_0xZBx80800uPLs5-LHjhs6EWC8PkVWN9j1Z5-2KFvI&e=

[Oliver Drotbohm]

Hi all, Reza, Werner,

thanks for your comments. A couple of replies to some key points inline.

> Am 24.09.2019 um 13:08 schrieb Werner Keil <werne...@gmail.com>:
>
> JNoSQL and Jakarta NoSQL are both where Hibernate or TopLink used to be around 2001.

I don't agree with that analogy as it's completely ignoring the point I made: JPA did not start with a completely different design approach than the already existing and established open source projects. Even if the current implementation is in use at a few companies (is there actual data on this?), there's still a huge imbalance to the usage of something that has been used in production for almost *a decade*. That difference wouldn't be that significant if there wasn't such a difference in the fundamental design.

To quote Adam from a different thread:

> Am 25.09.2019 um 08:30 schrieb Adam Bien <ab...@adam-bien.com>:
>
> I also consider Jakarta EE 8 as the stable base, the "boring OS" with less frequent releases.
> For me MicroProfile is the reflection of current e.g. CNCF, also upcoming, standards with faster release cadence.

Given that attitude, why would you start a NoSQL spec in Jakarta EE? Or any new spec ever? In fact, you could almost consider MicroProfile an incubator for specs to eventually end up in Jakarta EE. I don't really want to get involved into discussions about where each group sees their purpose but I have yet to see a technical reason why jNoSQL should start in Jakarta EE, not MicroProfile. Unless you consider this…

> Am 24.09.2019 um 14:55 schrieb reza_rahman <reza_...@lycos.com>:
>
> I think the need for a NoSQL standard in Java EE has been apparent for some time.

That is the impression I get as well. "Need" as in "we need to have something to tackle this space, because it's a widely discussed topic". There's no technical need in Jakarta EE anywhere to build dedicated support into it *right away*. MicroProfile modules are in use in a lot of Java EE projects around the world. They're just doing fine. I guess most Java EE developers don't even bother.

As to the opposite, I think *a lot* of existing specifications would benefit from something like MP Config being a Jakarta EE standard as it's a cross cutting concern, just like CDI is. Following Adam's train of thought here, shouldn't new Jakarta EE specs naturally grow out of MicroProfile modules as those have seen different implementations and usage reports from different vendors.

> Am 24.09.2019 um 13:08 schrieb Werner Keil <werne...@gmail.com>:
>
> There are other NoSQL efforts at Eclipse, Vert.x or Jetty, but all I saw the latter supports as of now is MongoDB.

An interesting nuance here: Spring Data has shipped CDI extensions for most of its modules for over 8 years and people living in the Java EE universe use it. Intensively. It's not like there is no current solution to this problem.

> Am 24.09.2019 um 14:55 schrieb reza_rahman <reza_...@lycos.com>:
>
> What I would suggest for most is just help evolve that before it goes final in Jakarta EE.

That's been the gist of the responses I got so far, but that's a tricky and easy thing to do. Easy, because one just postpones the question, i.e. doesn't give an answer and we all now how much more expensive it is to fix consequences of early decisions downstream.

It's tricky, because the spec effort doesn't start with a clean slate. A lot of debatable questions are already answered in a way that we're in already in the "Oh, we've come such a long way with this already, let's not change this, as it's a lot of work" mode. And we're getting more and more into this mode each time someone says: bring this up during the actual spec work.

Especially as it's the first planned specification added to Jakarta EE, the way it gets handled sets the tone for what to expect from the process and the setup of the work between involved parties. I have huge respect for the work that everyone does both for Jakarta EE in general as well as jNoSQL in particular (Kudos, Otavio!) but the overall process leaves a bit of a marred impression.

[Guillermo González de Agüero]

Agreed.

El mié., 25 sept. 2019 17:17, reza_rahman <reza_...@lycos.com> escribió:

Personally I think NoSQL is a pretty good place to start if the stated goal of Jakarta EE is still to standardize cloud native Java in a nimble and timely fashion. Is it the most straightforward candidate? Clearly not - Jakarta Configuration probably would be. But it is what we have and that's good enough for me to try to see what can be done to make it at least as successful as practically possible given the inevitable complexity of the domain. If CDI and JSF can serve as many users as it has, so can Jakarta NoSQL with the right care and support.

https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[Werner Keil]

Reza/all,

I also think Jakarta EE is a better place because it aims at standards. 

Nothing is written completely in stone. Like synergies and a possible shift of certain features from Jakarta Rest to Security is possible and likely to happen, there could be features or new API elements ending up in Persistence for synergies between relational and non relational systems.

For IP and licensing reasons as Mike outlined it would be extremely difficult with a Microprofile subproject.

Aside from the basic principles of NoSQL systems nothing is written in stone yet. I hope either as individual or to represent your company if they are Eclipse and Jakarta WG members we may see Reza or Oli in the Jakarta NoSQL committer team or a couple of other vendors of systems or providers offering NoSQL services in the Cloud.

Where e.g. Failsafe or other MP features help, implementations and services can add them because certain aspects like cache, resilience or a reactive behavior go beyond the pure data access and will hardly be seen in the NoSQL spec or JPA itself. 

So what Adam said about mixing Jakarta EE with Spring, Microprofile or any of the other Microframeworks (JCON just has a nice overview and comparison of the most popular) is perfectly fine. And some special features may not make sense for standardization, but still be useful for certain projects and solutions.

Werner 

reza_rahman <reza_...@lycos.com> schrieb am Mi., 25. Sep. 2019, 17:17:

Personally I think NoSQL is a pretty good place to start if the stated goal of Jakarta EE is still to standardize cloud native Java in a nimble and timely fashion. Is it the most straightforward candidate? Clearly not - Jakarta Configuration probably would be. But it is what we have and that's good enough for me to try to see what can be done to make it at least as successful as practically possible given the inevitable complexity of the domain. If CDI and JSF can serve as many users as it has, so can Jakarta NoSQL with the right care and support.

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: Oliver Drotbohm <ogi...@pivotal.io>

https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[Ondro Mihályi]

Thank you all for commenting in this thread. Considering all opinions and ideas here, I'd like to propose one possible way to move forward.

I see that there's a great need to use MicroProfile Config or similar config spec in Jakarta EE. Although I share some of Amelia's concerns, I'd like something like this happen. It's a pain that Jakarta EE doesn't have a config spec and the fact that MicroProfile already has one shouldn't stand in the way. We should try to seek a way how to evolve some MicroProfile specs to be Jakarta EE friendly or even how to evolve them together within MicroProfile and Jakarta EE.

Having Config in Jakarta EE would solve the problem of configuration for the JNoSQL spec. But there's another issue raised by Oliver D. that JNoSQL might not be ready for Jakarta EE. Going back to the time when Otavio proposed the JNoSQL spec to MicroProfile, I think it was the other way around - MicroProfile wasn't ready to adopt the JNoSQL spec. So the only options for the spec were to stay within teh JCP (clearly far from ideal) or move to Jakarta EE. A lot has changed since then and it's possible that MicroProfile is now ready to adopt the JNoSQL spec. I would argue that it's even possible to evolve the spec initially under MicroProfile and then propose it for Jakarta EE. Maybe the spec could use the 'jakarta' prefix but use the MicroProfile processes to deliver the first final version of the spec. At some point in time it could "cemented" by the Jakarta process in included in Jakarta EE.

So here's my proposal (I won't go into detail now, just share my high-level idea): develop a process how to evolve specifications within MicroProfile but allow certain spec versions undergo the Jakarta spec process and be adopted by Jakarta EE.

The goals we need to seek:

• specs can be evolved in the same pace as current MicroProfile specs
• once an MP spec is adopted by Jakarta EE, it's allowed to develop it and release new non-Jakarta versions within MicroProfile
• Jakarta EE can easily adopt the MP spec without any legal concerns

It could mean that such specs would change the package prefix to jakarta. It could also mean that the license for the spec and the Eclipse IP review process would need to be changed for them to comply with Jakarta EE requirements. But this would only affect such specs which would be initially delivered within MP and then developed jointly within Jakarta EE and MP. Currently I have only these specs in mind: MP Config, Jakarta JNoSQL, MP Rest Client.

I believe that to specify how MicroProfile and Jakarta EE efforts colaborate is essential to build a strong Jakarta EE community and avoid splitting our efforts and spreading confusion.

Ondro

> > _______________________________________________ jakartaee-spec-project-leads mailing listjakartaee-spec-project-le...@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads

> > jakarta.e...@eclipse.org

> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > <a href="https://www.eclipse.org/mailman/listin
> > _______________________________________________
> > jakarta.ee-community mailing list

> > jakarta.e...@eclipse.org

> > 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
>

...

[Emily Jiang]

I commented this thread initially under Jakarta mailinglist. I have the following concerns:

1. Two versions of Config exist and cause confusion. If MicroProfile Config was brought forward to Jakarta, MicroProfile Config has little value to be continued except causing more confusion.

2. Since the namespace under Jakarta EE has to start with jakarta, there will be another migration from MicroProfile Config to Jakarta Config. Is this necessary?

With this, my suggestion is for some MicroProfile specifications to go through a lightweight eclipse process. I then ask whether this is enough for Jakarta specs to depend on MicroProfile specs.

I would like to see the mutual inclusion between MicroProfile and Jakarta EE specs, which means Jakarta EE specs can depend on the specially approved specs. For these specs to be adopted by Jakarta EE, we can even reinforce the backward incompatibility.

My 2cents

Emily

...

[Dennis Gesker]

Ondro/All:

This might be the most exciting, passionate and exciting thread I've seen in some time. 

I typically watch from the sidelines but I decided to chime in on Ondro's thread entry in the conversation because I felt that his last sentence "I believe that to specify how MicroProfile and Jakarta EE efforts colaborate is essential to build a strong Jakarta EE community and avoid splitting our efforts and spreading confusion" was exactly on point.

I really do think and believe that collaboration and communication is the winning combination. 

Do I want to see NoSQL as part of the Jakarta EE standard? Of course.

Why? Well, it is a widely used technology (I'm captain obvious on this point) and in my shop we've always used EE for data integration and reporting work.

Why an EE standard? Well, for our group the TCK represents more than just a "smoke test" that a lib or sub-system meshes well with the whole system. It implies predictability, dependability and durability. As with all software YMMV.

My first concern? Under the new governance model at Eclipse there is the potential for the cadence and evolution of Jarkarta to move very fast. Not unlike how fast the cadence is at OpenJDK. Yes, I'm clearly the odd man out on this point but the whole Java world seems to be moving REALLY fast these days so my group will have to get more comfortable with change. Is this change in speedin EE a given? No. A possibility? Yes. So, it's important that the TCK evolve to ensure standards.

My second concern? NIH (Not Invented Here) syndrome in our COLLECTIVE communities. If an element or sub-set of features is used regardless of the direction flow (EE --> MP or MP --> EE) that is a desirable and positive interaction. As long as...

1. The API meshes well for all concerned

2. The intent of the approach (why and how) is well communicated by the originating community.

3. No matter which project (EE/MP/XYZ) is the "upstream" project there is respect and good communication between the "upstream" and "downstream" projects

4. Always a plus if technical issues rise above personality or politics -- not that the last two do not matter -- but at the end of the day we all want great APIs

I really do think EE owes a great debt to MP in that MP moved fast while EE was mired in organizational and legal change that was at time frustrating, slow and even confusing. But, EE finally got on a good governance path and has a good home at the Eclipse Foundation. This is a HUGE relief for small companies like mine. At times that process was almost panic inducing.

By, comparison, reaching an understanding of how these communities will interact and collaborate seems a low hurdle. Why?  There are a LOT of sharp folks in both camps that do really great work. And, even when communicating passionately for the most part it seem like we have riches in terms of pretty good folks who are decent to each other. I don't see any real animosity but really good questions that circle around HOW these code bases will relate to each other.

That is SO healthy.

On the other hand I'm not crazy about hard and fast assertions or putting communities into hard categories. E.g. MP should be an incubator... C'mon these folks have been on their own and doing great. We all know you can't hear intonation in a persons voice in email sometimes so I totally see how that could be taken as some how as an idea that MP is being relegated to some lessor status of immature or not ready for prime time APIs. E.g. EE should be the community core. At first read this appeals to me because we really depend on EE. But, again, c'mon, the jump from Java EE to Jakarta EE is only a few months old. It's moving really fast IMHO but true deep traction right after a change just takes time.

Again, I do like standards and by this I mean the LCD upon which you can ALWAYS depend. But, this shouldn't mean that a particular implementation can't have some "special sauce." Case in point... For JPA if writing to the standard does it matter if it's EclipseLink or Hibernate? Performance issues or bench-marking aside, no, because you know your program will function in a portable and predictable way. But, the "special sauce" in an API like the @Audited decoration offered in Hibernate is a God send. It saves so much time. (Thank you Hibernate folks if any of you are on this thread.)

I find myself wondering -- and this is a very early stage idea -- if the answer is that the TCK be extended at the Eclipse Foundation from a compatibility kit to a "TCPBK" -- technology compatibility and performance benchmark kit -- meaning that for any implementation seeking to provide the LCD API for a desired standard (after discussion between project on what the API ought to look like and leaving from for growth) not only is compatibility checked but performance checked -- apples to apples -- and the most compliant AND performant becomes the REFERENCE IMPLEMENTATION. Then the RI integration into respective stacks/projects becomes discussion part two or maybe even abstracted in some fashion. Heck, even if the RI is rotated in/out upon releases at least we'll all know the RI is the most performant API at the time of a project's release and provides a the expected base functionality -- that might be a positive evolution and mechanism for HEALTHY competition -- no favorites, tribes or community split -- metrics based RIs.

This seems really doable under the Eclipse Foundation flag and existing processes. And, with respect for each other, the craft, and the craftsmanship of the APIs as a whole, the communication and cohesion in this rich ecosystem can be allowed to evolve with a maybe a bit less friction.

Keep in mind that is It's OK to let go of an idea, approach or even an entire API when a better NIH solution presents itself. E.g. Years ago we had our own home rolled libs for handling dates. Then Joda came on the scene. It was love at first site and we just mothballed our home rolled solution.

There are all kinds of rich libs I would like to see in EE but not sure the community as a whole would want them. E.g. We do a lot of GIS work. We really love the GeoTools libraries and how they interact with PostGIS (we just PosgreSQL in house.) Should this be a standard? I simply do not know. Are a lot of firms doing GIS work? Is there demand for a GIS standard in EE? Maybe. Maybe not. in the meantime we'll continue to load the libs into our container as a module. It would be great if it was a standard but it is in no way a show stopper.

Now, back to NoSQL:  These kinds of databases are everywhere. Clearly it would be a plus to have a very standardized lib -- that could be used pervasively easily integrated into MP or EE or XYZ.

My first instinct when this came up was that "Hey, why not just pivot off of Hibernate" -- JpaNo or something -- but if the community believes it needs to stand alone? Great. I'll go along with that.

However, given the passion on this thread... 

Perhaps we can shoot for a real "win-win-win" -- aim for a great API, level up the collaboration and communication between projects, and demonstrate to the community as a whole (and other communities that are observing us) that we are a healthy, rich and well functioning community. 

Maybe NoSql in our ecosystem could be the poster project for how we are getting it "right" in the java world of extended and profile libraries; libs outside core SE.

Ondro: Thank you for putting concisely what it took me a long message to communicate.

All: While at a small firm that hopes to contribute more as we grow I am so happy to be able to share some thoughts with this group. A group that consists of so many developers and parties I respect and whose work I admire.

Sincerely,

Dennis

...

[Jean-Francois James]

From a user perspective, I fully agree with Alex.

We are now at a crossroad where:

· Jakarta EE is ready to move forward,

· MicroProfile is feature-rich, well identified and has a value on its own.

While I can understand the ongoing discussions about package renaming, MicroProfile integration (or not) in Jakarta EE, IP flow etc … I’m afraid of their potential very bad impact in terms of end-user adoption. After the end of Java EE, people need to be reassured.

I think that both projects have their raison d'être and are complementary:

· MicroProfile with a focus on innovation with a fast cadence release and a fail-fast approach,

· Jakarta EE with a focus on long term stability.

Maybe I'm too naive, but it seems natural to me that some of the mature features of MicroProfile integrate into Jakarta EE. This is the case with MicroProfile Config and I do not see any benefit in other options:

. a cyclic dependency on both projects (MicroProfile depending on some Jakarta EE specs and Jakarta EE specs itself depending on some MicroProfile features),

. two concurrent config solutions.

For 2 years people have been waiting for the real start of Jakarta EE and are looking forward to seeing it evolve with the help of MicroProfile. If they have the feeling that things are not going to go as expected, many of them will turn away from the platform and choose other technologies. And there many of them inside and outside the Java ecosystem.

I invite both communities to discuss and find common ground. The future success of Jakarta EE and MicroProfile depends on it. And the user satisfaction!

[Werner Keil]

Dennis,

We invite Hibernate OGM to participate in Jakarta NoSQL, so similar to Wildfly already being a compatible Jakarta EE 8 implementation, it could also do with a NoSQL standard, if it wants to. Others e.g. Oli from Spring Data already share opinions and thoughts, though he has not actually contributed, but the spec is still very new and right now people are cleaning the dust around Jakarta EE 8.

As for Emily's question, Mike Milinkovich has already answered both and the critical point is more using the EFSP which MicroProfile doesn't. Unless individual parts of MicroProfile were to adopt that (seems unlikely unless it was broken into more dedicated sub-projects than right now) they are unusable by Jakarta EE specs. 

If MP config does not also come with its own implementation, indeed, it would require a Jakarta Config 1.0  more or less a drop-in-replacement for MP Config x.y which would then simply be archived. So yes, there would be an overlap for some time until a Jakarta equivalent was final, but then it would just be used by MP the way all those other specs are.

The alternative would either be no standardization in this space or even a competing new spec that has no direct relation with MP Config. Look at Helidon defining two paradigms under one roof, or the green room "Fork" of Jakarta Dependency Injection without the original Spec Leads having had any part in that.

Regards,

Werner

...

[Dennis Gesker]

Hi Werner:

Thanks for your informative response to my TLDR post. 

I do apologise for such a long message injected into the thread.

Me and team are small and on the peripheral. Speaking for my little team there are so many folks that we admire and respect (yourself included) driving things forward in these projects I couldn't resist but chime in to follow up on Ondro's post.

Ondro's one sentence was better than my entire post.

So many good an well meaning folks I'm sure a good collaborative path forward will be found. Really, the only bad outcome would be apathy. 

Reading up on other threads in this and related groups I don't think that will be a problem at all.

Again, thank you, Sir.

Dennis

   

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/497ed10d-e6e0-4e71-8e84-afb7b6737651%40googlegroups.com.

[Werner Keil]

Hi Dennis,

Thank you very much for the nice reply.

I am not sure which one-liner Ondro replied with? 

There's an entire paragraph with a lot of text, so let me just refer to the 3 bullet points at the end:

• specs can be evolved in the same pace as current MicroProfile specs
  

• The pace of any project is based on the resources and contributors that are willing and able to participate. Leaving aside a roadmap for Jakarta EE which the PMC, Steering Committee or other bodies like Spec Committee and Platform project have to shape (not to forget the Marketing Committee and its interests driven by say product availability or major conferences) that has a few more "cooks" than MicroProfile, the individual specs depend on a particular team and its activity.
  
  

• once an MP spec is adopted by Jakarta EE, it's allowed to develop it and release new non-Jakarta versions within MicroProfile
  

• I think Mike explained there is an IP problem, so a MP spec in question would have to adopt the EFSP for that to work. 
  The Config JSR was far from ideal because although sticking to the JSPA as much as others like CDI or Bean Validation did before the Spec Lead organization was named to be Eclipse Foundation. And neither Mark nor Emily work there. At most in his new role Ivar could be seen as representative of Eclipse Foundation, Emily works at IBM, Sebastian also does now and Mark is an Individual committer. 
  Every Jakarta EE spec names the primary or only contributing entity, e.g. Batch (a non-Oracle one;-) says 
  Copyright 2012 International Business Machines Corp. in files like https://github.com/eclipse-ee4j/batch-api/blob/master/api/src/main/java/javax/batch/api/Batchlet.java not some "fuzzy" Eclipse contributors.
  Others like Krazo say  Copyright © 2017, 2018 Ivar Grimstad (which is not completely true any more btw, since Christian also joined)
  Both Red Hat with phrases like  Copyright 2010, Red Hat, Inc., and individual contributors by the @authors tag. and Oracle with a similar header try to reflect that more contributors may exist, but they still are precise towards the main IP holder (@authors should be @author btw) 
    

• Jakarta EE can easily adopt the MP spec without any legal concerns
  

• Unless MP features were to change to a more distinct header and adopt the EFSP, I don't think they can be used.
  Also having a package cacophony with spec or API defined in jakarta.*, org.eclipse.* and maybe (for not yet migrated specs) also javax.* does not sound desirable especially for new specs with a clean slate. There has been a lot of that legacy in the JDK with org.ietf.*, org.omg.*, org.w3c.* and org.xml.* beside all the others like java or javax, 
  

A little more than one or 3 lines, but I hope it gives an idea what could work and what seems problematic, unless the MP features and their contributors (like in JSRs AFAIK EVERY SINGLE contributor who wrote more than 1-2 lines of code needs to be asked and approve) adopted all this, even with the prospect of multiple package names for specs it seems unreasonable at least on the spec level.

Nothing prevents any implementation, whether it's done under org.eclipse, org.apache, org.payara or whatever from using a MP API and Spec.

As NoSQL already went through all those "hoops" like stricter IP regime and everything else (the headers also look fine) it makes no sense to soften or destroy that now. The design and architecture decisions are not written in stone and everyone including Oli/Pivotal, IBM, Red Hat, Oracle or Payara are welcome to participate in the spec if they are committers to other specs already.

Nothing prevents MP features from using NoSQL or implementing it like it does with other specs, but until it stabilized and released the first major milestones that might be subject to the MP sandbox or some not yet defined "incubator".

Those of you who'll come to ECE in 2 weeks are more than welcome to attend the NoSQL session I took over from Otavio, because he had a schedule conflict: https://www.eclipsecon.org/europe2019/schedule/2019-10-22

At 5, there is not a very long time, but I plan to do QA then and of course the Community Night also has a Cloud Native Java Townhall https://wiki.eclipse.org/ECE_2019_Community_Day, where I plan to be for discussions or hacking around Jakarta NoSQL and EE in general.

Werner

...

[Ondro Mihályi]

Hi Werner,

I believe that the one liner Dennis meant was about finding a clear way how to evolve MicroProfile and Jakarta together and avoid splitting the effort. We should definitely avoid evolving 2 different specs that cover the same area (e.g. have both MP Config and Jakarta Config). We need to focus on what's possible and try to find solutions around legal obstacles. We hear a lot about what can't be done. We now need to discuss what is possible and how we can do it.

I can imagine that we can agree on a process how to elevate an MP spec to become a Jakarta spec that is acceptable for both MicroProfile and Jakarta EE. So that it can be also adopted by MP to replace the original spec and also evolve at the same pace with the same people behing it as under MP. And it can be adopted by Jakarta EE and used in other Jakarta specs. We can also clarify how to do the opposite - adopt Jakarta specs by MicroProfile, although that never was any issue within MicroProfile, which already includes several Java EE specs. But there's also a room for improvement, e.g. to integrate TCKs for included Jakarta EE specs into the MP TCK.

I'd love to hear some opinions how to make this happen.

Ondro

...

[Josh Juneau]

I had already provided my opinion on the initial jakarta.ee-community email list, but I wanted to be sure it was also reflected on the Eclipse MicroProfile mailing list.

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 at this time. MicroProfile should still be able to continue evolving separately. Perhaps eventually down the road, it would make sense to move the mature MicroProfile specifications under the governance of the Eclipse Specification Process...but now is not the time to do so.

[Werner Keil]

I think for some time they could and should exist in parallel. As with the whole discussion about backward compatibility the products and frameworks that now implement MP config should be able to use it at least till a possible Jakarta EE spec evolves and goes final. This won't happen overnight, but sooner or later like we see with Jakarta EE 8 and beyond, there should be a migration path.

@Ondro indeed, it should be done without duplication where possible (if one API has to be maintained in parallel until the other is stable enough, that is just fair, we saw also the never finalized JSR 275 dominate downloads for almost a decade until earlier this year, the final JSRs 363 and 385 exceeded its usage ;-) 

Especially for NoSQL since that has already undergone a transition most MP features also will need, if they wanted to turn into Jakarta EE specs, there is no real need to go back with that one. Like projects at Apache or Eclipse or JSRs it could be withdrawn and archived, if interest and adoption were not big enough, but creating a fork at MicroProfile would only increase such risk. Some mashup like features that make use of DB systems in a Cloud Native environment, maybe something like that, because not everything may be subject to standardization there, but the actual JPA/JDBC like NoSQL spec seems more suitable for standardization at Jakarta EE.

Werner

[Reza Rahman]

I don't know if this helps at all, but here is my view of what could be considered for standardization via Jakarta EE and what probably should not.

* MP Configuration - definitely. This is stable and long pending for incorporation into pretty much every Jakarta EE technology.

* MP JWT - definitely. This is mature and a long pending gap in Jakarta Security.

* MP Concurrency - definitely. This is mature and a long pending gap in Jakarta Concurrency.

* MP Fault Tolerance - maybe. It is still not certain how broadly applicable these patterns are.

* MP Open API - maybe but probably not. This is a Linux Foundation standard and those are not necessary all that stable or well adopted always.

* MP Rest Client - maybe but probably not. The last time this was attempted in the JCP there was no consensus that this is a generally useful approach that aligns with REST principles.

* MP Metrics - no. This feels very non-standard at the moment. There is likely an open standard that will emerge on this like Open Metrics.

* MP Health Check - no. This feels very non-standard at the moment. There is likely an open standard that will emerge on this. Is there even a nascent one?

* MP Open Tracing/Open Telemetry - no. This domain has far too much flux.

* MP Reactive* - no. This domain has far too much flux.

* MP GraphQL - no. This domain has far too much flux.

* MP LRA - no. This domain has far too much flux.

This is why I really think the signal vs. noise on this discussion is a little overblown sometimes. In the end, we are actually talking about changing not that much...

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.

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/87635c56-cead-4e7e-a7e4-dc9285f32dbe%40googlegroups.com.

[Werner Keil]

Reza,

Thanks a lot for your assertion. It almost seems a bit hidden in this thread, but hopefully some of it can be discussed further at places like EclipseCon Europe in two weeks.

- Configuration, I agree, it should have been standardized some while ago and there are many places in Jakarta EE where niches got created instead.

- JWT I would say "maybe" but not a must. It could be an extension on top of Jakarta Security without a huge drawback.

What do you mean with "Microprofile Concurrency"? I guess the Context Propagation feature?

It is still relatively new and small, consisting of less than a handful of elements. All relevant contributors are either from Red Hat or IBM which at least commercially and when it comes to patents or IP are now the same company anyway. So if the contributors were happy to move it to a future version of Jakarta Concurrency it sounds like a low hanging fruit.

The others I agree are either premature or not really standard-worthy.

Werner

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Reza Rahman]

Yes, I meant context propagation. Feel free to use these views as you see fit. I won't be at EclipseCon. Hope others here and elsewhere express some views too other than the perhaps overly defensive ones on one "side" or the "other".

These are of course just my views. My hope is that we will run a detailed Jakarta EE future features survey soon just like I once help did at Oracle for Java EE 8. Some of the more obvious MP features could be put into that survey and see what people at scale actually need in terms of Jakarta EE. We also need to put some of the obvious purely Jakarta stuff in the survey and see how people prioritize them now. For example:

* NoSQL
* Deprecating EJB (move functionality to Jakarta Messaging, Concurrency, etc)
* @ManagedExecutorServiceDefinition
* MVC

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.

P.S.: With regards to MP JWT, I know what you mean. Personally though I'd prefer Jakarta EE to be feature complete and relatively standalone. That's why moving the JWT piece matters even if it does not actually mean an API change or maybe even not that much work.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5d4899d8-8782-4462-b8c7-c5b95b5d9563%40googlegroups.com.

[John Hogan]

I like the message Alex put forward, that’s certainly how I beiieve it should be.

John Hogan

“Lets discuss what MP would need to fit nicely into Jakarta EE without losing the obvious positives that the MP community has created, its ecosystem and sense of inclusion, and not impede the MP community's ability to contribute", a change to the package name may become less contentious”

[Ryan Cuprak]

I agree with your points. I am concerned that the longer this debate continues the more damage it does to the Java enterprise ecosystem. There are technologies in MP that Jakarta EE does need (like the configuration API). My understanding of "Java EE" was always that it standardized enterprise technologies once they've reached a certain level of maturity/usage. My opinion is that moving a project into Jakarta EE is an evolution of the project. It doesn't mean that the project is no longer used by MicroProfile or slows down its releases etc. For end-users this just means that something like MP Configuration is required by all Jakarta EE 10 implementations etc.

-Ryan

[Werner Keil]

Mike Milinkovich made pretty clear also in last week's Jakarta EE / Cloud Native townhall meeting at ECE, what would be necessary, to accept any current Microprofile technology for Jakarta EE.

You are perfectly right, that turning any such sub-project into a Jakarta EE spec would not necessarily slow it down compared to the current development. Coordination with others has to happen either way, the Metric Mishap in the latest MP version showed, that is nothing, a less formal way of working on them prevents or makes unnecessary. 

If any of the MP features in question qualified for that, Mike said, it is not an issue for Eclipse Foundation, whether the package was org.eclipse.microprofile.something or jakarta.something. That is for the platform and others to figure out, if they wanted a more consistent package naming convention or not. The important part is following the Eclipse Specification Process. 

Where name changes were beneficial, the inevitable change of most or all via the "Big Bang" for Jakarta EE 9 could also be a chance for a few to be included. If so many have to be refactored, one or two more would not really hurt. And e.g. Config or others would not really affect existing specs unless those were allowed to use them, so they could potentially be added to the platform with Jakarta EE 9, so better integration can happen in later releases.

Werner

[Ryan Cuprak]

 I wasn’t able to join the townhall but I know the devil is in the details. My statement was just from the perspective of a developer - I just hope it gets sorted out sooner than later.

 -Ryan

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5b84fafe-bd56-41b7-86d6-ce675d364839%40googlegroups.com.