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 RahmanPrincipal Program ManagerJava on AzurePlease 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 smartphoneReza, 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.-------- 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 ConfigurationThe 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 RahmanPrincipal Program ManagerJava on AzurePlease 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 ConfigurationOne 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.ThanksEmilyAs 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
EmilyOn 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
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
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.
--
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.
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
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Werner
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.
--
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.
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.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
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.
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 RahmanPrincipal Program ManagerJava on AzurePlease 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>
> > _______________________________________________ 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
> > 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
> > 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
>
...
...
...
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!
...
--
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.
...
...
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.
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.
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.
-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.