[ARCH] Discussion on "MP Compatibility" vote thread

[Ken Finnigan]

Steve/Rudy,

I'd be curious to know, if you're willing to share, what the reasoning is for voting against the "MP Compatibility" definition under vote in [1]?

From the discussion in [2], is there a different type of voting outcome you were anticipating?

Thanks

Ken

[1] - https://groups.google.com/forum/#!topic/microprofile/0q8qR9JI4nE

[2] - https://groups.google.com/forum/#!topic/microprofile/XY1a_9JqMtU

[Steve Millidge]

MicroProfile fundamentally has to decide whether it is a bunch of apis or a platform. Current state is that developer applications are not portable across implementations that claim compatibility because some choose to not fully implement the features in the base specs. That needs fixing, the statement we are voting on won't fix it.

[Ken Finnigan]

Thanks for responding Steve.

I agree that we need to resolve the situation with respect to underlying Jakarta EE specifications in MP, but with Jakarta EE 8, as mentioned in the thread, there is no way to have TCKs of those base specifications be run on anything except full Jakarta EE Application Servers.

Do you have an alternative proposal?

--
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/3c639d75-ee0a-4ad9-98e2-631a506c8a75%40googlegroups.com.

[Steve Millidge]

One of?

1) Remove the Jakarta EE specs from MP and just deliver apis. I haven't tried but I guess it would be possible to get "MicroProfile Compatibility" under this definition without including one or more of the Jakarta EE specs.

2) Write a MicroProfile platform test suite that exercises the Jakarta EE base specs to some agreed level

3) Require passing the Jakarta EE TCKs

4) Fork the Jakarta EE TCKs and remove the bits people agree are not required.

5) Specify which Jakarta EE TCK tests you are allowed to fail

Steve

[Ken Finnigan]

On Fri, Apr 3, 2020 at 10:52 AM Steve Millidge <l33t...@gmail.com> wrote:

One of?

1) Remove the Jakarta EE specs from MP and just deliver apis. I haven't tried but I guess it would be possible to get "MicroProfile Compatibility" under this definition without including one or more of the Jakarta EE specs.

That's an idea I've been thinking about, namely removing the notion of a Platform from MP, and be more like RFCs.

It does have implications though around marketing, etc.

I didn't think it would reach agreement prior to MP 4.0, so haven't raised it yet. Though I did mention it briefly in another thread.

 

2) Write a MicroProfile platform test suite that exercises the Jakarta EE base specs to some agreed level

I'd raised the idea of an MP Platform spec and TCK I think about 6 months ago and it was shot down.

 

3) Require passing the Jakarta EE TCKs

As per the thread, this isn't possible as it stands today. CDI is the only Jakarta EE 8 TCK that is independently runnable, however the TCK includes numerous tests that require EJB, JSF, etc

 

4) Fork the Jakarta EE TCKs and remove the bits people agree are not required.

Maybe. But that's a more appropriate task for Jakarta, or am I wrong? An alternative to this is properly defining what parts of Jakarta EE specs MP cares about, such as the CDI Lite discussion, but once again that won't reach a conclusion for MP 4.0

 

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

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7048ae35-ab29-46af-94b0-ae63eb713468%40googlegroups.com.

[Ondro Mihályi]

If MP claims that 4 JEE specs are part of it then they should be covered. If we want that passing only MP TCKs is enough then we should change the marketing and remove claims that JEE specs are part of MP as Steve suggests in 1. It would mean that MP 1.0 is an empty proclamation but that's now history.

If we want JEE specs to be part of MP, there are ways how to cover them. We can create a TCK to cover those JEE specs. For CDI, it would be easy to run at least a reasonable subset of the CDI TCK, which is more than nothing. For other specs we can say that we have no tests to cover the functionality but we'll be adding them as JakartaEE specs create syandalone TCKs like CDI has. JSON-B already started eork on this, other may follow. Or we can pull out existing tests from Jakarta CTS but that soubds too much work.

I just want that MP is what people expect. We shouldn't d say that MP includes something and at the same time say it's OK if it's not entirely there.

Ondro

[Ken Finnigan]

Why don't you and Steve start a thread about removing the notion of a platform for MP 4.0 then? Or dropping the Jakarta specs and just having the MP ones?

I'm trying to reach a point where we have a definition of what MP Compatibility means, as opposed to the current situation where some think one thing and others think another.

As was discussed on the thread, which you participated in, CDI TCK contains over 1200 tests that are not clearly segregated into what depends on EJB, JSF or other Jakarta EE specs that are not part of MicroProfile. Would anyone from Payara take on the task of defining which tests are appropriate and which aren't? As for the other TCKs, yes they are starting to be separated out, but only for Jakarta EE 9 and beyond. It does nothing to solve the issue for MP 4.0 on Jakarta EE 8.

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/fd12078b-74d8-430a-abab-032896c8a137%40googlegroups.com.

[Ondro Mihályi]

Hi Ken,

I wrote it's an acceptable option for me but not that I endorse it. We've been telling people those JEE specs are part of MP and I'd like it to stay that way. That's why I suggested we should try to cover by TCKs as much as possible.

What you say about CDI TCK isn't true. It's very easy to separate non-EE tests. CDI TCK directly supports it and it's documented. If the TCK is executed without any additional profile it won't use anything outside of CDI. The TCK docs say it's not enough to be certified as CDI compatible but it can be enough to certify as MP compatible. Better than nothing.

But then, what's the point in starting a new thread when I see no interest whatsoever to come to a unanimous solution? I proposed a solution and it was put down by false arguments. If we solve everything just by voting, the majority surely wins but we all lose in the end. 

Ondro

Dňa so 4. 4. 2020, 0:43 Ken Finnigan <k...@kenfinnigan.me> napísal(a):

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/lQF-9i_S7rg/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/CAKeeVe58gkr%3DakwgEw-_vFkdwFV3k5ObNrO9Eho7qmztACECYw%40mail.gmail.com.

[Ken Finnigan]

On Fri, Apr 3, 2020 at 7:07 PM Ondro Mihályi <ondrej....@gmail.com> wrote:

Hi Ken,

I wrote it's an acceptable option for me but not that I endorse it. We've been telling people those JEE specs are part of MP and I'd like it to stay that way. That's why I suggested we should try to cover by TCKs as much as possible.

What you say about CDI TCK isn't true. It's very easy to separate non-EE tests. CDI TCK directly supports it and it's documented. If the TCK is executed without any additional profile it won't use anything outside of CDI. The TCK docs say it's not enough to be certified as CDI compatible but it can be enough to certify as MP compatible. Better than nothing.

Yes it is. Matej from the Weld project explicitly stated that the delineations you mention from the TCK are not accurate and don't guarantee the separation between the different tests.

 

But then, what's the point in starting a new thread when I see no interest whatsoever to come to a unanimous solution? I proposed a solution and it was put down by false arguments. If we solve everything just by voting, the majority surely wins but we all lose in the end. 

What false arguments?

In the thread that leads to the vote, I tried very hard to reach a unanimous solution based on the constraints placed on us from what is available with Jakarta EE 8.

 

Ondro

Dňa so 4. 4. 2020, 0:43 Ken Finnigan <k...@kenfinnigan.me> napísal(a):

Why don't you and Steve start a thread about removing the notion of a platform for MP 4.0 then? Or dropping the Jakarta specs and just having the MP ones?

I'm trying to reach a point where we have a definition of what MP Compatibility means, as opposed to the current situation where some think one thing and others think another.

As was discussed on the thread, which you participated in, CDI TCK contains over 1200 tests that are not clearly segregated into what depends on EJB, JSF or other Jakarta EE specs that are not part of MicroProfile. Would anyone from Payara take on the task of defining which tests are appropriate and which aren't? As for the other TCKs, yes they are starting to be separated out, but only for Jakarta EE 9 and beyond. It does nothing to solve the issue for MP 4.0 on Jakarta EE 8.

Ken

On Fri, Apr 3, 2020 at 6:32 PM Ondro Mihályi <ondrej....@gmail.com> wrote:

If MP claims that 4 JEE specs are part of it then they should be covered. If we want that passing only MP TCKs is enough then we should change the marketing and remove claims that JEE specs are part of MP as Steve suggests in 1. It would mean that MP 1.0 is an empty proclamation but that's now history.

If we want JEE specs to be part of MP, there are ways how to cover them. We can create a TCK to cover those JEE specs. For CDI, it would be easy to run at least a reasonable subset of the CDI TCK, which is more than nothing. For other specs we can say that we have no tests to cover the functionality but we'll be adding them as JakartaEE specs create syandalone TCKs like CDI has. JSON-B already started eork on this, other may follow. Or we can pull out existing tests from Jakarta CTS but that soubds too much work.

I just want that MP is what people expect. We shouldn't d say that MP includes something and at the same time say it's OK if it's not entirely there.

Ondro

--
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/fd12078b-74d8-430a-abab-032896c8a137%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/lQF-9i_S7rg/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/CAKeeVe58gkr%3DakwgEw-_vFkdwFV3k5ObNrO9Eho7qmztACECYw%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 microprofile...@googlegroups.com.

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

[Ondro Mihályi]

Yes, in general, all delignations in the CDI TCK are not guaranteed. But Matej meant the profiles like "integration", "jaxrs" and others. The core set of tests executed without a profile is also executed for the CDI SE TCK which means they don't rely on anything from EE. I explained that too. But nobody wants to listen and I'm tired of explaining. 

Dňa so 4. 4. 2020, 1:14 Ken Finnigan <k...@kenfinnigan.me> napísal(a):

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

[Rudy De Busscher]

When you define compatible as only following the MP Specs, you have no compatible product at all.

Since runtimes can do whatever they like for CDI, JAX-RS and JSON* which means an application which can be deployed on one runtime fails to run on another.  This is just formalizing the current situation we have already today and community is already complaining about it.

[Emily Jiang]

 I share the same view as Steve, Ondro and Rudy!

It is incorrect to claim fully complying with MicroProfile while not able to passing 4 Java/Jarkart EE TCKs (CDI, JAX-RS, JSON-B and JSON-P), which are included by MicroProfile umbrella release. This will pass the wrong message to end users as they would assume all runtimes complying with MicroProfile platform tests and expect the spec behaviours defined in each of the included specificiations.

To move forward, I have the following suggestion:

We establish two level of compliances: full platform compliance, MicroProfile spec only compliance, which is similar to Jakarta Web Profile and Full Profile compliance.

In this case, the runtimes passing the MicroProfile spec only compliance can put them into that category and pass the right message to end users. They can also document their support statement for the 4 Jakarta specs. In some runtime, they might say they consume Weld, Yasson, RestEasy, etc. I think the most important thing is that the runtimes need to convene the accurate message to the end users.

In terms of making the TCKs (JAX-RS, JSON-B, JSON-P) available to be executed standalone, MicroProfile community should work closely with Jakarta community to separate JAX-RS, JSON-P out as Andy Guilbert mentioned previously that he was working on separating JSON-B Tcks. For CDI TCKs, I think we should work towards defining the scope of CDI lite and put the relevant TCKs to that category. Hopefully in Jakarta EE10, all runtimes should be able run any of the relevant Jakarta EE TCKs.

Emily

[Ondro Mihályi]

I like Emily's proposal.

Although I have to note that an MP-only profile is a bit vague becuase some support for the extra JEE specs is needed to pass the MP TCKs. But we can live with that if we clearly explain what this MP-only profile means and implementations clearly indicate which profile they support without confusing users. 

Ondro

Dňa po 6. 4. 2020, 0:38 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> napísal(a):

--

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/lQF-9i_S7rg/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/e5f42281-d4ba-4fe0-b87c-87c926a10e47%40googlegroups.com.

[Ken Finnigan]

Ondro, Have you tried running Payara Micro 5.201 with Weld 3.1.4.Final TCK runner? I did so this morning and there were a large number of errors.

Rudy, Yes it might be considered formalizing the current situation. But shouldn't that be done to remove any confusion, which there is already, about what compatibility actually means? Then we can move towards improving the meaning of compatibility over time.

Emily, you raised the same idea in the original discussion on compatibility. Your statement about it being incorrect to claim compliance with MP without passing the Jakarta EE TCKs is in itself incorrect, as we have no formal definition of what compatibility means, which is why we're having the vote. There are plenty of expectations about what it could, or should, mean, but nothing was defined.

As discussed in the original thread, creating two levels of compatibility will segregate the implementations and result in the non Jakarta EE application servers being deemed "second class". Such a situation would not be good for MicroProfile as it deems the work of non Jakarta EE specifications as lesser.

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.

[Alasdair Nottingham]

The proposal seems ambiguous to me:

MicroProfile compatibility is defined as a runtime passing all MicroProfile specification TCKs in the platform release.

I would consider CDI, JAX-RS, JSON-P and JSON-B to be MicroProfile specifications, but I suspect you would consider it otherwise. I would take this position purely because if we exclude them then Spring is MicroProfile 1.0 compatible.

Alasdair

> --
> 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/CAKeeVe7i3OND7XZMEEGUuWyd_3rU2GyJnkceBq-8W_VZtDMTgA%40mail.gmail.com.

[David Lloyd]

On Mon, Apr 6, 2020 at 9:08 AM Alasdair Nottingham
<alasdair....@gmail.com> wrote:
>
> The proposal seems ambiguous to me:
>
> MicroProfile compatibility is defined as a runtime passing all MicroProfile specification TCKs in the platform release.
>
> I would consider CDI, JAX-RS, JSON-P and JSON-B to be MicroProfile specifications, but I suspect you would consider it otherwise. I would take this position purely because if we exclude them then Spring is MicroProfile 1.0 compatible.

I'm curious why you would consider those to be MicroProfile
specifications? They're referenced by MicroProfile, sure, but so are
Java SE and even other (non-Java) specifications (HTTP for example),
and nobody (?) would consider those to be MicroProfile specifications,
right?

My intuition (FWIW) is that if the specification has the
"MicroProfile" prefix in its name, it's a MicroProfile specification;
otherwise it belongs to some other spec body.

--
- DML

[Ken Finnigan]

Certainly I didn't read "MicroProfile specifications" as being CDI, JAX-RS, etc, as they're not defined by MicroProfile

--
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/CANghgrRAJR7-hP%2B5bsyeSO3eAUvJ%3DKiqfq75-%2BKAJoz8AHTgng%40mail.gmail.com.

[Ondro Mihályi]

Hi Ken, I'll have to check whether Payara Micro passes the CDI TCK or not. But even if it doesn't, it's only a bug and not intentional. Payara is ready to fix it if it's the case.

This only highlights the gap in MP TCK. If MP doesn't clarify how to certify the functionality of CDI, JAX-RS and JSON-* specs, there will be confusion. But I'm against dropping the requirement to certify them and aloow free form implementation. If MP doesn't cover those JEE specs it can still cover them gradually in the future because all the JEE TCKs are now opensource.

If we simply state that it's enough to pass only TCKs of MP specs because it's currently not possible to run the JEE TCKs it's analogous to saying we'll fix the bug by removing the buggy feature. 

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

[Ken Finnigan]

I've never said what we defined as "MP Compatible" for 4.0 would exist in perpetuity, but that this is the definition for using Jakarta EE 8 as a base.

When MP moves to use Jakarta EE 9, 10, 11, etc as a base, then those would be appropriate times to redefine what compatibility means. But in the interim we work towards reaching the goal of having runnable base spec TCKs from Jakarta that aligns with MicroProfiles usage/needs.

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/d7b1e4fe-1085-4bf1-a037-59fed22137e2%40googlegroups.com.

[Emily Jiang]

Certainly I didn't read "MicroProfile specifications" as being CDI, JAX-RS, etc, as they're not defined by MicroProfile

The fact is that they are packaged in MicroProfile releases. How can an runtime claim the compliance for MicroProfile 1.0? Are you suggesting anyone whether or not they support the included  CDI, JAX-RS, and JSON-B, they are free to claim the compliance as they are not defined by MP?

Emily

On Monday, April 6, 2020 at 3:20:25 PM UTC+1, Ken Finnigan wrote:

Certainly I didn't read "MicroProfile specifications" as being CDI, JAX-RS, etc, as they're not defined by MicroProfile

On Mon, Apr 6, 2020 at 10:12 AM David Lloyd <david...@redhat.com> wrote:

On Mon, Apr 6, 2020 at 9:08 AM Alasdair Nottingham
<alasdair....@gmail.com> wrote:
>
> The proposal seems ambiguous to me:
>
>     MicroProfile compatibility is defined as a runtime passing all MicroProfile specification TCKs in the platform release.
>
> I would consider CDI, JAX-RS, JSON-P and JSON-B to be MicroProfile specifications, but I suspect you would consider it otherwise. I would take this position purely because if we exclude them then Spring is MicroProfile 1.0 compatible.

I'm curious why you would consider those to be MicroProfile
specifications?  They're referenced by MicroProfile, sure, but so are
Java SE and even other (non-Java) specifications (HTTP for example),
and nobody (?) would consider those to be MicroProfile specifications,
right?

My intuition (FWIW) is that if the specification has the
"MicroProfile" prefix in its name, it's a MicroProfile specification;
otherwise it belongs to some other spec body.

--
- DML

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

[David Lloyd]

On Mon, Apr 6, 2020 at 9:53 AM 'Emily Jiang' via Eclipse MicroProfile
<microp...@googlegroups.com> wrote:
>> Certainly I didn't read "MicroProfile specifications" as being CDI, JAX-RS, etc, as they're not defined by MicroProfile
>

> The fact is that they are packaged in MicroProfile releases. How can an runtime claim the compliance for MicroProfile 1.0? Are you suggesting anyone whether or not they support the included CDI, JAX-RS, and JSON-B, they are free to claim the compliance as they are not defined by MP?

I looked around the release artifacts for MicroProfile and I didn't
find these specifications packaged anywhere. Can you please show me
where these specifications are packaged with the MP release? Or do
you mean "packaged" in some other metaphorical way (and if so could
you explain)?

--
- DML

[Emily Jiang]

The content for MicroProfile 1.0 (CDI 1.2, JAX-RS 2.0, JSON-P 1.0) can be found from Mark Little's blog.

The content of MicroProfile 3.3 can be found here, which has CDI 2.0,  JAX-RS 2.1, JSON-B 1.0 and JSON-P 1.1.

Emily

[Ken Finnigan]

I think the issue is one of perception.

Yes MP has defined those specifications as a "base", but we never defined what compatibility in relation to that base actually meant. So we're in a situation where one group perceives one outcome and another group perceives a different one.

This is the entire point of the vote, aligning our perceptions on what is actually feasible for "MP Compatibility".

If the vote indicates we're unable to reach consensus on what it means, maybe we need to seriously reconsider the notion of MicroProfile needing a platform at all?

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/4565819d-756a-4a96-9f01-5c8aef7d988a%40googlegroups.com.

[Kevin Sutter]

I just voted Against the proposal.  Not so much that I don't agree with the premise of the vote.  But, rather because I was very surprised that this formal Vote was taking place.  Of course, I knew that this email thread was started.  But, I have not been able to keep up with all of the various emails.  I was quite surprised by calling a Vote when this has not been discussed on the Hangout (which I do make a point to attend and participate).  Thus, I'm voting Against the proposal.

-- Kevin

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

[David Lloyd]

OK I see, so we don't really have the same understanding of what
"package" and "content" mean then. To me, to "package a
specification" means to include the actual specification materials.
"Content" means something that is physically included. I think these
definitions are pretty widely held and understood, so to avoid
confusion perhaps we should stop using those words in this context and
instead use words like "referenced" or "referred to". The spec uses
*specific* language (note the shared provenance of the words
"specific" and "specification") in those pages; language like "must
provide", which is unambiguous and doesn't imply transitive compliance
in any way.

A critical part of *defining* specifications is using normative
language specifically for this reason: so that everyone uses the same
language when talking about the same thing. A critical part of
*reading* specifications is understanding the language, and not
drawing meaning or making assumptions beyond what the specification
actually *says*. This is something that I think we (the greater MP
community) have to practice and improve.

On Mon, Apr 6, 2020 at 10:29 AM 'Emily Jiang' via Eclipse MicroProfile

<microp...@googlegroups.com> wrote:
>
> The content for MicroProfile 1.0 (CDI 1.2, JAX-RS 2.0, JSON-P 1.0) can be found from Mark Little's blog.
>
> The content of MicroProfile 3.3 can be found here, which has CDI 2.0, JAX-RS 2.1, JSON-B 1.0 and JSON-P 1.1.
>
> Emily
>
> On Monday, April 6, 2020 at 4:00:59 PM UTC+1, David Lloyd wrote:
>>
>> On Mon, Apr 6, 2020 at 9:53 AM 'Emily Jiang' via Eclipse MicroProfile
>> <microp...@googlegroups.com> wrote:
>> >> Certainly I didn't read "MicroProfile specifications" as being CDI, JAX-RS, etc, as they're not defined by MicroProfile
>> >
>> > The fact is that they are packaged in MicroProfile releases. How can an runtime claim the compliance for MicroProfile 1.0? Are you suggesting anyone whether or not they support the included CDI, JAX-RS, and JSON-B, they are free to claim the compliance as they are not defined by MP?
>>
>> I looked around the release artifacts for MicroProfile and I didn't
>> find these specifications packaged anywhere. Can you please show me
>> where these specifications are packaged with the MP release? Or do
>> you mean "packaged" in some other metaphorical way (and if so could
>> you explain)?
>>
>> --
>> - DML
>>

> --
> 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/4565819d-756a-4a96-9f01-5c8aef7d988a%40googlegroups.com.



--
- DML

[Ken Finnigan]

Do we require all conversations to happen on Hangouts? Is that defined anywhere?

I've lost count of the number of times I raise something in a Hangout to be told "raise it on the ML" instead.

If we're really trying to be asynchronous and collaborative, why funnel everything through a Hangout?

It's not like I'm surreptitiously enforcing this rule in a corner where no one can see, I've opened a very public vote on the matter in a way that all committers can respond.

Apologies if people didn't feel the discussion on the topic hadn't reached a conclusion, but I'd seen no other comments for weeks and clearly wrongly presumed that most agreed with the outcome.

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/4565819d-756a-4a96-9f01-5c8aef7d988a%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/c07e9462-84ce-4f4c-92e5-c0027f34807c%40googlegroups.com.

[David Lloyd]

I have the opposite problem: with quarantine/lockdown going on and six
kids (some with special needs) who now effectively need to be
homeschooled, my schedule is often truly chaotic (evil) so I for one
can't usually attend the hangouts unless the planets align
miraculously. I rely on the lists exclusively along with whatever I
can glean from minutes and my coworkers. Do votes truly have to be
socialized on the hangout before they can take place?

>>> 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/4565819d-756a-4a96-9f01-5c8aef7d988a%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/c07e9462-84ce-4f4c-92e5-c0027f34807c%40googlegroups.com.



--
- DML

[Ondro Mihályi]

I agree with this, Ken. But it isn't stated in the proposal under the vote. If we also add that MicroProfile still encourages to abide the EE specifications as much as possible even though it can't be covered by tests then I would vote for it. But I can't accept the current proposal.

po 6. 4. 2020 o 16:44 Ken Finnigan <k...@kenfinnigan.me> napísal(a):

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/lQF-9i_S7rg/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/CAKeeVe4DhP5uLi9ACdoagr9WPejQTRxcX_GCeuAmteuG3co%3DyA%40mail.gmail.com.

[Ondro Mihályi]

David, don't take me wrong by I think your understanding is completely out of reality. The resources Emily linked clearly prove that MicroProfile umbrella includes also the EE specifications. Can you please share some evidence which suggests that those EE specs are only dependencies and not expected to be supported by an MP implementation? 

po 6. 4. 2020 o 17:58 David Lloyd <david...@redhat.com> napísal(a):

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/lQF-9i_S7rg/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/CANghgrSzLEV%2B3iLxtgqzZm2akap17Ks_AGm0SZcBWtT-xyYvzw%40mail.gmail.com.

[Ondro Mihályi]

I support Ken in that not everything needs to be discussed on hangouts to happen.

However, Ken, next time I suggest that you first start a thread to discuss the vote and brainstorm opinions before the actual vote takes place. I was very surprised that the vote was started without any introduction and that this thread to discuss the vote was started only after some votes against the proposal were submitted.

po 6. 4. 2020 o 18:03 Ken Finnigan <k...@kenfinnigan.me> napísal(a):

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/lQF-9i_S7rg/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/CAKeeVe7r7C2SitaKR%3Ds1mNsYS4euYaOiw3is5TpO03oX4NNGZw%40mail.gmail.com.

[John Clingan]

FYI, there is not a documented process for introducing a vote. While I like the idea, it is something we should discuss. For example, what should be brought to the broader community vs within a spec team or committee? We're haven't been big on process, so we have to figure out where the line is drawn.

[David Lloyd]

The only wording I have found that comes close to this implication is
"Compliant implementations of Eclipse MicroProfile 3.3 must provide at
least the following APIs and minimum versions." It doesn't talk about
compliance at all though, it only says the APIs need to be present!
In particular I would have expected wording along the lines of
"Compliant implementations ... must in turn be compliant with the TCKs
of the following specifications [with modifications as listed
below...]" if there was any expectation of full compliance (since
compliance itself isn't just a binary on/off thing; it requires an
exact definition).

Is there something I simply missed? Can you please point me to where
I can find more detailed requirements than what I've pasted above,
that says specifically that implementations must comply with the
specification TCKs?

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



--
- DML

[Alasdair Nottingham]

David,

This is the heart of the confusion. Some believe that language about providing the API requires you to actually implement the API and the spec behaviours and others do not. Given there are people involved in MicroProfile since the beginning who interpret this differently says to me we can’t just point at language in what was written as if it resolves the situation.

Alasdair

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CANghgrRXrqDoTTRGrY%2Bxo2b51AYGDP%3D0EM5S0L42g03yqRLEMQ%40mail.gmail.com.

[Ken Finnigan]

I thank you for offering alternative options, and I appreciate I probably needed to discuss the wording of the vote without presuming a wording based on discussions in a previous thread.

Would something like the below be more appropriate?

MicroProfile 4.x compatibility is defined as a runtime passing all MicroProfile specification TCKs in the platform release. MicroProfile encourages implementations to abide by the base Jakarta EE specifications, but does not require the passing of their TCKs for MicroProfile 4.x compatibility.

This then aligns the compatibility definition only applying to MP 4.x releases, which will have a Jakarta EE 8 API as base. While also encouraging runtimes to go beyond just the MP specs themselves.

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

[Ken Finnigan]

Argh, doing too many things at once and I messed up.

The text I wanted to propose was actually:

MicroProfile 4.x compatibility is defined as a runtime passing all MicroProfile specification TCKs in the platform release. MicroProfile encourages implementations to abide by the base Jakarta EE specifications if possible, but does not require the passing of their TCKs for MicroProfile 4.x compatibility.

[David Lloyd]

I think you are right, because I for one am confused! But I think I
can say for certain that there are two aspects here: what the current
situation *is* (which Ondro has said "your understanding is completely
out of reality", so I'm trying to figure out what is actually real if
my understanding is not), and what the situation *should be*.

I might be wrong, Ondro, but I think what you're saying is that your
perception of the situation is different than mine. Am I right?

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/EBA81B94-E74E-4514-B49A-1DB6BF50B272%40gmail.com.
>


--
- DML

[Steve Millidge]

Hi David,

Let me explain where the heat arises in these discussions from a Payara perspective. MicroProfile from close to the beginning professed a CDI first approach whereby CDI was the baseline component model supported by JAX-RS and JSON-P. No we didn't require implementations to pass the TCKs for these specifications because to do so would require vendors such as Payara and others to become Java EE licensees. However it was presumed that implementations would provide, in good faith, a CDI implementation in their runtime, the majority of which use Weld.

Fast forward now and Quarkus claims MicroProfile compatibility but excludes a number of core CDI features some of which you may not be able to implement to support Graal native images and some of which I understand aren't implemented for bootstrap performance and memory footprint reasons.

Obviously, as a small player, if Payara had come along and excluded core CDI features especially ones purely for performance and scalability and then proceeded to emphasize how faster and smaller we were we would have been crucified. Then if we had, IMHO, attempted to reinterpret history and compatibility requirements to push this through we would have been thrown out. From the Payara perspective this is a giant throwing their weight around. 

So we are where we are. Obviously we don't expect a non Jakarta EE based runtime to support CDI integration and features targeted at specifications not included within the MicroProfile platform. However we do expect a level playing field and norms of behaviour that support that level playing field. Therefore longer term we support a CDI-lite runtime definition which excludes these things and that can also support Graal native images if needed. That way we could also implement and strip out bloat in CDI or even collaborate on Arc. However the requirement for and the features of "CDI-lite" should have been brought to MicroProfile months if not years ago to retain the level playing field principle.

"Trust takes years to build, seconds to break and forever to repair"

I am writing this not to raise the heat but reduce the heat.

Steve

[Emily Jiang]

+1 Steve! I agree that instead of claiming a tickbox by lowering bar and move on, we should hold our standard level and fix the problem, as this will confuse our end users a great deal. I have not been told passing 8 TCKs out of 12 TCKs are the same as passing 12 out of 12. Compliance or not is a hard rule and there is no percentage digit associated with.

The urgent thing is to work on CDI Lite, which I started laying out the requirement at this thread. The other tasks are separating out JAX-RS, JSON-P tcks from Jakarta overall tcks so that any runtime can certify them separately.

Emily

[David Lloyd]

Thanks for the explanation Steve; it's clear and makes sense. For our
part, I (speaking for myself at least) don't believe that any of my
colleagues (at least) ever intended to throw their weight around (such
as it is). And I would be disappointed if your hypothetical scenario
was true. I would hope that, were our positions reversed, that we
could evaluate the issue fairly to all sides, and I think it is right
and just to try to understand your (and others') position(s) and your
reasons for it.

But whether or not that is the case, I hope we all agree that when the
specification doesn't say, one way or the other or with any
specificity, what the requirement is, that different people will
interpret it in different ways (because, well, that's what happened).
The best defence (IMO) against this kind of problem is a high quality
specification which is very clear about what is required versus what
is open to interpretation.

So now we must decide which way to go. There are two layers to the
problem: resolving the disagreement about the specification by
revising it, and the problem of what to do with implementations which
had differing interpretations. (Note well that we can expect this
kind of thing to happen frequently in any cross-industry specification
effort, so it would be a good idea to have a plan in place!)

Pragmatically, I think that we will all continue to disagree about
what the specification says until we are all in a position where
either interpretation can work for all of us. So to me that says: if
we want to revise the specification such that fully spec-compliant
implementations of the APIs are present, we're going to need a
definition of spec compliance that works for everyone, and we're going
to need the specs to be such that it's *possible* for us (and others)
to comply with it. To me this means: "CDI lite". So from my
perspective (not speaking for Red Hat but just for myself), that seems
like it is necessarily the first step, and everything else is really
just wasting time and energy, to be honest.

> --
> 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/579836fb-a6d1-4e3e-8865-7fe93051dcf8%40googlegroups.com.



--
- DML

[m.reza.rahman]

Firstly I am glad that this is getting sorted out. I am also very happy to see the fact that this effort is driven by a desire to meet the good faith concerns of end users and the community of people outside of necessarily MicroProfile commiters and direct contributors to MicroProfile. I think those are key ethos to growing just about anything.

My observation on this is that not everything can have a quick and easy fix. Some things just take time and need broader, truly multilateral consensus building.

Personally I still want to understand from an end user perspective why CDI Lite is a critical imperative. In particular when the time is right I would like to understand why supporting portable CDI extensions is a challenge in Quarkus.

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

[Rudy De Busscher]

On Tuesday, 7 April 2020 17:08:02 UTC+2, Ken Finnigan wrote:

Argh, doing too many things at once and I messed up.

The text I wanted to propose was actually:

MicroProfile 4.x compatibility is defined as a runtime passing all MicroProfile specification TCKs in the platform release. MicroProfile encourages implementations to abide by the base Jakarta EE specifications if possible, but does not require the passing of their TCKs for MicroProfile 4.x compatibility.

Although this definition is positive, every implementation should try to be compliant, but the user has no idea if implementation passes the Jakarta EE specifications or not based on the compatibility label. So the confusing for the user stays the same.

So for me, the text should indicate that MP compatibility means that Jakarta EE specs are not covered (and thus MP is not compatible with Jakarta EE) or there is full compliance with the used Jakarta EE specs (which is difficult for non-Jakarta EE based runtimes due to the current status of the TCK.)

Rudy

 

On Tue, Apr 7, 2020 at 10:57 AM Ken Finnigan <k...@kenfinnigan.me> wrote:

I thank you for offering alternative options, and I appreciate I probably needed to discuss the wording of the vote without presuming a wording based on discussions in a previous thread.

Would something like the below be more appropriate?

MicroProfile 4.x compatibility is defined as a runtime passing all MicroProfile specification TCKs in the platform release. MicroProfile encourages implementations to abide by the base Jakarta EE specifications, but does not require the passing of their TCKs for MicroProfile 4.x compatibility.

This then aligns the compatibility definition only applying to MP 4.x releases, which will have a Jakarta EE 8 API as base. While also encouraging runtimes to go beyond just the MP specs themselves.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d7b1e4fe-1085-4bf1-a037-59fed22137e2%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/lQF-9i_S7rg/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/CAKeeVe4DhP5uLi9ACdoagr9WPejQTRxcX_GCeuAmteuG3co%3DyA%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/CACZTZYVaXr5DaXr0nyKVPWej3hRnZfY6Hu3ay9-XiFWhQqPvrA%40mail.gmail.com.

[Sergey Beryozkin]

Hi All,

As a user, I'd like to understand how all of those extra CDI features which a given project may not fully support/implement are *relevant to the users writing portable MP code* given that the MP space seems totally self-contained, example, MP Config supports all of the other specifications with the help of CDI, every MP spec can make something available to the users (ex @Inject JsonWebToken jwt) with the help of CDI. How can these extra CDI features contribute to the execution of a given MP spec given that every spec outlines or should outline the expectations around CDI ?

Cheers, Sergey

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/49eed300-5267-4b65-afb5-2a03f78f20c0%40googlegroups.com.

[Sergey Beryozkin]

As a user, if I see 'MP Compatible' I expect that a given container will give me everything I need to do a portable code around a given MP spec: I should be able to write a portable fault tolerance code, rest client code, jwt code, etc etc. I honestly don't mind what extra CDI features may be around, as an MP user I'm interested in a given MP spec giving me what it promises in its text which a given container guarantees by passing the relevant TCKs (some TCKs may be more complete :-) but it is a separate story).

This is why it is difficult for me to understand how a given container, by implementing an extra CDI feature X, can help me at all around MP.

Thanks, Sergey

[Jonathan Gallimore]

One question I have, while we're talking about what "MicroProfile compatibility" means, is do we want to define something where some is interoperable with MicroProfile? 

For example, I could create an application using something other than Java and run it on a webserver. There's no reason why that couldn't accept JWT tokens that conform with MicroProfile, and it could easily implement metrics and health endpoints that have the same data format as MicroProfile. 

The MicroProfile Proposal (https://projects.eclipse.org/proposals/eclipse-microprofile) does have a point: "Provide an interoperable Microservices architecture that allows communication among polyglot runtimes (not just Java).". Do we want to enable products to identify themselves as "works with MicroProfile" somehow? I personally think its a good idea (which is why I'm asking :-) ) , but no problem if others don't share that view.

Jon

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

--

Jonathan Gallimore

http://www.tomitribe.com

[Rudy De Busscher]

>*relevant to the users writing portable MP code* 

users see that we are using CDI 2.0 and expect that everything contained in CDI 2.0 can be used in the MP implementation. Not just the features which we are using in the MP specs (since there is also no list of what we support and what not of CDI)

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

[Emmanuel Bernard]

Hi Steve, 

Thank you for this message, it shows me that on the RedHatter side, we definitely need to work harder on giving our reasoning and communicating more. 

I don’t necessarily Want to give an opinion on this debate but I have two points. 

Via the work we have done on Weld, Weld SE, Thorntail and then Quarkus, we now know much more precisely what would be (to our eyes) the best CDI lite. Not to us, but to users. We would not have done a good job had we started months or even years ago. We had to have concrete experience that frankly to this day we are still gathering. Many have been burnt with a specification First approach vs a tried and tested _then_ standardize approach — JPA has been mostly a good example of the latter except a few things like the type safe criteria query which is a failure as a result (to me and yes I helped design it).

When we started the first sketches of what is now Quarkus, we had one clear mandate in mind : use the good specs and standards but don’t be constrained by them when they go against the build time architecture approach of Quarkus And the cloud native focus of Quarkus. We knew very early that compromising here would lead to the wrong solution for people. And from day one, we wanted to propose back our spec evolutions to the groups as soon as we had bandwidth and we felt it was the right tested solution. Unfortunately we lagged on that and we now have this thread. 

I hope this helps you understand where RedHatters come from (not that we don’t even think alike but we talk a lot to each other to debate). We are not in the standard factory business, we are in the solving problem for users business and we do see standard have a big role but still as a servant of users needs. 

My second point is that I have been talking to too many people to count in the past 18 months and by a large majority people like MicroProfile. They don’t like it because they can write a MP application. They like it because they can solve their problems with MicroProfile libraries. They are not after a platform, they are after libraries who have the big advantage of being backed by specs and the interest of several vendors. Oh and primarily because they get the job done. 

Peace

Emmanuel

--
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/579836fb-a6d1-4e3e-8865-7fe93051dcf8%40googlegroups.com.

[Reza Rahman]

Firstly, thanks indeed for sharing your thoughts. I do hope you know most of us want to see MicroProfile succeed on it's own right with the right user cohort without introducing needless risks to a broader ecosystem.

I think we really need to discuss the CDI Lite issue more in it's proper context. The biggest pain points described by folks that I come across that have tried to evaluate Quarkus is library integration, especially immediately with CDI portable extensions for folks coming from a Java EE background. Another consistent and related theme is compatibility and the lack of Java EE APIs they expect. My understanding had been that this feedback was passed on to Red Hat properly. It is possible someone dropped the ball on passing on candid and helpful feedback.

One hypothesis to consider is whether the promoters rather than detractors are the ones you are encountering: https://beyondphilosophy.com/promoter-or-detractor-why-you-need-know-answer-question/. One other hypotheses to consider is that positive reinforcement on something that one has a lot of psychological investment in tends to create strong implicit bias (it is a natural part of human nature we are all susceptible to some degree or another and a result of thousands of years of evolved survival instincts for a social species).

Nonetheless, as I said I think I would like to understand a lot of this from you and hopefully share some useful insights with you when it is time to discuss CDI Lite in detail in the most appropriate context.  

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 unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Ken Finnigan]

A discussion on what "CDI Lite" could mean for MP has already been started: https://groups.google.com/forum/#!topic/microprofile/Rg4MPG4E6J4

As for Quarkus supporting Java EE/Jakarta EE APIs, it was said from the beginning that Quarkus would not offer all implementations of Java EE/ Jakarta EE APIs, but only a subset. If there are APIs that are not currently included that users feel should be, then they're more than welcome to propose them as feature requests on a Quarkus issue.

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/234cfa2b-ed74-4d0a-9cc4-7d64e4576485%40googlegroups.com.

[Emmanuel Bernard]

Well to your point, I had very few users and customers asking for PE support and some requests for some Java EE specs, e.g. SOAP support (cxf was asked) and JMS (because of XA integration). I have not seen others on the top of my head except some for a batching feature. We had requests for some extra CDI features that we try and accommodate as they come.

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/234cfa2b-ed74-4d0a-9cc4-7d64e4576485%40googlegroups.com.

[Ondro Mihályi]

Maybe it's worth looking at CDI from a different perspective. What if CDI was an MP spec? Then all MP implementations would have to implement all of it. Now, we may come to an agreement that some of it isn't useful and should be dropped. We would release CDI 3.0 which drops some APIs like PE. It would be part of the next major MP version.

But CDI is in JakartaEE. To emulate the usual process, we would create a temporary MP-CDI spec that defines which parts of Jakarta CDI are not needed. We would define how to run the tests in CDI TCK to pass the MP TCK and maybe add some more tests. Or simply fork the CDI spec and TCK.

I admit it's too much work but it's the best way to clarify which part of CDI is in MP. The only other alternative is to wait for a CDI Light profile which as a whole is good enough for MP. Switching to CDI Light in the future would be again a breaking change and require a new major MP version.

Technically, dropping all JEE specs is also a breaking change and we could do it with any new MP version. But I doubt this is what most of us want. And even if we do it, we would have to define a subset of required JEE behavior anyway because some MP specs rely on it. And this is the same thing as forking the JEE specs anyway.

If we decide that MP continues to contain JEE specs but say that it's enough to pass the MP TCKs is like saying it's up to impls to implement them as they wish. Is this what we want?

After all this thinking, I think that we should wait for CDI Light and actively contribute to make it happen. Until then, we can state that passing TCKs for JEE specs is not required but this is subject to change. And we should gradually specify how to run TCKs for JEE specs as they become available. For CDI we can already start doing it.

Ondro

[Ebuzer Taha Kanat]

Why not leave the standards as it is and not expect them to comply with some partial implementation like i don't know Quarkus. I think those techs can live by their own or if they need to be part of some standards they should pass that standards. That way standards be standards and implementations stay as implementations. And standards wouldn't have some sort of further smaller user base.

Sorry but i had to say it because i was going to lose all my teeth to grinding.

3 Nisan 2020 Cuma 14:58:37 UTC+3 tarihinde Ken Finnigan yazdı:

Steve/Rudy,

I'd be curious to know, if you're willing to share, what the reasoning is for voting against the "MP Compatibility" definition under vote in [1]?

From the discussion in [2], is there a different type of voting outcome you were anticipating?

Thanks

Ken

[1] - https://groups.google.com/forum/#!topic/microprofile/0q8qR9JI4nE

[2] - https://groups.google.com/forum/#!topic/microprofile/XY1a_9JqMtU

[Werner Keil]

Well CDI is an MP spec at least in the sense that the equivalent to the two Profiles in Jakarta EE (Web Profile, Full Profile) does not seem to really exist in MP, so the "MP Platform" is not so strict and every Jakarta EE Spec is optional to use, but where one or more are used, e.g. Jakarta REST, JSON or CDI, then it is really hard to understand why an implementation should be allowed to pick only some TCKs to pass, can they also do so within MP say pass 2/3 and claim "OK we're somewhat compatible"? 

It's pretty much the same if you pass the MP ones but fail the Jakarta TCKs of the underlying specs. 

You can't be "half pregnant" either, so at least for a particular spec, whether one or more are used, their TCKs should also be passed.

Btw why is the SE feature in CDI 2 not "light" enough alredy?

Werner

[Ondro Mihályi]

To answer your last question, Werner, my understanding is that CDI SE is not light enough because:

- the SE-specific APIs, although very small, is completely irellevant to MP

- some features like extensions are still required by CDI SE but we're discussing here that this is probably too much for all MP implementations

We could solve the first with instructions how to pass the CDI TCK to run all the tests for CDI SE without those specific to SE, which I proposed already in a different thread.

But if we want to drop support for some extra stuff like extensions then we really need a lighter profile for CDI. 

Ondro

Dňa po 13. 4. 2020, 22:46 Werner Keil <werne...@gmail.com> napísal(a):

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/lQF-9i_S7rg/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/5cc77f2f-6848-4294-8627-484f1041d7df%40googlegroups.com.

[Emily Jiang]

I suggest not to waste any more time with the infinite cicle :o of discussions but to focus on the following tasks to get work done as highlighted in my earlier reply.

The urgent thing is to work on CDI Lite, which I started laying out the requirement at this thread. The other tasks are separating out JAX-RS, JSON-P tcks from Jakarta overall tcks so that any runtime can certify them separately.

Emily

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

[Reza Rahman]

Thanks for the reference. I indeed did chime in to that thread already and I was hoping the discussion would progress a bit more. At the moment, basically I agree with Emily but it does not yet feel like that is the consensus decision and it did not feel like I really heard or understood all the perspectives - certainly perhaps not the AOT perspective.

If the discussion there restarts, I would love to hear from informed end users particularly (it is tough to convince the end user types to chime into seemingly stale discussions, but I can at least give it a shot anyway and see what happens).

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/CAKeeVe4OFVwnJ7-dNrVVRh6BGj%2B3t%3Dsxrfn7GOq_4BhVxb7tWg%40mail.gmail.com.