Partial specifications, transitive (in)compliance, embracing the cutting edge, communication

[David Blevins]

I see the TCK thread. I also see the CDI First thread. I'm not 100% sure my thoughts fit into either of those buckets. If I annoy someone by starting another thread, I apologize in advance. I'm all questions at this point.

Context:

- I'm looking at the Quarkus complaint on twitter that triggered the two threads above. It seems to be that Quarkus does not implement parts of CDI.

- I'm also aware that Jetty and Tomcat cannot currently pass the Servlet TCK; there are MicroProfile implementations built on those as well.

- I'm also aware that some of us are targeting Graal/native support for our MicroProfile implementations and it does not completely implement Java. I see some open source projects in our industry avoiding those Java features. It's not clear you can actually implement Java EE (in whole or part) natively without these features.

- I'm also aware that in the EJB side of the fence we ended up realizing it was too big and began splitting it up. Some EJB requirements are not "EE" requirements such as the embedded EJB container. I know that CDI has an "SE" flavor as well. We have not actually specified which we "include." I wonder what our overall strategy should be for situations were there are profiles of as specification.

- I wonder what our strategy should be if there is not a profile that matches what we need or are willing to allow; do we create our own "you must support A, B and C of spec Foo, all other features are optional"; do we say "all or nothing; if we say all or nothing what does this mean for our references to other specifications like JWT where we deliberately aim at a subset.

- I wonder what it means for TCK requirements to be all or nothing and transitive; MicroProfile requires TCK compliant Java EE specs, the Java EE specs require TCK compliant Java. Does that lead us to a place where nothing MicroProfile can touch Graal as it is not Java TCK compliant.

- I also wonder what our testing guarantees mean given we do not guarantee backwards compatibility even for the TCKs themselves.

- I wonder what the right path for us to take on these matters might be given our "run fast and break stuff" attitude.

- I wonder if we are rising to the challenge of effectively communicating the nature of MicroProfile.


About now you're all expecting a definitive conclusion :) Sorry, I don't have one. I'm all big questions and no answers at this point.

We've had the policy of not solving issues until they happen. There's clearly some room for our improvement in these topics. I'm not too sure what the actual improvements are.

High level I see two attitudes we can take:

- Lean into innovation. Clear away all obstacles that prevent us from touching and catering to the latest-greatest things regardless of their state or compliance.

- Lean into stability. Clear away all non-compliant things that prevent apps from running portably. Avoid the latest-greatest until those requirements are met.

I do think none of these routes allow us bad communicators. There'll be reforms we need to take either way. We don't want blog posts and twitter threads complaining about expectations not being met. I see that more as a failure to effectively communicate what innovation costs.

Anyway, I don't really expect responses as I'm all questions myself this point and haven't made a recommendation or a point. If anything, think of this as an invitation to think with me. (for whatever value that has) :)



--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

[David Blevins]

Found Tim's email.  Want to make sure he's in on the conversation.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

[Mark Little]

Great email and I do want to reply to some of it but can't at the moment as in Boston doing no-laptoo meetings. So apologies in advance if it takes me a few days to do so.

Mark.


Sent from my iPhone

> --
> 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/27D07DE0-3526-4E00-A7FF-5F30E7A78A52%40tomitribe.com.

[Ken Finnigan]

First off, just wanted to say that this is a great summation of some issues we need to address in the MicroProfile community.

What you've raised also covers some topics that I was thinking about prior to this weekend, but hadn't proposed anything to the community yet. Namely, whether MP should be using the entirety of a Jakarta EE spec as a base, or only a subset? And if a subset, how do we define that?

One example was raised by Steve, in another thread yesterday, around whether @ConversationScoped from CDI makes sense for MicroProfile. I would tend to agree that it doesn't, but then we enter the realm of complicating what MP means when we say "Based on CDI". It becomes "Based on CDI" with a list of exclusions. Maybe that's ok in the short term, but it's not a long term situation we would want.

Interestingly, MP has already done some excluding by deliberately removing the EL API from the CDI dependency we bring in. Had a chat with the Weld team and they said a runtime without an EL implementation would cause test failures when running the TCK. Without wanting to create a list of TCK tests we're ok with an implementation failing, it would be easier to more accurately define what in our dependencies we actually want to be part of MP.

From my perspective, MP has always been about fostering the innovation and exploration side of enterprise Java development. As such, I would be in favor of leaning more to the innovation side.

Leaning into stability, for me, more closely aligns with the goals of Jakarta EE than MicroProfile. And that's not a bad thing, many customers prefer stability over fast churning innovation.

This approach doesn't preclude MP from using parts of Jakarta EE as a base, like today, and it shouldn't preclude Jakarta EE deciding to use MP specs if it has reached a more stable stage (I'm presuming MP is part of a Working Group).

Likewise, I don't have the answers, but agree it's a problem we need to solve to clear up the confusion about what MP actually is seeking to do, and what it wants to base itself on top of.

Ken

--
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/6426BEE1-7B85-45D6-A9B4-6E5E4D860C84%40tomitribe.com.

[Emily Jiang]

David,

Servlet is not required by MicroProfile, so I don't think Servlet TCK is a concern for MicroProfile, but for Jakarta EE.

Personally I don't think innovation and compliance are against each other. In MicroProfile, we are innovating and don't fear failing fast. Even though we make mistakes, all of our compliant runtime still comply with TCKs and Specs. We then fix the spec, tck and then our impls follow them all the time. Therefore, I think we are operating with innovation and compliance hand in hand. In this way, our end users have clear view what the implementations support.

As mentioned in other TCK thread, I think we need to be clear and honest on the compliance, so that the end users know what they are getting and assumed something different.

Thanks

Emily

[Tim Zöller]

Thank you for adding me to the list, David!

First of all, it was never my intention to complain publicly about the state of MicroProfile or Quarkus, but to share the experience I had with integrating an existing, CDI based library with Quarkus. I have not contributed to any of these projects until now and have a deep respect for both communities and their achievements.

In the past months I had discussions about MicroProfile at conferences, usergroups and with customers. From this small "sample size", almost all of the people I talked to had a background with Java EE / Jakarta EE. Their lines of business were banks, insurances and car manufacturers here in Germany, which tend to be on the more conservative side of software development. They saw MicroProfile as a chance to introduce microservices into their existing Java EE ecosystem and move some workload into the cloud without having to deviate from their established and proven tech stack too much. 

In some of those discussions, Quarkus was a topic, too, as they were aiming to become MicroProfile compatible for some time now. Every time I brought up the fact, that they would not get full CDI support with Quarkus, my interlocutors were surprised. From the way the specification was communicated (many of them knew the "specification graphic", which was also quoted in the Twitter thread), nobody would have guessed that the Jakarta EE parts were not considered mandatory. On the other hand, my assumption is that they would not mind if they were optional. In both our own and our customers projects, we see that MicroProfile is being mixed with Jakarta EE features already - Bean Validation, JPA and JMS being the most prominent, one customer even using EJB in their mix. They are also aware, that this will limit the portability of their applications to other runtimes supporting Jakarta EE. At the same time they are looking forward to the upcoming MicroProfile innovations, like reactive messaging, lra and graphql. 

I believe that all the people I talked to would have decided to use MicroProfile for their applications, even if CDI had not been a part of it - they simply would have taken it from the Jakarta Specifications, as they did with other features, too. The premise for this is, that it would have to be clearly communicated. Ambiguity will scare adopters away - and partial support of specifications seems very ambiguous to me, as well as the fact that the process of passing the TCK is not verified, and can be claimed without proof.

Tim

[Amelia Eiras]

Hola Tim, 

Your continue participation in MicroProfile via testing the code & as #MPspeaker continues to improve this project, you are awesome! :) 

For those of you who might have missed Tim's tweet, HERE

David has nicely brought it to the MP forum for healthy acknowledgment & to re-focused all of us onto adding value and not just "distracting-noise" to  what actually was your intention Tim:  to share your findings via a blog and to not be passively frustrated alone. 

 #sharingIScaring, your feedback is going to improve MicroProfile and we need more of it to arrive to this forum!

 See you with health and smiles at Javaland! :) 

[Emily Jiang]

Thank you Tim for sharing your feedback and your obeservation!

First of all, let me clarify something. It is perfectly fine to use MicroProfile together with other Jakarta EE technologies. You can use MicroProfile with JPA, JMS and you won't get surprise if the runtime you are using certifying both MicroProfile and Jakarta EE/Jakarta EE related specs.

I think the only unclear question is CDI. I will say from my understanding complying with MicroProfile umbrella specification should pass all TCKs of the included subspecs, which includes CDI. I do agree that MicroProfile community need to clarify and state clearly in public. I think once the community is clear and runtime clearly declares their support statement. The end uers won't get surprises and understand what they will get from a particular runtime.

Thanks,

Emily

[Ondro Mihályi]

I agree with David's assessment and the conclusion that there are 2 obvious paths to move forward, either lean more towards innovation and loose the requirements or lean into stability avoiding too many exceptions and confusion. And I see that it doesn't fit to the 2 other threads as those are about how we interpret the current status and not which path we choose for the future.

However, before thinking about what we want in the future, we should agree on the present status and make sure we all interpret it in the same way. I studied the documents and past communication that lead to some key decisions. I admit that some sources are confusing and may be interpreted in different ways but some are pretty clear and exact, with a lot of evidence how most people interpret them. Here's my summary (forgive me if I'm wrong, I'm just trying to state plain facts):

* The initial MP release only contained JEE specs. Without them, it would be a blank release. This indicates that the 4 JEE specs included in MicroProfile are treated equally to the MicroProfile-only specs. With the difference that the TCK is not publicly available for most of them and that MicroProfile has had no influence on their TCK or any other resource. Even MP 3.2 spec lists the JEE and MP-only specs in the same list, with no special treatment.

* CDI has an open TCK and any implementation can use it to test compatibility

* Some JEE specs don't have an open and standalone TCK so it's almost impossible to test compatibility with them at this moment (Jakarta opens them up, but they're bundled together with tests for many other non-MP JEE specs). That's why we never required to prove that an MP implementation passes TCKs for those specs. I saw some opinions that it's enough that an MP impl passes MP-only TCKs but i didn't find it documented anywhere. And those who say so, forgot that CDI has an open spec which can be used in the same way as any other MP TCK. So there's no reason why MP impls wouldn't need to pass the CDI spec.

* The guidelines in the wiki (https://wiki.eclipse.org/MicroProfile/ArchGuidelines#CDI_Dependency) say that EL isn't included in MP and thus all specs should exclude the transitive dependency. The original reason to exclude the EL dependency was that it was leaking to the applications that build against MP API artifacts (https://github.com/eclipse/microprofile/issues/56). think we haven't clarified the consequences of this decision enough. I understand it in the way that the EL API artifact shouldn't be exposed to user applications as a transitive dependency so that portable MP apps don't rely on it at compile time. It doesn't mean that an MP implementation doesn't have to include it internally if it's required by something else. For example, if the CDI TCK requires some part of EL, then MP runtimes need to implement at least the necessary part of EL to pass the CDI TCK. We may come to an agreement that this is wrong and not expected and I'm not against it if it makes sense for the majority. But all the current resources I found don't specifically clarify it and I personally find this interpretation of the current status the only one possible. Simply, CDI is a required part of MP, MP impls should be compatible with all MP specs, to prove that they should pass all open TCKs, thus should pass the CDI TCK, which may require to implement a part of EL. Any other interpretation makes it currently impossible to prove any compliance with CDI. We would need to fork the CDI TCK and adjust it to the needs of MP. 

* CDI spec allows that CDI is used in Java SE, outside of container. In that case, it clearly states which parts are mandatory only when running in a JEE container. Again, we didn't clarify this specifically. Strictly speaking, MP container isn't automatically a JEE container. And without clarification, the only way how I interpret ithe CDI spec is that MP containers only need to meet the behavior specified by CDI for Java SE. Then it's clear that things like @ConversationScoped, @RequestScoped are not mandatory as for Java SE, only @ApplicatinScoped and @Dependent are required. Similarly, no JSF and JSP is required in MP and thus using EL doesn't even make sense. Another things is bean discovery where the spec says that Java SE implementations can't discover beans in an implicit archive by default and MP implementations that aren't also JEE containers should obey that.

I believe that all the above should be considered and clarified if we choose to lean more towards stability. If we choose to lean more towards flexibility and innovation, then we should at least know the consequences and possible confusion that is likely to follow if we don't address them well enough.

Ondro

[m.reza.rahman]

From the continued spontaneous and frankly very valuable social media dialog on this topic, one element of this debate appears to be passing the Java EE CDI TCK. I am honestly not so sure why that is such a big issue. Couldn't MicroProfile simply state that it is the Java SE CDI TCK that must be run? I imagine in the long run one could define a CDI microservices profile in addition to a Jakarta EE microservices profile.

As a side note, I have undertaken an effort to try to better understand MicroProfile adoption and non-adoption patterns. This to me seems critical in understanding what is actually likely to meet the best interests of adopters in terms of MicroProfile and Jakarta EE alignment. I will share the results of what I am able to understand here in addition to the existing data points I had already gathered with regards to Jakarta EE and MicroProfile alignment.

Whoever wishes to is welcome to use those data points as they see fit. Personally such data helps me sort my own thoughts out as well as challenging the set of biases that we all have as human beings. I wish I had done that a bit earlier but hopefully it is not too late to aid some people's thinking here.

Many thanks Tim for chiming in here, your blog entry as well as active participation in the subsequent dialog. To me everything you have done is more of what needs to be done. You should proudly consider it as valuable a contribution to the ecosystem as any. Sometimes lessons can be hard earned and painful but perhaps sometimes pain is what is necessary to make important change for some.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

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

--
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/da32f245-b62c-47bf-947c-edac0e9db0a1%40googlegroups.com.

[Mark Little]

+1

--
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/511df6aa-5067-4c27-aad9-4a2eed4d3b94%40googlegroups.com.

[m.reza.rahman]

I am sorry, but I see non-inclusive attitudes and language here. We should never be attempting to characterize any good faith dialog anywhere as "noise". This kind of language has the net effect of putting a damper on legitimate conversation. As long as the conversation is legitimate it is not our place to attempt to assign whatever value we happen to see or not see in it personally by using language like "noise". This is disrespectful to honorable people with honorable intentions. If we want to keep people engaged we should be making a conscious effort to avoid this kind of language.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

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

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CA%2BfW9O722cCb0bLqrjOQFrtmz%3DeOVXdFW5H75_w%3Djtxjjt2zsQ%40mail.gmail.com.

[Mike Milinkovich]

On 2020-02-11 9:12 p.m., m.reza.rahman wrote:

Couldn't MicroProfile simply state that it is the Java SE CDI TCK that must be run?

Maybe I am missing something, but isn't the Java SE CDI TCK a proprietary Oracle product whose use requires a license from Oracle? Assuming my understanding is correct, I think that answers the question on why it can't be used.

--

Mike Milinkovich

Executive Director | Eclipse Foundation, Inc.

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

@mmilinkov

+1.613.220.3223 (m)

[m.reza.rahman]

The CDI TCK (both the Java EE and Java SE variants) are actually one of the few that are available in the open source domain. Someone from Red Hat should confirm this, but I believe you do not require a license to run the CDI TCK (that's what I seem to remember from my CanDI/Resin certification days).

Regardless, as I have stated already, I don't think this needs to be addressed right now. We can just wait to properly address this with MicroProfile 4.0 when Jakarta EE 8 adopted, solving the entire license issue. I think that's what the "noisy, non-doer commentators" were suggesting in the social media dialog.

Hope that helps?

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

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: Mike Milinkovich <mike.mil...@eclipse-foundation.org>

Date: 2/12/20 1:23 PM (GMT+00:00)

To: microp...@googlegroups.com

Subject: Re: [microprofile] Re: Partial specifications, transitive (in)compliance, embracing the cutting edge, communication

[Emily Jiang]

CDI TCK has Apache License. More info is here.

Emily

mike.mi...@eclipse-foundation.org

@mmilinkov

+1.613.220.3223 (m)

[Mike Milinkovich]

Thank you both Reza and Emily. Good to know.

--

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/22139b70-1a6e-43b6-837d-81c6c84f9352%40googlegroups.com.

--

Mike Milinkovich

Executive Director | Eclipse Foundation, Inc.

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

@mmilinkov

+1.613.220.3223 (m)

[Scott Stark]

I have never viewed the use of Java EE APIs as defining a certified subset of any EE lite platform. It was a connivence to incorporate the enterprise APIs that developers were familiar with as a basis for defining a microservice runtime. I have always viewed an MP compliant runtime to be one that passes the associated MP TCKs. Nothing else is required. I would not be in favor of mandating that compliance includes a transitive dependence to the EE TCKs as that limits the possible implementations for MP runtimes. In the extreme, android or other non-Java SE compliant Java based runtimes should not be a requirement for branding an MP runtime as compatible.

[Leonardo Lima]

With that in mind, CDI is not a part of MP? As an end user, I'd never expect that from the documentation available in the Eclipse MicroProfile presentation. The last slide in particular, that defined MicroProfile 1.0 as ONLY Java EE specs, seems very empty with this in mind. As this is not "transitive dependency" - it is explicitly stated as part of MicroProfile. And every release since then doesn't make CDI/JAX-RS/JSON-P transitive - they're there as part of the gang, no special discrimination.

Then again, going to the actual Eclipse Microprofile page in Eclipse, you will see that CDI is NOT a part of MicroProfile (btw this page has only 3.1 as latest release, needs updating).

So, is CDI/JAX-RS part of MicroProfile or not? If it is not, can you please update Microprofile.io to clearly state that? If it is so, it seems that a clear definition of CDI TCK is required for MicroProfile, as many have stated before.

Regards,

Leonardo.

--

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/62da26b5-b082-41d6-b74f-44a3fece9209%40googlegroups.com.

[Emily Jiang]

Leonardo,

CDI together with JAX-RS, JSON-B, JSON-P is part of MP and we always include it in our umbrella releases.

going to the actual Eclipse Microprofile page in Eclipse, you will see that CDI is NOT a part of MicroProfile (btw this page has only 3.1 as latest release, needs updating).

The page you mentioned is for release specs for MP, which have not been released.  CDI, JSON-B, JSON-P, and JAX-RS were released by JavaEE, so they are not listed under the page above.

Well spotted with 3.1 as the last release! It needs to update to be 3.2 as 3.2 supercedes 3.1, which was decleared as faulty. John/Edwin, can you fix this as the release owner for 3.1/3.2.

Emily

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

[m.reza.rahman]

In this particular case, I am very curious once again how consensus in MicroProfile is actually reached. When will a vote be taken and a decision reached? Who determines when consensus has been reached?

How does an end user get to have input into that process? Is there any substantive commitment to considering such input?

What is the Eclipse Foundation best practices on these issues? Surely other Eclipse Foundation projects have answers to these questions? Does the Eclipse Foundation provide any guidance at all as project host as to what makes an effective project and what doesn't?

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

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: 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com>

Date: 2/13/20 6:21 PM (GMT+00:00)

To: Eclipse MicroProfile <microp...@googlegroups.com>

Subject: Re: [microprofile] Re: Partial specifications, transitive (in)compliance, embracing the cutting edge, communication

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/102c049c-f89d-4755-95e3-4bfa778d6d48%40googlegroups.com.

[Ivar Grimstad]

On Friday, February 14, 2020 at 5:37:38 AM UTC+1, Reza Rahman wrote:

In this particular case, I am very curious once again how consensus in MicroProfile is actually reached. When will a vote be taken and a decision reached? Who determines when consensus has been reached?

How does an end user get to have input into that process? Is there any substantive commitment to considering such input?

What is the Eclipse Foundation best practices on these issues? Surely other Eclipse Foundation projects have answers to these questions? Does the Eclipse Foundation provide any guidance at all as project host as to what makes an effective project and what doesn't?

There is probably a long answer to this, but there is a short version: 

It is up to the project to define how to make decisions. According to the Eclipse Development Process, Committers to a project have voting rights to affect the future of the Project.

See the handbook for the details: https://www.eclipse.org/projects/dev_process/#4_7_Committers_and_Contributors

 

Ivar

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/102c049c-f89d-4755-95e3-4bfa778d6d48%40googlegroups.com.

[m.reza.rahman]

If this is factual, I believe one of the committers should call for an open vote that everyone can see and settle this matter. Just like in the case of the JCP, end users and observers can decide to what extent this project overall respects and considers their input and hence is something they can stand behind or not.

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/c1d7f2d3-0ef0-4f4f-a55c-da0cd511fde4%40googlegroups.com.

[Emily Jiang]

With the currect package of MicroProfile, it is clear that any MicroProfile compilance needs to pass all sub specs included by the corresponding MP versions. It means it needs to pass JAX-RS, JSON-P, JSON-B and CDI TCKs as MP releases includes these specs and exposes the corresponding APIs. As for other MP specs, such Config, Fault Tolerance, etc, the compliance will just require the corresponding TCKs to be passed.

Therefore, I don't think a vote is necessary for whether CDI TCK needs to be pased to claim MP compliance, which was Tim's question. If you mean other issues to be voted, please clarify here.

Thanks

Emily

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/_vML3EzLKIE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e46526c.1c69fb81.abb9.b1ba%40mx.google.com.

--

Thanks
Emily

[m.reza.rahman]

I am no MicroProfile expert but frankly I see it the same way and I hope this is indeed already established consensus. If so, I suggest tightening up the documentation somewhere to explicitly state that MicroProfile umbrella compliance also means passing the CDI, JAX-RS, JSON-B and JSON-P TCKs. That way, we can all refer to that documentation when this question arises in the future. This of course also means that Quarkus cannot currently be considered fully MicroProfile compliant?

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A-C%2BR-jYoei9-%2BR3Bvo8Xz%3D92wx64zg98ur_uuMemxNGA%40mail.gmail.com.

[Mike Milinkovich]

On 2020-02-13 12:26 p.m., Scott Stark wrote:

I have never viewed the use of Java EE APIs as defining a certified subset of any EE lite platform. It was a connivence to incorporate the enterprise APIs that developers were familiar with as a basis for defining a microservice runtime. I have always viewed an MP compliant runtime to be one that passes the associated MP TCKs. Nothing else is required. I would not be in favor of mandating that compliance includes a transitive dependence to the EE TCKs as that limits the possible implementations for MP runtimes. In the extreme, android or other non-Java SE compliant Java based runtimes should not be a requirement for branding an MP runtime as compatible.

Based on some direct prior experience, it occurs to me that running on top of Android would be clearly okay once the MP specs using the Jakarta-ized versions of the CDI et al specs in the jakarta namespace. In fact, ensuring that freedom was a big part of the reason why we had to move to the jakarta namespace. But someone in Oracle might have an opinion about whether that scenario is okay as long as the specs are still using the javax namespaces.

On Tuesday, February 11, 2020 at 4:59:26 PM UTC-6, Emily Jiang wrote:

I think the only unclear question is CDI. I will say from my understanding complying with MicroProfile umbrella specification should pass all TCKs of the included subspecs, which includes CDI. I do agree that MicroProfile community need to clarify and state clearly in public. I think once the community is clear and runtime clearly declares their support statement. The end uers won't get surprises and understand what they will get from a particular runtime.

[Ken Finnigan]

We've never defined what "MP Compatibility" means, which is why I started the other thread.

There is no way, today, for implementations of MP to pass any base spec TCK from Java EE. Either because the TCK isn't available or because we've excluded aspects from CDI that would cause the TCK to fail.

Please continue discussion on the compatibility thread about what we want to see for MP 4.0.

For MP 3.3 and earlier we need to accept that it's vague at best, and move forward to resolving the problem for MP 4.0

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e46747d.1c69fb81.44623.aca2%40mx.google.com.

[Emily Jiang]

There is no way, today, for implementations of MP to pass any base spec TCK from Java EE. Either because the TCK isn't available or because we've excluded aspects from CDI that would cause the TCK to fail.

I just want to point out the statement "we've excluded aspects from CDI that would cause the TCK to fail." is only applicable to MP specs. In these MP specs, passing the corresponding TCKs are sufficient to claim compliance (no need to pass the full CDI TCKs).

As for the full MP umbrella release, we package the whole CDI without excluding anything though.

https://github.com/eclipse/microprofile/blob/master/pom.xml#L236

I think the discussion about CDI has 2 points: 1. MP takes the whole CDI on board. 2. Other Specs using some aspect of CDI.

Most people concentrates on the partial CDI used by MP spec. Actually, what determins whether CDI TCKs need to be passed is mandated by point 1.

We do need to straighten this compliance rules. I think WG will be able to sort it out.

Thanks

Emily

On Friday, February 14, 2020 at 1:32:26 PM UTC, Ken Finnigan wrote:

We've never defined what "MP Compatibility" means, which is why I started the other thread.

There is no way, today, for implementations of MP to pass any base spec TCK from Java EE. Either because the TCK isn't available or because we've excluded aspects from CDI that would cause the TCK to fail.

Please continue discussion on the compatibility thread about what we want to see for MP 4.0.

For MP 3.3 and earlier we need to accept that it's vague at best, and move forward to resolving the problem for MP 4.0

On Fri, Feb 14, 2020 at 5:20 AM m.reza.rahman <m.rez...@gmail.com> wrote:

I am no MicroProfile expert but frankly I see it the same way and I hope this is indeed already established consensus. If so, I suggest tightening up the documentation somewhere to explicitly state that MicroProfile umbrella compliance also means passing the CDI, JAX-RS, JSON-B and JSON-P TCKs. That way, we can all refer to that documentation when this question arises in the future. This of course also means that Quarkus cannot currently be considered fully MicroProfile compliant?

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

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: 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com>

Date: 2/14/20 10:08 AM (GMT+00:00)

To: MicroProfile <microp...@googlegroups.com>

Subject: Re: [microprofile] Re: Partial specifications, transitive (in)compliance, embracing the cutting edge, communication

With the currect package of MicroProfile, it is clear that any MicroProfile compilance needs to pass all sub specs included by the corresponding MP versions. It means it needs to pass JAX-RS, JSON-P, JSON-B and CDI TCKs as MP releases includes these specs and exposes the corresponding APIs. As for other MP specs, such Config, Fault Tolerance, etc, the compliance will just require the corresponding TCKs to be passed.

Therefore, I don't think a vote is necessary for whether CDI TCK needs to be pased to claim MP compliance, which was Tim's question. If you mean other issues to be voted, please clarify here.

Thanks

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c1d7f2d3-0ef0-4f4f-a55c-da0cd511fde4%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/_vML3EzLKIE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e46526c.1c69fb81.abb9.b1ba%40mx.google.com.

--

Thanks
Emily

--
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 microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A-C%2BR-jYoei9-%2BR3Bvo8Xz%3D92wx64zg98ur_uuMemxNGA%40mail.gmail.com.

--
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 microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e46747d.1c69fb81.44623.aca2%40mx.google.com.

[Ken Finnigan]

That's an error then, the platform shouldn't be including the entire CDI dependency as we've decided that we didn't want to include EL

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/b3abda1e-04cb-4d52-9e3b-a6de3f0708ac%40googlegroups.com.

[Scott Stark]

The problem is that there is no subset of the cdi-api spec that does
not include EL. There is no artifact currently that does not have that
dependency. The simple fact that we depend on the cdi-api artifact
does not imply the requirement of a full CDI runtime. Emily is stating
her belief, I have an opposite view. We will need to handle this in a
hangout.

[Ondro Mihályi]

I would like to stress there are no beliefs if somebody strictly follows what's written. There might be bugs but not beliefs.

Let's keep the conversation about compliance to plain facts.

The MP umbrella spec clearly says that CDI is part of MicroProfile. It doesn't even mention EL in any way, so, if MP requires CDI it also implicitly requires EL, period. EL is only mentioned in the Architecture board guidelines on wiki, but they are just that, guidelines.

The situation is different for individual MP. Most (or all) of them follow the arch. board guidelines and specifically state that EL is excluded from transitive dependencies. That means that the impl needs to provide CDI in order to pass the TCKs but no need to support EL. And also no need to pass the CDI TCK no MP TCK requires it.

Based on these facts, it's OK to say that runtimes that don't provide complete CDI can claim compatibility with individual MP specs if they pass their TCKs. But they can't claim compatibility with full MicroProfile. Actually, even part of EL must be supported by a full MicroProfile implementation in order to pass the CDI TCK to comply with CDI. This is possibly not what we intended but there's currently no way to ensure CDI compatibility without this. We would have to fork CDI and remove all references to EL. Or we would need to identify which tests in the CDI TCK can fail to claim MicroProfile compatibility.

This is the current situation. If we're going to question it, we can start questioning why we even write spec documents and TCKs. If we want something else, we should agree on how to change it and clarify the compatibility rules for future MP versions right in the spec documents, not on the mailing list or wiki.

Ondro

pi 14. 2. 2020 o 15:09 Scott Stark <sst...@redhat.com> napísal(a):

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/_vML3EzLKIE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAHyjRvDSSXzpRZjbWWqa-4D__04oTXu-1Ou-iw%3DTCe_-kL9LMA%40mail.gmail.com.

[Scott Stark]

What? Beliefs are what lives in the holes of missing facts. There is
no statement of fact that a compatible MP runtime must pass any form
of a CDI TCK. If I'm wrong, point to the statement of this
requirement.

[Ondro Mihályi]

The requirement is clear in the MicroProfile umbrella spec. It lists which specs are part of MicroProfile. 

With your reasoning, can you point to a statement that MicroProfile implementations need to pass all MP TCKs? You won't find it because this is obvious. In the same way as it's obvious that they need to comply with the other JEE specs because they are treated equally in the spec. Although in the past it was only possible to verify this using a TCK for CDI while the other 3 had closed source TCK.

Ondro

On Friday, February 14, 2020 at 3:41:32 PM UTC+1, Scott Stark wrote:

What? Beliefs are what lives in the holes of missing facts. There is
no statement of fact that a compatible MP runtime must pass any form
of a CDI TCK. If I'm wrong, point to the statement of this
requirement.

[Scott Stark]

No I cannot, hence MicroProfile compatibility is poorly defined.
MicroProfile did not adopt the Java/Jakarta EE where use of brands and
even IP flow was tied to passing a TCK. MicroProfile compatibility
needs to be explicitly defined.

[Roberto Cortez]

Hi,

I understand both sides.

While it would be possible to run and pass the CDI TCK (because it is open), it is not the case for JAX-RS and JSOP (as far as I’m aware). Meaning that only vendors with access to the full TCK's would be able to fully pass it, leaving out new implementors and small vendors. I believe this is not in the spirit that originated in this group but please correct me if I’m wrong.

I agree that the matter needs to be clarified. I also think that until MP moves all of the javax to jakarta dependencies (in 4.0), we shouldn’t demand implementors the javax TCK’s (by the sole reason that not all of them are freely available).

Cheers,
Roberto

> --
> 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/CAHyjRvDP6F9B3qL0APwsGtFz6X1xhmpMU_HOTziDx4hwZ2ebtA%40mail.gmail.com.

[Scott Stark]

That is no longer true as all of the TCKs have been moved to Jakarta
as of Jakarta EE 8, so you can grab the code and run against it.

[Dmitry Kornilov]

Maybe now is a right time to make a revision to CDI spec? Create another CDI lighter profile suitable for microservices frameworks and supporting compile time injection?

-- Dmitry

пт, 14 февр. 2020 г. в 15:09, Scott Stark <sst...@redhat.com>:

--
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/CAHyjRvDSSXzpRZjbWWqa-4D__04oTXu-1Ou-iw%3DTCe_-kL9LMA%40mail.gmail.com.

[Scott Stark]

Yes, most definitely it is time.

> You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/_vML3EzLKIE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CALgpM5T%2BDr%2BUBvTKKGo0e1vY_KqrETFikMTH14QpxRCY_BA8Vw%40mail.gmail.com.

[Emily Jiang]

I have been thinking about the same for some time now. I have raised an issue for the next CDI release (hopefully targetting for Jakarta EE9).

Emily

On Saturday, February 15, 2020 at 7:53:52 PM UTC-5, Scott Stark wrote:

Yes, most definitely it is time.

On Sat, Feb 15, 2020 at 5:30 PM Dmitry Kornilov <maid...@gmail.com> wrote:
>
> Maybe now is a right time to make a revision to CDI spec? Create another CDI lighter profile suitable for microservices frameworks and supporting compile time injection?
>
> -- Dmitry
>
> пт, 14 февр. 2020 г. в 15:09, Scott Stark <sst...@redhat.com>:
>>
>> The problem is that there is no subset of the cdi-api spec that does
>> not include EL. There is no artifact currently that does not have that
>> dependency. The simple fact that we depend on the cdi-api artifact
>> does not imply the requirement of a full CDI runtime. Emily is stating
>> her belief, I have an opposite view. We will need to handle this in a
>> hangout.
>>
>> On Fri, Feb 14, 2020 at 8:01 AM Ken Finnigan <k...@kenfinnigan.me> wrote:
>> >
>> > That's an error then, the platform shouldn't be including the entire CDI dependency as we've decided that we didn't want to include EL
>> >
>> > On Fri, Feb 14, 2020 at 8:55 AM 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:
>> >>>
>> >>> There is no way, today, for implementations of MP to pass any base spec TCK from Java EE. Either because the TCK isn't available or because we've excluded aspects from CDI that would cause the TCK to fail.
>> >>
>> >>
>> >>
>>
>> --
>> 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 microp...@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAHyjRvDSSXzpRZjbWWqa-4D__04oTXu-1Ou-iw%3DTCe_-kL9LMA%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/_vML3EzLKIE/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.