Defining "MP Compatible" for MP 4.0

[Ken Finnigan]

All,

There may be many assumptions about what "MP Compatible" means for an implementation, but I took a look through the wiki and couldn't find anything obviously documented as to a clear definition.

Is the definition documented anywhere?

If it's not, which I believe to be the case, then I'd like to propose that for MP 4.0 we define what "MP Compatible" means for both the whole platform, and for an individual specification.

Once we've agreed on a definition of what they mean, we can clearly document it in the wiki and link to that definition from anywhere else that might be needed.

First thing to agree is that this is worth clearly defining. I think it is, but it's a valid question to ask.

After we agree it needs defining, we can discuss what it means.

Ken

[Edwin Derks]

Hi Ken,

Good initiative to formally start this discussion. It is probably also a good topic to discuss during the Hangout or in place of the WG discussion as soon as that’s finished?

Edwin

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

[Ken Finnigan]

Can certainly be discussed in the Hangout, but I hope we're able to reach agreement on this without waiting for the WG discussion to be resolved.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAE35TCMQz77UMf1%3Dcjyg7ks%2Bihj-zYd5NoDrQkKkM3zhU9B0BA%40mail.gmail.com.

[Mark Little]

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe7PxG6Db3UjygYRAt7V9Kn8OP1XX-uHpS%3DfUZKVF7VwpA%40mail.gmail.com.

[Alasdair Nottingham]

I’m not sure if I’ll be on the conference call, but I think the point of a mail chain is to have discussion open to people who can’t make it so I’ll put my perspective in this chain.

My understanding has always been that to be MicroProfile compatible you need to implement all the specs in MicroProfile which includes CDI, JSON-P, JSON-B and JAX-RS. I think for the 4 from Java EE historically it hasn’t necessarily been possible to run the TCKs, so I’d probably give a pass to an implementation on passing the TCK if they writer believed they were compliant. I think running the TCK from Jakarta EE 8 would be reasonable.

I know there is a view that CDI, JSON-P, JSON-B and JAX-RS are just API dependencies, but I struggle with that on the basis that if you implement the API in a totally different way from anyone else that isn’t really a stable platform someone could depend on, so I think it needs to be behavioural expectation as well as a pure API one.

Just my 2 cents worth
Alasdair

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CA%2BfW9O6yPM0r663dOV5hZB3mLZgv%2BU0vVM9jcUx3Cy4Bhnbjjw%40mail.gmail.com.

[Ken Finnigan]

Thanks Alasdair, yes I think it's important to have most of the discussion on this thread, if only as a way to document what ends up being decided.

I agree that requiring TCKs of the base specs isn't something we can force for Java EE 8 based dependencies. In MP 4.0 moving to Jakarta EE 8, it does allow the possibility of requiring future implementations to pass the base specification TCKs as well.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/2981CDE4-2280-4266-8331-DE61509DF966%40gmail.com.

[Steve Millidge]

I too won't be attending the calls mainly due to them falling at a bad time in the UK. I think these things should be decided asynch. 

+1 to what Alasdair says. Maybe there is some bits in the base specs that are not relevant i.e. Conversation Scoped but these should be made explicit.

[Rudy De Busscher]

Since many runtimes are building on top of the Java EE spec implementations, they are fully compliant with the Java EE TCK also.

That means that those who aren't using a fully compatible implementation of JAX-RS, CDI or the JSON ones, the code which runs fine on some runtimes will fail on others.

You can see that within MP Starter where several classes needed adjustments to be able to run on Quarkus.

So requiring that the Jakarta EE TCK (CDI, JAX-RS, JSON-B and JSON-B) pass on a runtime, at the moment we switch to the Jakarta EE dependencies, is the only solution to make sure that all runtimes can run the same application.

Rudy

[Ken Finnigan]

I'm not familiar with the Jakarta TCKs, so I would appreciate someone more knowledgeable commenting on the question below.

In https://wiki.eclipse.org/MicroProfile/ArchGuidelines#CDI_Dependency we define that the use of CDI as a dependency must exclude EL API as a transitive. Can the CDI TCK be run without an EL implementation being present and pass?

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/586ce749-a8ef-4fa1-b81b-e2b361f5343e%40googlegroups.com.

[m.reza.rahman]

It appears I am obligated to chime in here, so I will comply.

As far as I can tell, most developers are caught seriously off guard that MicroProfile does not require compliance to the Java EE specifications it references. I am too. The widely circulated MicroProfile component graphic is perhaps the greatest contributor to this confusion. To be completely honest, the alternative is far too mind bending for the average developer in the enterprise to understand and communicate. Without keeping the concept of platform compliance simple, I suspect MicroProfile will lose all but cowboy coders, hobbyists and the sort that does not care much about anything that aims to be a standard or specification of some kind anyway.

Where does that leave things like Quarkus? I think where it leaves it is that it needs to stand on it's own two feet instead of dragging the majority of the MicroProfile effort and potentially Jakarta EE too into pretty funky territory. In the long run, the Quarkus team should work it out with the CDI community. I don't think having the "rebel non-conformist" image hurts Quarkus that much given the audience it appears to be trying to draw. If I am wrong on that, the engineering team behind Quarkus needs to figure out how to fully support CDI at least for now.

That's it. Hope it helps. Need to get some sleep and get ready for an all day meeting and afternoon lecture now.

Peace and hope for all of us that have poured our heart and soul into this stuff for decades now. Maybe in the end some of us have just had enough and need to move on. I certainly feel pretty ready to do that now.

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/2981CDE4-2280-4266-8331-DE61509DF966%40gmail.com.

[Ken Finnigan]

Reza,

Thanks for taking the time to respond.

As a brief recap to make sure I'm completely understanding. You would be in favor of MP 4.0 requiring that the Jakarta EE TCKs of the "base specs" are passed by implementations, and that the MP platform spec graphic is adjusted so that the "base specs" are in a separate layer? Or would enforcing Jakarta EE TCK execution mean that the graphic doesn't need adjusting?

Thanks

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e41cd96.1c69fb81.17d8b.433c%40mx.google.com.

[Reza Rahman]

I just want to make sure people don't run into surprises. The graphic is fine if we just tighten up the TCK details. The graphic adds a sense of badly needed cohesion with Jakarta EE APIs and MicroProfile. It is also far too pervasive at this point. Putting in a separation now is just going to add to confusion and increase unnecessary friction between communities I believe.

Waiting until MicroProfile 4.0 is perfectly fine. I think at this point we have raised enough awareness around the issue with Quarkus and I hope the Quarkus team will be a bit more careful about how they document and position current CDI support. The majority of the other MicroProfile implementations are fine anyway.

I want to reinforce that there is absolutely no question of any hostility, latent or salient, on my part in any of this. If I didn't care much for success or failure of MicroProfile, I would have said and done absolutely nothing and let more people just stumble into this and get frustrated. I hope that is clear.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4pCydwLxdA-aj6pzQCzxw2HZuGrmk9yNUyG%2BZwyK5%3D0A%40mail.gmail.com.

[Emily Jiang]

I also think that since MP umbrella release pulls in CDI, JAX-RS, JSON-B and JSON-P, any claim on the compliance of MP umbrella releases must pass all TCKs defined by all of the enclosed specs.

Emily

On Tuesday, February 11, 2020 at 1:57:45 PM UTC, Reza Rahman wrote:

I just want to make sure people don't run into surprises. The graphic is fine if we just tighten up the TCK details. The graphic adds a sense of badly needed cohesion with Jakarta EE APIs and MicroProfile. It is also far too pervasive at this point. Putting in a separation now is just going to add to confusion and increase unnecessary friction between communities I believe.

Waiting until MicroProfile 4.0 is perfectly fine. I think at this point we have raised enough awareness around the issue with Quarkus and I hope the Quarkus team will be a bit more careful about how they document and position current CDI support. The majority of the other MicroProfile implementations are fine anyway.

I want to reinforce that there is absolutely no question of any hostility, latent or salient, on my part in any of this. If I didn't care much for success or failure of MicroProfile, I would have said and done absolutely nothing and let more people just stumble into this and get frustrated. I hope that is clear.

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.

On 2/11/2020 1:21 PM, Ken Finnigan wrote:

Reza,

Thanks for taking the time to respond.

As a brief recap to make sure I'm completely understanding. You would be in favor of MP 4.0 requiring that the Jakarta EE TCKs of the "base specs" are passed by implementations, and that the MP platform spec graphic is adjusted so that the "base specs" are in a separate layer? Or would enforcing Jakarta EE TCK execution mean that the graphic doesn't need adjusting?

Thanks

Ken

> 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/CAKeeVe6nOrahB1p52_SOCLagPC4neBbXWou13o1PqcugLyJVBg%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/CAE35TCMQz77UMf1%3Dcjyg7ks%2Bihj-zYd5NoDrQkKkM3zhU9B0BA%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/CAKeeVe7PxG6Db3UjygYRAt7V9Kn8OP1XX-uHpS%3DfUZKVF7VwpA%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/CA%2BfW9O6yPM0r663dOV5hZB3mLZgv%2BU0vVM9jcUx3Cy4Bhnbjjw%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/2981CDE4-2280-4266-8331-DE61509DF966%40gmail.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/5e41cd96.1c69fb81.17d8b.433c%40mx.google.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.

[Emily Jiang]

One more comment:

I have been trying to push for more formality about compliance. In MicroProfile, we should take a look at how to certify against Jarkata EE and adopt some the best practices. We should make the compliance formal (such as uploading test result etc or point at the test run result).

Emily

[John Clingan]

It is my understanding that the CDI TCK tests EL and JSF. If that is the case, then does that mean MP has to include EL and JSF? What are the dependencies that EL and JSF bring in? I think we have to be very careful how this is defined.

I think certifying against Jakarta EE is fine, but it needs to be discussed where that happens. Perhaps in the Jakarta community. Perhaps appserver vendors do product testing and bring issues back to MP. I know my opinion here is controversial, but I don't think all MicroProfile paths lead to Jakarta. It is *a* path.

[John Clingan]

Egad, it figures i post this and *then* read david's thread. let's move this point to that discussion.

[Ondro Mihályi]

I've expressed most of what I think is important to realize in the thread about partial specifications here: https://groups.google.com/d/msg/microprofile/_vML3EzLKIE/LYDc5UnnBAAJ

With that in mind, I believe that all the current MP resources and documentation suggest that all MP implementations should pass the MP TCKs and conform to the other JEE specs as closely as possible. Earlier, only Java EE certified servers had access to the TCK for JSON-P, JSON-B and JAX-RS so we couldn't require that MP implementations pass them. Now that the TCK is in Jakarta EE, it's possible but some more work needs to be done do separate the tests for those 3 specs from the single Jakarta EE TCk bundle. 

CDI TCK is a different story. It's been open since MP 1.0 and so can be used freely to test compatibility. But there are some problems too. First one is that we didn't verify that the CDI TCK fits well with MicroProfile and can be used easily to test compatibility of MP runtimes. Another issue is that we haven't clarified which parts of the CDI spec should MP implementations comply with. My interpretation is that impls that aren't JEE containers, should comply with CDI for Java SE and those which are Java EE or Jakarta EE containers should comply with CDI for Java EE. But since we decided to remove the EL API transitive dependency, it's not clear how impls should pass the CDI TCK. I believe that even if EL API isn't exposed by MP APIs, implementations should provide the required EL functionality to pass the CDI TCK. If we want to change that, we should fork the CDI TCK and remove the tests that require EL so that MP implementations can pass it.

So my understanding is that currently:

* all full MP implementations should pass TCKs for all MP specs

* CDI TCK for Java SE or Java EE (if they are also a JEE container)

* try to comply with the JAX-RS, JSON-P and JSON-B spec as much as possible

In the future, we should explore how the Jakarta EE TCK can be used to verify the compliance against those 3 specs. It will possibly need forking the Jakarta EE TCK to MicroProfile and extract only the necessary stuff. Or contribute to Jakarta EE to help separate the TCK suites for these specs so that MP can just reuse them. If we want to have other exceptions, e.g. that EL or CDI extensions are not needed to pass the TCK, we should definitely fork the existing TCKs and adjust them accordingly.

I don't have any hard opinion on this apart from that we should clearly specify how to verify that implementations are MP compatible, including the JEE specs. I'm not a fan of leaving things loose so that everybody can interpret them as they see fit.

Ondro

[Andy Guibert]

I agree with Ondro's stance on this.  Over in JEE land I've started an initiative to split out TCKs [1] so they can be more like the standalone CDI and BeanValidation TCKs, which can be independently published, consumed, and run with Arquillian.  I believe JSON-P will follow soon after, which then just leaves the JAX-RS TCK.

[1]: https://www.eclipse.org/lists/jakartaee-platform-dev/msg01455.html

[Dmitry Kornilov]

Does it make sense to join Jakarta EE working group and use Jakarta EE compliance process instead of creating a new process based on it?

-- Dmitry

[Emily Jiang]

My interpretation is that impls that aren't JEE containers, should comply with CDI for Java SE

I am not sure certifying CDI for Java SE is sufficient. Since MP has JAX-RS, JAX-RS integrates with CDI, which does not mean CDI SE though.

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/XY1a_9JqMtU/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/8418fc6d-2c59-434f-9a97-0a17daa7537f%40googlegroups.com.

--

Thanks
Emily

[Laird Nelson]

On Wednesday, February 12, 2020 at 2:54:00 PM UTC-8, Emily Jiang wrote:

My interpretation is that impls that aren't JEE containers, should comply with CDI for Java SE

I am not sure certifying CDI for Java SE is sufficient. Since MP has JAX-RS, JAX-RS integrates with CDI, which does not mean CDI SE though.

And so we come full circle to the same root of the kinds of issues that are described here (and probably all others with the "Architecture Board" label):

• https://github.com/eclipse/microprofile/issues/49
• https://github.com/eclipse/microprofile/issues/50
• …and so on

Surely for an effort like MicroProfile—however agile or innovative—that almost definitionally needs to impose restrictions and/or direction upon its subordinate, component specifications there needs to be an explicit umbrella specification that carefully delineates what those restrictions are.  Is there any effort to produce such an umbrella specification?

Best,

Laird

[Mark Little]

It depends what you expect from an "umbrella specification". At a minimum we do need an architecture board/group which has a clear mandate for imposing clarity and conformance against well understood goals for all of the constituent projects. Now that clarity/conformance may be as simple as "enterprise distributed objects using heterogeneous languages" (e.g., CORBA/OMG, and yes I do kinda abbreviate their mandate), or it could be much more detailed. I'll leave off stating my personal preference here because I think it'd be better to have a separate thread on the topic, perhaps kicked off by someone from the architecture team.

Mark.

--

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/c28574d0-8041-485e-8f94-bab67b74b7fb%40googlegroups.com.

[Ondro Mihályi]

I believe what Liard meant is that the MP umbrella specifications should define any modifications to the base JEE specs, e.g. to clarify whehther CDI SE is enough, how it integrates with JAX-RS, whether implementations should pass the TCK of EE specs and how, etc.

The current umbrella spec just states that all EE specs are equally MicroProfile specs as all other specs. And thus implementations should follow exactly what's in those EE specs. If we want something else, the MP umbrella spec should document it.

Ondro

[Mark Little]

OK definitely wasn't what I read into it, though I think that's kinda valid too :)

In terms of driving change/evolution into any "3rd party spec" (ok only Jakarta/Java EE at the moment, but who knows in the future?) I see two variants:

- a specification such as CDI which is used across the MP architecture should definitely have the architecture group involvement even if suggested changes are driven by a subset of the MP specs themselves.

- a specification which is used by one or more MP specifications does require coordination across those MP specs at the very least (e.g., wouldn't want one spec trying to push for a change which made it difficult for others, or at least not without some form of prior consultation). I'd like to see the architecture group involved in this coordination too but I could maybe see this as being optional. My preference would be mandatory though.

Mark.

--
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/abdea692-cd3e-43fd-b959-c7d8bc3da1b8%40googlegroups.com.

[Steve Millidge]

One solution is to abandon the concept of a platform specification or platform version of MicroProfile and just release a series of specifications. This also makes technical alignment with Jakarta EE easier as they would be free to consume any spec they choose on any cadence as envisaged on the other thread. 

This would also kill the idea that there is any portability between MicroProfile implementations at the same platform level, which is likely the reality as shown by the CDI discussions. This also means there is no need to list CDI, JAX-RS etc. as part of the MicroProfile platform, as they are not MP specs. This would remove the ambiguity between core specs and non-core specs with the additional benefit that this would open MP up to have other non CDI/JAX-RS  based frameworks adopt MP specifications. 

If the concept of a "platform" is retained then there should be a platform TCK covering all specs mandated as part of the platform. 

Steve 

[Mark Little]

Not discounting your suggestion but I think that should be a new thread/topic. With the current processes and rules governing the aims of MicroProfile, Ken's original question remains valid and we should try to come to some agreement (whether consensus based on through voting, I don't mind). This suggestion can happen in parallel.

Mark.

--
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/52f25a26-a2c6-4e23-8396-4e7804bb0286%40googlegroups.com.

[Ken Finnigan]

I've re-read the thread again and would like to summarize where I think we're at.

The current assumptions I make is that there is an MP "umbrella" platform for 4.0 (which is just the pom, no separate spec or tck), as there has been for previous releases, and that we are aligning with Jakarta EE 8 APIs.

The proposal for "MP Compatibility" that commences with MP 4.0 is for an implementation to claim "MP Compatibility" it must pass the TCKs of CDI, JAX-RS, JSON-P, and JSON-B.

Can someone help out by commenting as to whether the TCKs for JAX-RS, JSON-P, and JSON-B are independently executable for Jakarta EE 8? I'm pretty sure JAX-RS isn't but wasn't sure if the JSON TCKs were done or only happening as part of Jakarta EE 9+.

Ken

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

[Andy Guibert]

I have split out the JSONB TCKs so that they are independently executable. I am still debating with people on the JEE list trying to make this the official copy for EE9 (right now it’s just a fork). 

I expect JSONP will follow suit after I get B sorted out. 

- Andy

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/XY1a_9JqMtU/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/CAKeeVe4ykZchH667s1MGve7a_4-1t9fGAPo7xi%3D%2BvtEL0o_QZA%40mail.gmail.com.

[Ken Finnigan]

Andy

As that’s happening now, would those JSON TCKs be executable against Jakarta EE 8, or it requires 9?

Ken

Sent from my iPhone

On Feb 17, 2020, at 18:28, Andy Guibert <andy.g...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAHiR6Z8QBMev1EzMv92_7N_j2z%3DZWAMpfSCzFaOuq%3Dxyd%3D0iAA%40mail.gmail.com.

[Andy Guibert]

It would require EE 9, since I included all of the package rename changes in the tests too 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/773FB9FF-0C66-40AE-A29E-2FF8B8696230%40kenfinnigan.me.

[Emily Jiang]

Andy,

For MP 4.0, we need JSON TCKs be executable against Jakarta EE8. How much effort will need to be involved?

Emily

On Monday, February 17, 2020 at 9:09:05 PM UTC-5, Andy Guibert wrote:

It would require EE 9, since I included all of the package rename changes in the tests too 

On Mon, Feb 17, 2020 at 6:04 PM Ken Finnigan <k...@kenfinnigan.me> wrote:

Andy

As that’s happening now, would those JSON TCKs be executable against Jakarta EE 8, or it requires 9?

Ken

Sent from my iPhone

On Feb 17, 2020, at 18:28, Andy Guibert <andy....@gmail.com> wrote:



I have split out the JSONB TCKs so that they are independently executable. I am still debating with people on the JEE list trying to make this the official copy for EE9 (right now it’s just a fork). 

I expect JSONP will follow suit after I get B sorted out. 

- Andy

On Mon, Feb 17, 2020 at 12:47 PM Ken Finnigan <k...@kenfinnigan.me> wrote:

I've re-read the thread again and would like to summarize where I think we're at.

The current assumptions I make is that there is an MP "umbrella" platform for 4.0 (which is just the pom, no separate spec or tck), as there has been for previous releases, and that we are aligning with Jakarta EE 8 APIs.

The proposal for "MP Compatibility" that commences with MP 4.0 is for an implementation to claim "MP Compatibility" it must pass the TCKs of CDI, JAX-RS, JSON-P, and JSON-B.

Can someone help out by commenting as to whether the TCKs for JAX-RS, JSON-P, and JSON-B are independently executable for Jakarta EE 8? I'm pretty sure JAX-RS isn't but wasn't sure if the JSON TCKs were done or only happening as part of Jakarta EE 9+.

Ken

On Mon, Feb 17, 2020 at 10:30 AM Mark Little <markc...@gmail.com> wrote:

Not discounting your suggestion but I think that should be a new thread/topic. With the current processes and rules governing the aims of MicroProfile, Ken's original question remains valid and we should try to come to some agreement (whether consensus based on through voting, I don't mind). This suggestion can happen in parallel.

Mark.

On Mon, Feb 17, 2020 at 2:46 PM Steve Millidge <l33t...@gmail.com> wrote:

One solution is to abandon the concept of a platform specification or platform version of MicroProfile and just release a series of specifications. This also makes technical alignment with Jakarta EE easier as they would be free to consume any spec they choose on any cadence as envisaged on the other thread. 

This would also kill the idea that there is any portability between MicroProfile implementations at the same platform level, which is likely the reality as shown by the CDI discussions. This also means there is no need to list CDI, JAX-RS etc. as part of the MicroProfile platform, as they are not MP specs. This would remove the ambiguity between core specs and non-core specs with the additional benefit that this would open MP up to have other non CDI/JAX-RS  based frameworks adopt MP specifications. 

If the concept of a "platform" is retained then there should be a platform TCK covering all specs mandated as part of the platform. 

Steve 

--
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/52f25a26-a2c6-4e23-8396-4e7804bb0286%40googlegroups.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/CA%2BfW9O6_nszwsr66PYOhpnAgpWqHDYv2CYrw34KLEZGtC21nBQ%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/XY1a_9JqMtU/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/CAKeeVe4ykZchH667s1MGve7a_4-1t9fGAPo7xi%3D%2BvtEL0o_QZA%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/CAHiR6Z8QBMev1EzMv92_7N_j2z%3DZWAMpfSCzFaOuq%3Dxyd%3D0iAA%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/XY1a_9JqMtU/unsubscribe.

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

[Ken Finnigan]

Before we go asking groups for more work, let’s make sure we’re all agreed on what the situation is.

As it stands today, there is a TCK for CDI that can be run, and I’ll put aside content issues with that for now, but there are no executable TCKs for JAX-RS, JSON-B, and JSON-P with Jakarta EE 8.

Even if there could be an effort to make the JSON TCKs runnable for Jakarta EE 8, does it matter as JAX-RS would not have one?

Ken

Sent from my iPhone

On Feb 18, 2020, at 05:31, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:



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/4d714c49-8708-4197-b7ff-0bca896d24d9%40googlegroups.com.

[Kevin Sutter]

That's a good summary, Ken.  I think our hands are tied with Jakarta EE 8 (similar to Java EE 8) with standalone TCKs.  And, even with Jakarta EE 9, we still may not have a standalone TCK for JAX-RS.

-- Kevin

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

[Ken Finnigan]

Unfortunately I'm not sure where that leaves us for MP 4.0

We're not going to be able to enforce all base spec TCKs being run.

What do people think? Should MP 4.0 any base spec TCKs to be run to be "MP Compatible"? Or is it just defined as passing all MP spec TCKs of the platform?

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/4d714c49-8708-4197-b7ff-0bca896d24d9%40googlegroups.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/be75e3b6-5f93-42a9-89ec-b1dde12fc81b%40googlegroups.com.

[Emily Jiang]

`I think as a minimum, CDI and all MP TCKs need to be executed as they are freely available. As for JSON-B, JSON-P and JAX-RS, I think it is reasonable to make them optional so far. However, for the runtimes that are certifying against Jakarta EE, they may clearly announce their extra support statement over the minimum requirement.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4d714c49-8708-4197-b7ff-0bca896d24d9%40googlegroups.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/be75e3b6-5f93-42a9-89ec-b1dde12fc81b%40googlegroups.com.

[Ken Finnigan]

If we require the CDI TCK is passed, how does that align with what we've defined around removing EL from CDI.

I know that the main MP pom currently doesn't exclude EL, but I consider that a bug as we've defined at the Architectural level that we didn't want EL.

In addition, it's been raised on other threads that CDI defines behavior around WAR/EAR and @ConversationScoped, to name a few, that don't really align with the goals of MicroProfile around focusing on microservices. I think it's necessary to start a separate thread about what CDI behavior MP wants to mandate.

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/034197b4-8b20-4dca-bd64-3e90ccd71694%40googlegroups.com.

[Emily Jiang]

Ken,

EL was not removed from CDI. It was only removed from the API dependencies from other MP specs. In MicroProfile, we include the full set of CDI not partial, as mentioned in other thread.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/034197b4-8b20-4dca-bd64-3e90ccd71694%40googlegroups.com.

[Ken Finnigan]

Emily,

My understanding of the EL removal from CDI was that it didn't apply to the specifications but to the entirety of MicroProfile, which is why I consider it a bug.

We can certainly re-evaluate whether the EL removal makes sense, but it's very unusual to define rules for the specifications that don't apply to the platform as a whole

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/635cf5f0-c632-4776-baa7-f2e976158fde%40googlegroups.com.

[Emily Jiang]

I disagree the suggestion of removing EL from CDI. With the removal of EL from CDI, CDI injection will not work with .jsp. As a consequence, Jakarta EE apps with just CDI, JAX-RS, JSON-B, JSON-P usage may not even port to MicroProfile. We need to think about the pros/cons.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/635cf5f0-c632-4776-baa7-f2e976158fde%40googlegroups.com.

[Ken Finnigan]

Maybe it's best for you to make these points on the meaning of CDI for MicroProfile thread I started. As I mentioned there, we're not talking about precluding implementations from including parts of CDI that MicroProfile doesn't think applies. We're solely defining what MicroProfile does require. It doesn't preclude implementations going beyond.

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/783aa71d-7aa8-4f9e-8483-48f3d265e127%40googlegroups.com.

[Emily Jiang]

done.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/783aa71d-7aa8-4f9e-8483-48f3d265e127%40googlegroups.com.

[Dmitry Kornilov]

I think that all base spec TCKs must be passed. I also think that it's fine to test implementations separately. I mean that if you use Weld and that version of Weld passes CDI TCK - it's fine. If you use Jersey and that version of Jersey passes TCK - it's fine. If you use some other implementation, you need to make sure that it passes TCK first.

Why you want to stick with Jakarta EE 8 versions of base specs? Does it make more sense switching to Jakarta EE 9 versions with `jakarta.*` package as soon as possible?

-- Dmitry

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe5CLQvfqYwP80wnrgtdj%2BV1tUCLEhY47wU_9WJXL1Df1g%40mail.gmail.com.

[Ken Finnigan]

I'm not sure if that approach is practical. In another MP thread David mentioned that Jetty/Tomcat don't pass the Servlet TCK, so it's likely there could be various issues with any implementation.

With respect to Jakarta EE 9 APIs, it was decided to move to them in June was too risky a proposition. If you'd like to challenge that, then please open a separate thread to discuss it

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CALgpM5RyxHVkPKsm40J-jC%3DZFrB1v7tpc_nVq%2BF70hpVcaRJBg%40mail.gmail.com.

[Emily Jiang]

I think that all base spec TCKs must be passed. I also think that it's fine to test implementations separately. I mean that if you use Weld and that version of Weld passes CDI TCK - it's fine.

This is a first step. Even though Weld passes CDI TCK, we also need to ensure Weld is integrated into the specific runtime properly. I have personally integrated Weld in Liberty and found out getting the integration done properly was not a trivial task. Therefore,  it is important to run TCK against the runtime as well to ensure the microservice developers can use CDI as documented in CDI Spec with MicroProfile runtimes.

In another MP thread David mentioned that Jetty/Tomcat don't pass the Servlet TCK, so it's likely there could be various issues with any implementation.

Since Servlet is not part of the MP, this might be orthogonal for this conversation.

Thanks

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4d714c49-8708-4197-b7ff-0bca896d24d9%40googlegroups.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/be75e3b6-5f93-42a9-89ec-b1dde12fc81b%40googlegroups.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/CAKeeVe5CLQvfqYwP80wnrgtdj%2BV1tUCLEhY47wU_9WJXL1Df1g%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/CALgpM5RyxHVkPKsm40J-jC%3DZFrB1v7tpc_nVq%2BF70hpVcaRJBg%40mail.gmail.com.

[Antoine Sabot-Durand]

Regarding CDI TCK, I think today no MP implementation pass it.

There are 2 flavor of CDI today:

- CDI for Java SE that provides API to bootstrap and configure a CDI container from a Java SE application. The TCK have more than 50 tests for these API to ensure implementation are compliant.

- CDI for Jakarta EE (the original one) that support heavy integration with EJBs, lighter with EL. We have hundreds of tests in TCK for EJB integration.

CDI in MP isn't either of these official approaches. Since we didn't defined a CDI "profile" or a CDI features subset doe MicroProfile, we don't have an official TCK for CDI in MP.

so before talking about TCK, I think we should work on this MP CDI official supported features to have the same rules for everyone.

Antoine

Antoine Sabot-Durand

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/053a62a6-e958-4682-8ca0-11d7a4e982c2%40googlegroups.com.

[Emily Jiang]

Regarding CDI TCK, I think today no MP implementation pass it.

I am afraid I disagree with you on this. This is a bold statement. I hope this has not frightented end uers who are using CDI from MP releases. Let me list some facts:

All application servers that have done EE8 or Jakarta EE8 compliance have passed CDI EE TCKs  plus all other integration tests. You can view here for the list of application servers that has passed every single CDI EE tck including EJB integration. They are Open Liberty, GlassFish, Payara and Wildfly. Based on this, the application servers including Open Liberty (19.0.0.6 and onwards), Payara (5.193.1 and onwards) and Wildfly (18.0.0.Final and onwards) passed all CDI EE TCKs including EJB, EL, etc. Open Liberty and Payara have also passed all MicroProfile specs while Wildfly is trying to release the support for MicroProfile. Below are CDI TCKs for EE servers.

Stage Name: CDI TCK
Tests run: 1800, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4,840.407 sec - in TestSuite

Results :
Tests run: 1800, Failures: 0, Errors: 0, Skipped: 0

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.586 sec - in TestSuite

Results :
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0

Stage Name: jms/ee20/cditests/ejbweb
[javatest.batch] ********************************************************************************
[javatest.batch] Completed running 13 tests.
[javatest.batch] Number of Tests Passed      = 13
[javatest.batch] Number of Tests Failed      = 0
[javatest.batch] Number of Tests with Errors = 0
[javatest.batch] ********************************************************************************

Stage Name: jms/ee20/cditests/mdb
[javatest.batch] ********************************************************************************
[javatest.batch] Completed running 2 tests.
[javatest.batch] Number of Tests Passed      = 2
[javatest.batch] Number of Tests Failed      = 0
[javatest.batch] Number of Tests with Errors = 0
[javatest.batch] ********************************************************************************

Stage Name: jms/ee20/cditests/usecases
[javatest.batch] ********************************************************************************
[javatest.batch] Completed running 10 tests.
[javatest.batch] Number of Tests Passed      = 10
[javatest.batch] Number of Tests Failed      = 0
[javatest.batch] Number of Tests with Errors = 0
[javatest.batch] ********************************************************************************

As for the EL removal, no matter whether it is a defect or not, currently all released MP versions have full CDI support. In MP, there is no annoucement at all to state the CDI we are adopting is a partial CDI. In the first release, we announced to adopt CDI, JAX-RS and JSON-P from Java EE. Even though it is partial CDI in MP, all application servers that support the full CDI are more sufficient to claim the compliance of the CDI support in MP.

I think the above clarifies which application servers support CDI fully and passed the CDI TCK compliance. In order to make all other application servers or runtimes that want to support MP to pass CDI TCKs easier, we should focus on the effort to define the CDI Lite issue instead of agruing who are complying. I think we should create a google doc and list all CDI features and then we can work together to pick some useful features from CDI for better alignment with other non EE but MP runtimes.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/053a62a6-e958-4682-8ca0-11d7a4e982c2%40googlegroups.com.

[Antoine Sabot-Durand]

Ok, my first sentence should have been : MP impl DON'T have to pass the CDI TCK because they DON'T have to support EJB.

Honestly I think that having EJB support in MP impls is not great because it makes it look like Jakarta EE. 

Should you have read my full message, you'd see that I'm just saying the same than you : Before going for compliance we should define a subset of CDI that fit for MP.

That can be CDI Lite or AtInject under steroid,

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/0c80f657-5f10-4195-b60f-15440fb062d9%40googlegroups.com.

[Emily Jiang]

Ok, my first sentence should have been : MP impl DON'T have to pass the CDI TCK because they DON'T have to support EJB.

Honestly I think that having EJB support in MP impls is not great because it makes it look like Jakarta EE. 

OK, agreed!

That can be CDI Lite or AtInject under steroid,

I don't think AtInject is enough as we do need to support some built-in scopes such as RequestScoped, etc as well as interceptor support etc. Therefore, I think we should collaborate to define the scope for CDI Lite.

Thanks

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0c80f657-5f10-4195-b60f-15440fb062d9%40googlegroups.com.

[Ken Finnigan]

Just for some clarification, I believe Antoine’s original statement to be closer to the truth. The reason, as you stated Emily, is that only application servers can pass the CDI TCK!

If I recall, MP was focused on leaner runtimes that didn’t include everything in Java EE, and as such it wasn’t envisioned that application servers would necessarily offer MicroProfile. We’re in a different place now, in terms of application servers offering it, but that doesn’t mean they’re the poster children for MP implementations passing the CDI TCK

I agree we need the discussion around what a CDI for MP means, which is why I created the thread on it. Please add thoughts and ideas there. I’d prefer not to jump to a document right now, better to have open discussion first.

Getting back to MP Compatibility for 4.0, given all the statements I see our only option is to clearly define it as not including passing of base spec TCK passing, for reasons of them being bundled or requiring functionality not defined in MP, and that it purely relates to passing all TCKs of MP specs defined in the platform

What does everyone think?

Sent from my iPhone

On Feb 28, 2020, at 14:47, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:



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/0742b0e8-b776-4b6e-a954-21bfb699e322%40googlegroups.com.

[Alasdair Nottingham]

I don’t agree with this. I think most people expect CDI to broadly work so are surprised by a statement that it isn’t required. It sounds to me as if we think that a subset (to be defined) is required, as such I think we should be working to define that and how to validate an implementation supports it. I think making a statement that it isn’t required essentially denies that whole process. I think we shouldn’t go from a point of doubt to a point of wrong certainty to go to a different point of certainty that is right. In my mind better to focus on moving towards the desired outcome rather than a left fork to another wrong state.

> On Feb 28, 2020, at 10:15 AM, Ken Finnigan <k...@kenfinnigan.me> wrote:
>
>

[Roberto Cortez]

Hi,

I believe that we need to define what CDI for MP means.

Not only that, but state which versions should do what. So I have a few of questions:

- What is the community consensus about MP compliance for the current version (3.3) and previous versions of MP?

- Do you require to pass the CDI TCK as is? 

- If yes, does this mean you need to implement things like EL, EJB support, RequestScoped, etc, like mentioned in previous emails?

- If no, what do you need to pass exactly?

- What about TCK’s for JAX-RS, JSON-B and JSON-P?

With the move to Jakarta in 4.0 and all TCK’s being open, it clarifies a few things, but we still need to answer if the CDI TCK has to fully pass, including things that were never discussed in MP.

Cheers,

Roberto

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7967A7BD-6719-44B2-A92C-851420E565FA%40kenfinnigan.me.

[Scott Stark]

All that should be required for MP compatibility are the MP TCKs. 

[Ken Finnigan]

Roberto, 

Please open a new thread for non MP 4.0 Compatibility items.

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7F890E26-C8DA-4ABB-98A6-50B2BDF9BC58%40yahoo.com.

[Ken Finnigan]

Alasdair, it's not even related to discussions of whether MP wants a subset of CDI or not.

As it stands today, with Jakarta EE 8 for MP 4.0, there would be no way for a non-Jakarta application server to pass the CDI TCK, as it requires EJB, JSF, etc to be present to pass.

It would be great to say we require CDI TCK passing to be MP Compatible, but then it restricts that moniker to only implementations that include Jakarta EE full. It wouldn't even be possible to include a slimmed application server for MicroProfile and pass the CDI TCK.

Sure, I want us to get to a place where we can say passing base spec TCKs is required, but that isn't a short term goal and we need to answer the question of what MP 4.0 Compatibility means, otherwise we're still in the current muddied waters of everyone holding different perspectives and recollections.

What would you suggest as an alternative?

On Fri, Feb 28, 2020 at 4:48 PM Alasdair Nottingham <alasdair....@gmail.com> wrote:

I don’t agree with this. I think most people expect CDI to broadly work so are surprised by a statement that it isn’t required. It sounds to me as if we think that a subset (to be defined) is required, as such I think we should be working to define that and how to validate an implementation supports it. I think making a statement that it isn’t required essentially denies that whole process. I think we shouldn’t go from a point of doubt to a point of wrong certainty to go to a different point of certainty that is right. In my mind better to focus on moving towards the desired outcome rather than a left fork to another wrong state.

> On Feb 28, 2020, at 10:15 AM, Ken Finnigan <k...@kenfinnigan.me> wrote:
>
> 

--
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/CC998732-C2BC-4AC8-A179-035A4E06BEF2%40gmail.com.

[Mark Little]

Agreed. We absolutely do not want to restrict implementations to only Java EE/Jakarta EE implementations. That was never our starting point and shouldn't be where we are today, 4 years later.

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4S1xYqmMVGk1wc8wPRV25jdcw3F86c0zMpZ6AHK02RLQ%40mail.gmail.com.

[Andy Guibert]

CDI integrates with a ton of other specs, but I don't think anybody is implying that MP requires all of these integration points to work when the integrating spec isn't present.

JEE specs have very clear language about cross-spec interactions, for example JAX-RS spec states that IF JSON-B is present, then JSON-B should be used for POJO<-->JSON [un]marshalling.

I believe what people are asking for is that _core_ CDI should work the same way in JEE as it does in MP. After all, the reason why Quarkus initially got flak for this is because core CDI stuff was not working. Any reasonable user would not be surprised if things like CDI+EL CDI+EJB interactions do not work given that EL nor EJB are not included in MP or Quarkus platforms.

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/XY1a_9JqMtU/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/E1FDA4CB-C526-4734-8218-464866552E5A%40gmail.com.

[Scott Stark]

That is too big a requirement as core itself assumes a base vm runtime
where reflection is a non-trivial burden. It only makes sense for MP
to be talking about compatibility at the CDI level when there is an
appropriate minimal cloud native CDI version.

[Andy Guibert]

Regardless of the size of the burden reflection brings, I think it is what CDI users expect. CDI itself is heavily dependent on reflection. Saying "CDI without reflection" sounds like an oxymoron IMO.

The successful adoption of MP is largely due to the fact that it built upon some of the most common JEE technologies (CDI, JAX-RS, JSONB) so JEE developers familiar with these APIs could hop into "MP runtimes" and be be productive quickly by using familiar APIs and concepts. If MP tries to mutate or redefine the specs we are building upon, MP starts to lose the ease of migration that developers had going from JEE to MP.

Are you suggesting that we should create another "profile" in the CDI spec (alongside the existing CDI-SE and CDI-EE profiles) that would accommodate cloud native runtimes like Quarkus? I think this would be a reasonable thing to do, because we'd be creating something new with a universal definition, as opposed to trying to redefine the CDI-EE 2.0 spec.

--
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/XY1a_9JqMtU/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/CAHyjRvDzPX6Gs_mqr82W%3D_US0kxot%2BeCB%3D_6mhUGYtpGKOor7w%40mail.gmail.com.

[Werner Keil]

Well if they're not even compatible with CDI, then MP products are just not "compatible" and should not pretend to be.

There is no way to redefine the CDI 2.0 or Java EE 8 spec now, at most a future CDI spec under Jakarta EE may do what was mentioned by creating another "profile" in the CDI spec from Jakarta EE 9 or 10 onward. Strictly speaking Jakarta EE 9 should not do that kind of thing because a new profile would effectively be a "new feature" but maybe something like that could be accomplished in Jakarta EE 9?

I know because we took the CDI TCK as inspiration for JSR 363/385, that this should work also on the TCK level. JSR 385 supports 7 different profiles ;-)

Werner

Am Freitag, 28. Februar 2020 20:58:16 UTC+1 schrieb Andy Guibert:

Regardless of the size of the burden reflection brings, I think it is what CDI users expect. CDI itself is heavily dependent on reflection. Saying "CDI without reflection" sounds like an oxymoron IMO.

The successful adoption of MP is largely due to the fact that it built upon some of the most common JEE technologies (CDI, JAX-RS, JSONB) so JEE developers familiar with these APIs could hop into "MP runtimes" and be be productive quickly by using familiar APIs and concepts. If MP tries to mutate or redefine the specs we are building upon, MP starts to lose the ease of migration that developers had going from JEE to MP.

Are you suggesting that we should create another "profile" in the CDI spec (alongside the existing CDI-SE and CDI-EE profiles) that would accommodate cloud native runtimes like Quarkus? I think this would be a reasonable thing to do, because we'd be creating something new with a universal definition, as opposed to trying to redefine the CDI-EE 2.0 spec.

On Fri, Feb 28, 2020 at 1:22 PM Scott Stark <sst...@redhat.com> wrote:

That is too big a requirement as core itself assumes a base vm runtime
where reflection is a non-trivial burden. It only makes sense for MP
to be talking about compatibility at the CDI level when there is an
appropriate minimal cloud native CDI version.

On Fri, Feb 28, 2020 at 12:39 PM Andy Guibert <andy....@gmail.com> wrote:
>
> CDI integrates with a ton of other specs, but I don't think anybody is implying that MP requires all of these integration points to work when the integrating spec isn't present.
>
> JEE specs have very clear language about cross-spec interactions, for example JAX-RS spec states that IF JSON-B is present, then JSON-B should be used for POJO<-->JSON [un]marshalling.
>
> I believe what people are asking for is that _core_ CDI should work the same way in JEE as it does in MP. After all, the reason why Quarkus initially got flak for this is because core CDI stuff was not working. Any reasonable user would not be surprised if things like CDI+EL CDI+EJB interactions do not work given that EL nor EJB are not included in MP or Quarkus platforms.
>

--
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/XY1a_9JqMtU/unsubscribe.

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

[Scott Stark]

Yes, we need an MP targeted CDI profile.

On Fri, Feb 28, 2020 at 1:58 PM Andy Guibert <andy.g...@gmail.com> wrote:
...

[Emijiang6]

Not another profile. I have been mentioning the CDI lite idea, which targets for MP adoption: 

https://github.com/eclipse-ee4j/cdi/issues/425

Emily 

> wrote:
>>
>> That is too big a requirement as core itself assumes a base vm runtime
>> where reflection is a non-trivial burden. It only makes sense for MP
>> to be talking about compatibility at the CDI level when there is an
>> appropriate minimal cloud native CDI version.

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

[Andy Guibert]

Thanks for pointing that out Emily. I think me/you/Scott all of the same thing in mind, just different names.

@Werner agreed, if a new CDI profile/spec/whatever was defined, it would need to be in a future version of CDI/JakartaEE (probably CDI 3.0 / JEE 10). Note that MP could potentially consume a CDI 3.0 before JEE 10 is released, if timelines are a concern.

Do we all agree that this is something that should be worked out within the CDI community? As opposed to MP externally redefining what CDI means.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b235b853-5202-4632-8b58-7e4627b85a6d%40Emilys-iPhone.

[Ken Finnigan]

It feels like we’re getting off track again

What MP might want for an “optimal” CDI is a separate topic.

The problem we will have for MP 4.0 is that there is no way to run and pass the CDI TCK “as is” without features that are not present in MP. That is the reality we’re dealing with right now, which is what we need to solve.

Sent from my iPhone

On Feb 28, 2020, at 16:10, Andy Guibert <andy.g...@gmail.com> wrote:



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/CAHiR6Z-7e31YbF2ROGk2Dwvz%2BavV3SRs2rmbmVtXWU3dec17fQ%40mail.gmail.com.

[Ondro Mihályi]

I had a look at the CDI TCK docs and the statement "there is no way to run and pass the CDI TCK as is” is technically true as a whole. But there's a simple way how we can relax CDI TCK requirements so that any MP implementation can run the CDI TCK and meet those requirements to pass the TCK.  A way to go is to require only the core set of CDI TCK tests to pass, without EE or SE specific tests.

There are many test groups in the CDI TCK: core, integration, ee-full, ee-web, se. There are only 2 ways to officially pass the TCK. Either in EE profile (includes core, integration, and one of ee-full or ee-web) or in SE profile (includes core and se). Some MP runtimes are also EE runtimes, so they can pass via the EE profile. But the other MP runtimes are not SE runtimes, as they also run apps in a container and don't allow bootstrapping a new CDI container, so they can't pass via the SE profile. 

However, for any MP implementation, it's possible to run and pass the core (standalone) profile, although the CDI TCK docs state this isn't sufficient to pass the CDI TCK as a whole: https://docs.jboss.org/cdi/tck/reference/latest/en-US/html/executing.html#_running_the_tests_in_standalone_mode

A simple way to define CDI compatibility withing MP is therefore to require that all MP implementations pass the CDI TCK at least in the core/standalone.

On Saturday, February 29, 2020 at 4:03:12 AM UTC+1, Ken Finnigan wrote:

It feels like we’re getting off track again

What MP might want for an “optimal” CDI is a separate topic.

The problem we will have for MP 4.0 is that there is no way to run and pass the CDI TCK “as is” without features that are not present in MP. That is the reality we’re dealing with right now, which is what we need to solve.

Sent from my iPhone

On Feb 28, 2020, at 16:10, Andy Guibert <andy....@gmail.com> wrote:



Thanks for pointing that out Emily. I think me/you/Scott all of the same thing in mind, just different names.

@Werner agreed, if a new CDI profile/spec/whatever was defined, it would need to be in a future version of CDI/JakartaEE (probably CDI 3.0 / JEE 10). Note that MP could potentially consume a CDI 3.0 before JEE 10 is released, if timelines are a concern.

Do we all agree that this is something that should be worked out within the CDI community? As opposed to MP externally redefining what CDI means.

On Fri, Feb 28, 2020 at 2:54 PM 'Emijiang6' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Not another profile. I have been mentioning the CDI lite idea, which targets for MP adoption: 

https://github.com/eclipse-ee4j/cdi/issues/425

Emily 

On Feb 28, 2020 at 8:45 pm, <Scott Stark> wrote:

Yes, we need an MP targeted CDI profile.

On Fri, Feb 28, 2020 at 1:58 PM Andy Guibert <andy....@gmail.com> wrote:
...
> Are you suggesting that we should create another "profile" in the CDI spec (alongside the existing CDI-SE and CDI-EE profiles) that would accommodate cloud native runtimes like Quarkus? I think this would be a reasonable thing to do, because we'd be creating something new with a universal definition, as opposed to trying to redefine the CDI-EE 2.0 spec.
>
> On Fri, Feb 28, 2020 at 1:22 PM Scott Stark <sst...@redhat.com> wrote:
>>
>> That is too big a requirement as core itself assumes a base vm runtime
>> where reflection is a non-trivial burden. It only makes sense for MP
>> to be talking about compatibility at the CDI level when there is an
>> appropriate minimal cloud native CDI version.

--  
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/XY1a_9JqMtU/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/CAHyjRvBamBq69gyOXMopfZPAA9zxPML2KMCq11OsgvmYBOzQ4g%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/XY1a_9JqMtU/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/b235b853-5202-4632-8b58-7e4627b85a6d%40Emilys-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 microp...@googlegroups.com.

[Ken Finnigan]

Wouldn't this raise the risk of non-CDI compatibility because it's not the "TCK" as the community understands it?

How would doing this solve the confusion we have today?

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/0d65bbeb-e697-403f-ba80-08887b467a10%40googlegroups.com.

[Werner Keil]

As Andy mentioned and I also asked in the Spec Committee today this is out of discussion before a Jakarta EE 10 CDI version.

I don't know, if the plans for MicroProfile 3.x are to stay in the 3.x range for some time and only go 4.x after embracing Jakarta EE 10, otherwise this may be a topic for MP 5 or 6 instead ;-)

Werner

Am Dienstag, 3. März 2020 20:57:02 UTC+1 schrieb Ken Finnigan:

Wouldn't this raise the risk of non-CDI compatibility because it's not the "TCK" as the community understands it?

How would doing this solve the confusion we have today?

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/0d65bbeb-e697-403f-ba80-08887b467a10%40googlegroups.com.

[Ken Finnigan]

Yes, what is being discussed here is solely around what's possible with Jakarta EE 8 for MP 4.0.

Longer-term we need to define what "MP Compatibility" means and ideally have Jakarta projects support that view such that we can run the TCKs we want, but right now the focus is MP 4.0 and Jakarta EE 8

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/a962fda4-e5f5-47e7-b701-0f8cdca58d2d%40googlegroups.com.

[Ondro Mihályi]

My proposal suggested how MP can specify CDI compatibility now, not after there's a new CDI version. I agree that it's better if CDI specifies a new profile that matches the needs of MP. But meanwhile my proposal provides a way how such profile can be specified by MP to provide an option for non-EE implementations how to pass the CDI TCK.

In other words, MP implementations would be required to pass the MP spec TCKs plus the CDI TCK in the "core" profile, plus JSON-B TCK. We wouldn't require passing the JAX-RS and JSON-P TCKs as they can't be run separately from the Jakarta EE TCK at the moment. We can require that MP implementations use JAX-RS and JSON-P implementations that pass the Jakarta EE TCK but that's up to discussion.

I don't see how this is more confusing than the current state when it's not clear whether passing the TCKs for Java EE specs is required or not. Do we have any other option other than specify that it's up to each MP implementation to decide how they implement Java EE specs as long as they pass all MP spec TCKs? I clearly don't prefer the latter because it leaves a huge portion of MP uncovered.

Ondro

st 4. 3. 2020 o 20:14 Ken Finnigan <k...@kenfinnigan.me> napísal(a):

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/CAKeeVe5_L76%2BK_V8v-SvFbkbkPsW18DbX0JEuWb11hq18SrKXQ%40mail.gmail.com.

[Ladislav Thon]

Hi,

for an unrelated reason, I went into the CDI spec a few days ago, looking for normative text that says that the request context (@RequestScoped) is tied to an HTTP request (which we all know it is). I only found that in the EE section. (It is actually specified in terms of servlet, web services and remote EJBs, none of which is present in MicroProfile.) If the TCK is structured similarly (I don't know, didn't look), then the "core profile" of the TCK isn't all that useful in my opinion, as it's likely missing quite a few important bits.

LT

čt 5. 3. 2020 v 10:30 odesílatel Ondro Mihályi <ondrej....@gmail.com> napsal:

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CACZTZYX6J1jRv%3D1pkw6zzQS3CsGiP_u-9qAUOVioG8P92PROvA%40mail.gmail.com.

[Matej Novotny]

Just to give a comparison - "core" tests are about 1200 tests, whereas running incontainer executes 1800 tests. SE tests are pretty small and basically only deal with testing the bootstrap API which is SE-specific part.

Now, TCKs do not state what exactly is tested in "core" and what is outside of it, the only thing you know is that those EE tests (actually they are integration group of tests) need to run in an EE container. The reason for that can be either the functionality they test, or the way the test was written. I.e. there could be tests that are integration, but could be re-written to "core".

It is hard to say if "core" would be sufficient for two reasons. Firstly it is what I stated earlier; it may not test everything that is considered core feature in CDI, some tests might be in the integration group. And secondly, which is IMO the major issue is that MP doesn't define what it exactly needs from CDI spec therefore what should be tested. If we are talking about passing partial TCKs, then we should know what parts are we interested in. This is something that a subspec of CDI could define (like those discussion around lighter profile suggest) and then you could select part of TCKs to run and certify.

As a side note, those "core" tests will still contain certain CDI features that are not really used/needed in cloud microservice use cases. Or things that are not AOT-friendly.

Also, any further changes into CDI TCK do not mandate that tests are written in one category or another - so you may end up with changes being added to "core" which is something we don't want to test for MP. Or vise versa, there can be features we want but tests can be added into integration group. It would be best effort.

[Emily Jiang]

I think it is pretty clear that we need to define a clear scope in CDI with the corresponding TCKs. Let's use this issue (CDI Lite) to note down the requirements and work towards an agreed scope. I have noted down some functionalities I think the CDI Lite should include. Please share your thoughts there.

Thanks

Emily

[Ken Finnigan]

Emily, as mentioned previously in this thread, it's better for the MP community to contribute to a discussion around what is appropriate amongst us before we create a huge issue thread with discussion that should happen here. Please comment on https://groups.google.com/forum/#!topic/microprofile/Rg4MPG4E6J4 with your perspectives.

Matej, thanks for the information. My interpretation is that we have no guarantees about what might be part of the CDI TCK "core", without expending huge effort evaluating every test, and therefore it's not a viable option for MP implementations to pass it.

Ondro, you mentioned that JSON-B TCK could be passed? Is that a separate TCK for Jakarta EE 8? I thought all TCKs were packaged into the CTS?

Ken

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/2c9a458f-d1f4-417a-a7cc-6bce8b9eec7f%40googlegroups.com.

[Ondro Mihályi]

Yes, John, JSON-B has a separate TCK in the JSON-B repo: https://github.com/eclipse-ee4j/jsonb-api/tree/master/tck. It's mentioned in the repo README and Yasson repository contains an example how to run it with the Yasson impl.

pi 6. 3. 2020 o 15:31 Ken Finnigan <k...@kenfinnigan.me> napísal(a):

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/CAKeeVe6qpeVHxafLojpf%2Bey7evr01LYEWmbsVhX0PbnLVbOUmQ%40mail.gmail.com.

[Andy Guibert]

Hi, the JSON-B TCKs Ondro found it is still a work in progress. I have been leading an effort to allow specs to "externalize" their TCKs from the big platform monorepo. It is not the official TCK source for JakartaEE 8, but I am working on making it the single official source for Jakarta EE 9 and future.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CACZTZYUKkX6vP%3DK-NxPUicOy8Q1%3DmbAmByMaAcyExFJeQEw7Uw%40mail.gmail.com.

[Ondro Mihályi]

Thanks Andy for correcting me, I didn't realize that the TCK was added only to the Eclipse JSON-B repo after JSON-B 1.0 was released. It's true that the original repo under the javaee Github organization doesn't contain a TCK. 

pi 6. 3. 2020 o 23:24 Andy Guibert <andy.g...@gmail.com> napísal(a):

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAHiR6Z-GhYjb6t7oHW1yu1xS3qOZyFJcrAUVSBt_vFwY1HaSKw%40mail.gmail.com.

[Ken Finnigan]

Is there agreement that it's not possible for an implementation to pass any of the Jakarta EE 8 API TCKs for MP 4.0?

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CACZTZYV4PeH9C1swEJdiRpEj8YX%2BomH%3D_o41PoOLzZHp-u2EUw%40mail.gmail.com.

[Emily Jiang]

I think I have pointed out in the earlier conversation. I would not say it is not impossible. For Jakarta EE8 compliance servers such as Open Liberty, Payara, Wildfly, they have passed all TCKs.

For other runtimes, it is a different story as they need to certify against CDI TCKs, JAX-RS, JSON-P, JSON-B with a lot of effort since JAX-RS, JSON-P and JSON-B TCKs are in the big overall Jakarta EE TCK bucket.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe6GwT0txLktRyUKki_FMHB9Qf29bE2A3TUWRv-J8aGzVg%40mail.gmail.com.

--

Thanks
Emily

[Ken Finnigan]

I'd like to summarize where we're at:

• Only Jakarta EE 8 compatible application servers are able to pass the CDI TCK "as is", as a MicroProfile implementation is not required to contain EJB, JSF, etc that are part of the CDI TCK verification
• JAX-RS, JSON-B, and JSON-P TCKs for Jakarta EE 8 are only available in a combined Jakarta EE platform TCK. Once again meaning that only a Jakarta EE 8 compatible application server would be able to pass them

Given the above, there is no way for us to define "MP 4.0 Compatibility" to include passing the TCKs of the underlying Jakarta EE 8 APIs.

Yes, it's possible for Jakarta EE 8 application servers to pass those TCKs, but we don't want to have distinctions between different MP implementations as to whether they do, or do not, pass certain TCKs, and thus indirectly imply that some implementations are inferior to others simply because they aren't an application server. That sends the wrong message for MP. Every implementation should be treated equally.

Without additional discussion over the next few days, I will propose a vote on MP 4.0 Compatibility on it's meaning being that an implementation has passed all MicroProfile platform specification TCKs only.

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A-pTtvqNsk%3D9D1ny5_N7gPAH%3D6oeRhV1Y6XrPRxHmyz0g%40mail.gmail.com.

[Werner Keil]

I guess that'll also stay that way for Jakarta EE 9, since no significant changes like a new profile is planned before Jakarta EE 10.

As all of the platform specs are part of the Web Profile: https://jakarta.ee/specifications/webprofile/8/webprofile-spec-8.html it is sufficient to pass that.

Werner

Am Montag, 9. März 2020 13:46:02 UTC+1 schrieb Ken Finnigan:

I'd like to summarize where we're at:

• Only Jakarta EE 8 compatible application servers are able to pass the CDI TCK "as is", as a MicroProfile implementation is not required to contain EJB, JSF, etc that are part of the CDI TCK verification
• JAX-RS, JSON-B, and JSON-P TCKs for Jakarta EE 8 are only available in a combined Jakarta EE platform TCK. Once again meaning that only a Jakarta EE 8 compatible application server would be able to pass them

Given the above, there is no way for us to define "MP 4.0 Compatibility" to include passing the TCKs of the underlying Jakarta EE 8 APIs.

Yes, it's possible for Jakarta EE 8 application servers to pass those TCKs, but we don't want to have distinctions between different MP implementations as to whether they do, or do not, pass certain TCKs, and thus indirectly imply that some implementations are inferior to others simply because they aren't an application server. That sends the wrong message for MP. Every implementation should be treated equally.

Without additional discussion over the next few days, I will propose a vote on MP 4.0 Compatibility on it's meaning being that an implementation has passed all MicroProfile platform specification TCKs only.

Ken

On Sat, Mar 7, 2020 at 5:05 AM 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

I think I have pointed out in the earlier conversation. I would not say it is not impossible. For Jakarta EE8 compliance servers such as Open Liberty, Payara, Wildfly, they have passed all TCKs.

For other runtimes, it is a different story as they need to certify against CDI TCKs, JAX-RS, JSON-P, JSON-B with a lot of effort since JAX-RS, JSON-P and JSON-B TCKs are in the big overall Jakarta EE TCK bucket.

Emily

On Sat, Mar 7, 2020 at 1:03 AM Ken Finnigan <k...@kenfinnigan.me> wrote:

Is there agreement that it's not possible for an implementation to pass any of the Jakarta EE 8 API TCKs for MP 4.0?

On Fri, Mar 6, 2020 at 5:37 PM Ondro Mihályi <ondrej...@gmail.com> wrote:

Thanks Andy for correcting me, I didn't realize that the TCK was added only to the Eclipse JSON-B repo after JSON-B 1.0 was released. It's true that the original repo under the javaee Github organization doesn't contain a TCK. 

pi 6. 3. 2020 o 23:24 Andy Guibert <andy....@gmail.com> napísal(a):

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/2c9a458f-d1f4-417a-a7cc-6bce8b9eec7f%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/XY1a_9JqMtU/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/CAKeeVe6qpeVHxafLojpf%2Bey7evr01LYEWmbsVhX0PbnLVbOUmQ%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/XY1a_9JqMtU/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/CACZTZYUKkX6vP%3DK-NxPUicOy8Q1%3DmbAmByMaAcyExFJeQEw7Uw%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/XY1a_9JqMtU/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/CAHiR6Z-GhYjb6t7oHW1yu1xS3qOZyFJcrAUVSBt_vFwY1HaSKw%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/CACZTZYV4PeH9C1swEJdiRpEj8YX%2BomH%3D_o41PoOLzZHp-u2EUw%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/XY1a_9JqMtU/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/CAKeeVe6GwT0txLktRyUKki_FMHB9Qf29bE2A3TUWRv-J8aGzVg%40mail.gmail.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-pTtvqNsk%3D9D1ny5_N7gPAH%3D6oeRhV1Y6XrPRxHmyz0g%40mail.gmail.com.