Platform specification discussion

92 views
Skip to first unread message

Scott Stark

unread,
Sep 15, 2020, 3:51:50 PM9/15/20
to MicroProfile
On today's call there was a question about whether we had a formal MP platform specification and the associated APIs, TCK, and specification document. We certainly need to decide this for 4.0, but my feedback is that we certainly do.

- Our APIs are the platform pom/bom.
- The spec document needs to spell out the various specifications included in the release, and integration requirements, which today happens to be none.
- The TCK is a collection of standalone TCKs, but this needs to be spelled in in a user guide along with a resolution to the requirements regarding Jakarta EE TCKs.


John Clingan

unread,
Sep 18, 2020, 3:55:48 PM9/18/20
to MicroProfile
On Tuesday, September 15, 2020 at 12:51:50 PM UTC-7 Scott Stark wrote:
On today's call there was a question about whether we had a formal MP platform specification and the associated APIs, TCK, and specification document. We certainly need to decide this for 4.0, but my feedback is that we certainly do.

- Our APIs are the platform pom/bom.

Or an aggregation of javadocs.
 
- The spec document needs to spell out the various specifications included in the release, and integration requirements, which today happens to be none.

There "kinda" is a platform spec (example). I say kinda because it is exactly what you intend it to be - an aggregation of component specs. However, there are no top-down requirements on the component specs, although we may want to add some (minimum JDK for example). This is easy to fix,  although we will want to identify any other shortcomings.
 
- The TCK is a collection of standalone TCKs, but this needs to be spelled in in a user guide along with a resolution to the requirements regarding Jakarta EE TCKs.

Hopefully, this user guide is short.
 
A potential problem is the compatible implementation requirement. Who (one or more) will have a compatible implementation by the time we are ready to release specs? Strawman - mid-late November (I am working on schedule).

Scott Stark

unread,
Sep 18, 2020, 4:01:46 PM9/18/20
to microp...@googlegroups.com
I would expect the TCK today to simply be a listing of the standalone TCKs along with the requirements regarding whether certification requires passing on the standalone MP TCKs. I would not be arguing for extension to subsets of the Jakarta EE TCKs, but if that is something we end up requiring, how that needs to be setup would have to be described as well.

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/FGgHJgyYYpg/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/68cea793-08f9-49d6-a12b-fc02062585ffn%40googlegroups.com.

John Clingan

unread,
Sep 18, 2020, 5:20:47 PM9/18/20
to MicroProfile
On Friday, September 18, 2020 at 1:01:46 PM UTC-7 Scott Stark wrote:
I would expect the TCK today to simply be a listing of the standalone TCKs along with the requirements regarding whether certification requires passing on the standalone MP TCKs. I would not be arguing for extension to subsets of the Jakarta EE TCKs, but if that is something we end up requiring, how that needs to be setup would have to be described as well.

Agree 100%

Emily Jiang

unread,
Sep 21, 2020, 5:16:47 AM9/21/20
to MicroProfile
I feel unease with the TCK exclusion towards Jakarta EE TCKs. Since MP umbrella spec releases includes the 5 Jakarta EE specs as well as 8 MP-created specs. It does not make sense if we don't require implementations to pass Jakarta EE TCKs but just MP TCKs. I think we could have 2 levels of compliance for the runtimes that have difficulties to pass Jakarta EE TCKs: full compliance or MP Leval compliance.

Thanks
Emily

Roberto Cortez

unread,
Sep 21, 2020, 5:45:21 AM9/21/20
to microp...@googlegroups.com
Hi Emily,

I understand your view.

On the other hand, as far as I know, there is no way to run the Jakarta TCKs separate (except for CDI). So how can we force MP only implementations to pass the Jakarta TCKs also?

Cheers,
Roberto

You received this message because you are subscribed to the Google Groups "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/b6542f89-1c14-49f9-b873-4dd01043fc0bn%40googlegroups.com.

Edwin Derks

unread,
Sep 21, 2020, 5:54:24 AM9/21/20
to microp...@googlegroups.com
Hi Emily, Roberto,

If CDI TCK can already be run standalone, will it be worthwhile to consider achieving this also for JSON-B, JSON-P and JAX-RS? Especially if it is already desired by the Jakarta EE community, we should be able to make a start in order to set this up properly for MP where Jakarta EE can continue ons this base? And IIRC, Andrew Guibert already started a thread and experimentation on this last year with JSON-B?

Edwin

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/57F454E5-8F8D-410D-B8D7-CCE6F0A0E8DB%40yahoo.com.

Roberto Cortez

unread,
Sep 21, 2020, 6:10:07 AM9/21/20
to microp...@googlegroups.com
The CDI TCK has other issues (for instance, testing EJB integrations that are not supported on a MP only implementation).

Separating the remaining TCK’s was discussed before. As far as I remember there was a considerable amount of effort involved, so I’m not sure if these will be ready in time for a MP 4.0 release. Maybe someone has more information about this?

My concern and point here is that it will be highly unfair to force MP only implementations to pass the Jakarta TCK’s if there is no way to do it. We need to fix two issues: the technical issue to be able to run the TCKs and the requirements issue so the TCKs test what they are supposed to test.

Cheers,
Roberto

Emily Jiang

unread,
Sep 21, 2020, 7:14:14 AM9/21/20
to MicroProfile
I know the Jakarta TCKs are in one repo. As far as I know, you can run JAX-RS TCKs alone (https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/sun/ts/tests).

As for CDI TCKs, I think running through the TCKs bucket and hand-pick the tests for MP. It is good to have some golden pass tcks to justify the quality. I'll raise an issue on MP repo to log our discussion. I created this issue to track the conversation.

Alternatively, we can set up two levels of compliance as I mentioned in my previous email: full and MP level only.

Thanks
Emily


To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/105CAEBB-0EE9-41E3-B0AE-DC9A9ACBD124%40yahoo.com.


--
Thanks
Emily

Roberto Cortez

unread,
Sep 21, 2020, 7:53:09 AM9/21/20
to microp...@googlegroups.com
And how about JSON-B and JSON-P? Also, I believe that for CDI, it was not as easy as to hand pick some tests, since some tests were mixing multiple checks. If someone is able to split the TCK into a MP compatible TCK, let us know. 

BTW, we had a huge thread discussing this a few months ago:

There was no consensus and no clear definition of compatibility.

I’m fine if implementations are able to run everything, but again, some may not be able to do it and we can’t force them, especially considering that we don’t even have instructions on how to run these for MP only implementations. Can you work on set of instructions? 

Ken Finnigan

unread,
Sep 21, 2020, 9:05:04 AM9/21/20
to MicroProfile
First, I believe it's important that this discussion around TCKs and MP 4.0 happen on this thread, and not mixed between this thread and a GH issue. This thread is about defining the platform specification, which includes what TCKs are required, making it appropriate to discuss here.

As Roberto mentioned, there was a lengthy discussion about this that started in February and went on for a couple of months with no resolution [1].

After the effort it's taken to reach this point, are we willing to delay MP 4.0 even further to have another lengthy discussion related to Jakarta TCKs?

Some points from [1] that I believe are still relevant:
  • JAX-RS TCK for Jakarta EE 8 is not separately runnable.
    • Emily, you mentioned that it is. Can you provide documentation showing that it's possible to run the JAX-RS TCK for Jakarta EE 8 on its own?
  • JSON-P and JSON-B TCKs are not independently runnable with Jakarta EE 8. There was effort to do so for Jakarta EE 9, but that's irrelevant for MP 4.0
    • Has this situation changed? Andy, can you answer?
  • While the CDI TCK is separately runnable, there are two groups of possible tests that can be run. One of them, "core", contains about 1200 tests. Matej commented in [1] that it's not possible to identify whether all those 1200 tests actually apply completely to non Jakarta EE functionality without manually checking every one of those tests and verifying what it does.

With respect to the two levels of compatibility idea, one for Jakarta based implementations and another for pure MicroProfile implementations. I personally don't like the idea of creating two levels within MP, it opens the door to many questions and concerns around what the compatibility differences mean leading to the "this one is better" outcome. That approach isn't what the MP community was founded on.

Thanks
Ken


To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/C0A59198-AB90-45F8-ACC2-58C3F1460C8E%40yahoo.com.

John Clingan

unread,
Sep 21, 2020, 12:31:41 PM9/21/20
to MicroProfile
This is an important discussion, but I don't think we have time to focus on Jakarta-related spec compliance for MP 4.0. I think the results of this discussion should be targeted at MP 5.0. Let's get MP 4.0 released first, although this discussion can happen in parallel.

Ondro Mihályi

unread,
Sep 22, 2020, 6:17:13 AM9/22/20
to MicroProfile
Hi,

AFAIK, the EE 8 TCKs can't be run separately except CDI. For EE 9, all Jakarta EE TCKs are going to be released separately, although they still remain in the same Github repository. Here are staged versions of individual TCKs: https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-900/ (Some of them were already promoted and moved here, including JSON-B, JSON-P and JAX-RS: https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/promoted/). The sources for individual TCK user guides are here: https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/user_guides

This is probably not relevant for MP 4.0 as Ken and John said though, will be probably relevant for MP 5.0.

I suggest we have a very lightweight umbrella spec, which is a collection of individual MP and EE specs, and specifies some common requirements like Java version. Later we may need to specify more common behavior, like interactions between individual specs or integration points if needed. But I'd keep it as lightweight as possible in any case.

Regarding the TCK, I think the best way is to encourage testing on the best effort basis. Implementations should test as many related TCKs as possible. For MP specs it means individual TCKs, for EE specs it means running the Jakarta CTS or individual CDI TCK if possible. If not possible, the implementation should at least document which EE TCKs it passes (or almost passes with the number of failed tests) and why it couldn't run some or all EE TCKs. It would allow any implementation to claim compatibility and still make it transparent for the community.

Ondro

Dátum: pondelok 21. septembra 2020, čas: 18:31:41 UTC+2, odosielateľ: John Clingan

Emily Jiang

unread,
Sep 22, 2020, 10:32:39 AM9/22/20
to MicroProfile
I am not sure why this conversation slows down the effort of MP 4.0. As for as I know, we need to decide what compliance means for MP 4.0 unless MP 4.0 has the freedom to skip what the compliance means. Otherwise, we just need to make decision based on the conversation.

As for how to run JAX-RS, JSON-B and JSON-P,  you will need to download the user guide from https://download.eclipse.org/jakartaee/platform/8/ and then run JAX-RS, JSON-B and JSON-P. It is not as easy as MP TCKs but these TCKs can be executed.

The tcks for JSON-B has been moved out of the full tck bucket and reside here.

For quite a few Jakarta EE compliance runtimes, the passing EE tcks is a given already. This is just other new runtimes, which require some effort for the set up.

As mentioned earlier, it might be a good idea to have 2 level of compliances: full and MP-level to accommode both camps. I think this is close to what Ondro suggested as well. Thoughts?

Thanks
Emily

Mark Little

unread,
Sep 22, 2020, 11:59:11 AM9/22/20
to 'Emily Jiang' via MicroProfile
A bit late to this but +1

You received this message because you are subscribed to the Google Groups "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/CAHyjRvA67FDw-EppQrG3eVNk4CVbQ4H8ow6cBVcAkediq9WZ_A%40mail.gmail.com.

Mark Little

unread,
Sep 22, 2020, 12:15:01 PM9/22/20
to 'Emily Jiang' via MicroProfile
We should strive for all MP TCKs to be easily executed by anyone “at a click”. I believe that’s possible for the MP specific TCKs but not (yet) for Jakarta EE related specs. Yes, if you’re so inclined you can “click here, download there, run this, scurry across there and run that” but generally that’s not a good thing. There have been several discussions in the Jakarta Steering Committee and elsewhere around improving things with the TCKs so I’m confident that will improve over time.

So for now I would be hesitant to require any MP implementations to have to pass the individual Jakarta EE TCKs. I know that could appear to confuse the issue on what exactly MP compliance/compatibility means but we can always evolve that over time, i.e., for 4.0 we stick with the MP TCKs alone and work with the Jakarta EE community to improve those other TCKs.

Mark.


Kevin Sutter

unread,
Sep 22, 2020, 5:10:38 PM9/22/20
to MicroProfile
I'm confused by some of this discussion... All of the TCKs in this download directory structure for Jakarta EE are available as standalone TCKs:

For Jakarta EE 8...

Each of these zip files contains the testcases and instructions on how to execute the tests.  Running these tests should not be difficult for any of the app servers or frameworks that support MicroProfile.  Passing these tests may be another story...  But, the execution of these standalone tests should not be an issue.

Now, whether passing these Jakarta EE 8 tests should be a requirement for MP 4.0, that's a good question.  In the past, the answer as to whether we could require passing of Java EE TCKs for MP was "no" due to the fact that some implementations didn't have the license for running the TCKs from Oracle.  Now that the TCKs are readily available for Jakarta EE, does that requirement change?

-- Kevin
Roberto

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

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

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

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/FGgHJgyYYpg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.


--
Thanks
Emily


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

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

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

Mark Little

unread,
Sep 23, 2020, 1:47:05 AM9/23/20
to microp...@googlegroups.com
Hi Kevin.

Let's table this for after 4.0 is out the door. As you you know better than most, we've been putting a lot of effort into the WG definition and delayed the MP 4.0 release for quite a while as a result. I believe that should be our collective priority at this stage.

Mark.


Sent from my iPhone

On 22 Sep 2020, at 22:10, Kevin Sutter <kwsu...@gmail.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/7d0d9279-cbed-4fc8-8eb3-54a686af132co%40googlegroups.com.

Amelia Eiras

unread,
Sep 23, 2020, 12:23:30 PM9/23/20
to MicroProfile Community
+1 to Mark's recommendation! 




Roberto

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

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

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

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/FGgHJgyYYpg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.


--
Thanks
Emily


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

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

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

--
You received this message because you are subscribed to the Google Groups "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/7d0d9279-cbed-4fc8-8eb3-54a686af132co%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "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/85B648F5-C90F-46F6-8891-570C7098636F%40gmail.com.

Scott Stark

unread,
Sep 23, 2020, 1:40:08 PM9/23/20
to microp...@googlegroups.com
The fundamental problem with some of the EE tests is their dependency on specs outside of MP. Both CDI and JAX-RS have this issue. CDI has a mode to run only Java SE based tests, but as far as I can see. JAX-RS requires a servlet container capable of deploying wars. I personally don't see the need to go beyond the MP TCKs until the CN4J alliance initiative has defined and produced EE TCKs that fit into the MP profile.

Roberto

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

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

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

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/FGgHJgyYYpg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.


--
Thanks
Emily


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

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

--
You received this message because you are subscribed to the Google Groups "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/CAKeeVe6xdMzvgMZUpYypVZy96hibrhrHTY58eW4tKKQT5te6gQ%40mail.gmail.com.

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/FGgHJgyYYpg/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/7d0d9279-cbed-4fc8-8eb3-54a686af132co%40googlegroups.com.

Kevin Sutter

unread,
Sep 23, 2020, 7:38:42 PM9/23/20
to MicroProfile
I tend to agree that we should defer this discussion post MP 4.0.  I just wanted to clarify that we do have separate standalone TCK buckets for all of the Jakarta EE specs which MP references.

Also, the jax-rs tests have two "modes".  As Scott pointed out, there is portion of the tests which require a Servlet container.  But, there is a large portion of the tests that run in Java SE mode.  We would probably need to define which tests are required under what circumstances (similar to CDI).

-- Kevin
Roberto

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

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

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

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/FGgHJgyYYpg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.


--
Thanks
Emily


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

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

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

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/FGgHJgyYYpg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

m.reza.rahman

unread,
Sep 26, 2020, 12:38:11 AM9/26/20
to microp...@googlegroups.com
I hope this is not too much of a tangent but it is an idea that has been floating around in my head for a while so just want to get it out there.

How about defining a Jakarta EE Microservices Profile with just what MicroProfile needs? MicroProfile could then simply reference that. I think this could go a long way towards answering the questions of alignment between these two technology sets. Anything MicroProfile platform compatible would by definition also be Jakarta EE compatible.

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

Scott Stark

unread,
Sep 26, 2020, 12:45:34 PM9/26/20
to MicroProfile
Yes, I think that is a fundamental notion that needs to be added to EE 10. Along with that, the referenced specs need to be refactored to layer their dependencies so as to allow for finer grained platforms definitions. I have raised that on other threads and I believe in the EE10 directions document, although it may be more opaquely stated as MP integration.

Emily Jiang

unread,
Sep 26, 2020, 6:16:50 PM9/26/20
to MicroProfile
How about just creating two levels of compliance: Full MP compliance and MP-level only compliance, which is similar to full profile and web profile (https://jakarta.ee/compatibility/).

In this way, end users have a full view on what compliance statements each runtime certify against.

Thanks
Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f8057952-c896-454e-b4c1-0bd3f3f83e7en%40googlegroups.com.


--
Thanks
Emily

Werner Keil

unread,
Sep 27, 2020, 3:55:25 PM9/27/20
to MicroProfile
That sounds rather strange. At least the standalone TCKs of every mandatory MP ingredient
should be passed, otherwise why have them as a mandatory requirement in the first place?

That's also what Kevin mentioned here earlier.
It seems fine, if they do not have to pass the Full or Web Profile TCKs of Jakarta EE, but these (and should MP 4 require more those as well) should be passed, otherwise a compatibility claim is not really worth anything.

Werner

Rudy De Busscher

unread,
Sep 28, 2020, 2:04:41 AM9/28/20
to MicroProfile
That sounds a reasonable proposal. At least, the users have a clear view of what they can expect and whatnot.

Rudy

Rudy De Busscher

unread,
Sep 28, 2020, 2:06:26 AM9/28/20
to MicroProfile
>should be passed, otherwise a compatibility claim is not really worth anything.

True, but if an implementation can't guarantee anting more, then it is up to the users to decide if they go along with it or not.

Werner Keil

unread,
Sep 28, 2020, 3:19:23 PM9/28/20
to MicroProfile
Then if it's a "work in progress" I wouldn't make or trust any compatibility claim, till everything is properly passed.
Jakarta EE has a much bigger chunk to work on, if it works there, then it should be much easier with just those 5 specs to consider.

Otherwise any compatibliity claim is about as meaningful as the emission tests by major auto makers ;-)

Werner

Reply all
Reply to author
Forward
0 new messages