MP 3.3 in Feb 2020

[Ken Finnigan]

All,

For those that may not have seen, we've decided to update to Jakarta EE 8 APIs for the MP 3.3 platform release in Feb 2020.

As a consequence of that decision, we need every specification to provide a minor update that includes the new Jakarta EE 8 APIs. There's no requirement that a specification provide any feature updates, but there must be a release that includes the new APIs so that we can align for MP 3.3

I don't know the exact date as to when specifications will need to be released for MP 3.3, John took an action to update the calendar in today's MP Architecture call, but it's probably around mid-January.

I would appreciate everyone's cooperation in getting a release of each specification by mid-January to ensure MP 3.3 is a smooth transition to Jakarta EE APIs.

Thanks

Ken

[Amelia Eiras]

Wonderful follow up reminder Ken. 

MicroProfile release based on Jakarta EE 8 APIs [thread from Nov 20th with 13 contributors +24 exchanges]

Can we have a reminder of who are the 2 Microprofilers leading the MP 3.3. release? 

By my count based on the release process we agreed on, the current individuals are:

1.  Edwin [trainer] and 
2. X? [trainee]
   

[John Clingan]

Edwin is leading, and I am #2. Kevin, of course, remain the guru backup. It will take Edwin a couple more releases before he can become a trainer. After 3.3 he should have enough battle scars to have a committer election, and he will be able to actually do much of the hands on work directly. Right now he is shadowing me doing the hands-on work since it turns out that being a committer is required to do most of the hands-on work. Plus, generally speaking, the releases are far enough apart (some level of mental atrophy) that it takes at a few releases to get in the groove. Either that or I'm just showing my age :-)

[John Clingan]

FYI, we are discussing the Feb release date right now. The component spec release dates will likely be early Feb, give or take a week.

On Tuesday, December 3, 2019 at 12:31:49 PM UTC-8, Ken Finnigan wrote:

[Amelia Eiras]

Wonderful follow up John! 

I say, can we add it as  part of  the release wiki? Your write-up is a core part of the release as is effectively explains beyond the known meat what what on the process itself and a sure way to become a MP committer! 

win/win. :)

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com      https://tribestream.io   

OSS:  http://microprofile.io     https://jakarta.ee

--
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/cDx5TlPFY1o/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/d8dffdbe-001c-4415-83d3-780844b8729c%40googlegroups.com.

[Kevin Sutter]

I know we're well on the way for this update for Jakarta EE 8 APIs, but a discussion with a local MP developer raised a valid question...

IF the only change for an MP component is to update the dependencies from Java EE 8 APIs to the corresponding Jakarta EE 8 APIs, then why is a minor version update required?  Can't we just update those as a service/patch version (ie. 3rd digit)?  Jakarta EE 8 is functionally equivalent to Java EE 8.  The APIs themselves are identical -- still in the javax namespace.  And, look at the Jakarta EE Compatible App Servers -- none of them had to make any updates to their code to be Jakarta EE 8 compliant.

So, why make this a bigger deal than it really is?  Update our maven coordinates to point at the Jakarta EE 8 APIs.  But, do this as a service/patch release.  I know there are a handful of components that are looking to add additional function in MP 3.3, so they will need to update their minor version.  But, for the simple maven coordinate update, keep it simple.

Thoughts?

Kevin

[Edwin Derks]

Hi Kevin,

Is updating every specs minor version or a patch version not an update nonetheless? Does it matter in regards of the amount of work that has to be done for the specs that are not including functional changes?

Second, didn’t we discuss lately that we’re not using the third digit in MP spec releases? Which resulted in a Metrics 2.2 instead of a 2.1.1 if I remember correctly?

Or am I completely off here not having my facts straight. I apologize if I do.

Kr,

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/96b1d27d-88f4-4c49-82b4-7b0395206048%40googlegroups.com.

[Martin Stefanko]

I wrote the service upgrades down some time ago in [1]. This supports the reasoning that if there are no API changes we can request only service version upgrade. However, the minor upgrade was proposed at the beginning of the Jakarta upgrades discussion and the reason I believe was that we are trying to avoid service upgrades in the parent pom (at least they are not included in there right now) so users will not be influenced by the service upgrade if they don't include the dependency of the service spec API release directly.

 

[1] https://xstefank.io/2019/10/09/minor-patch-releases-in-microprofile/

[Kevin Sutter]

Thanks, Martin, for that reference.  That write-up is consistent with what we expected the major.minor.service version numbering to represent.

To follow through on this, let's consider the simple change to update the maven coordinates for CDI for MP Config.  (For this exercise, forget about any other proposed changes to Config for MP 3.3)  Changing the maven coordinates would not be a major version update since there are no breaking API changes.  So, no change to the major version.  And, there are no other changes to the Config API -- no new APIs, no clarifications to existing APIs, nothing.  Just updating the maven coordinates for CDI.  So, there is no reason to update the minor version either.  But, we are updating something, so we do need an updated version.  Since there is no impact to the Config API itself, then it follows that the service version should be the item to update.

This all seems very consistent with our reasoning for our major.minor.service version numbering.  If the only thing that an MP component is doing is updating the maven coordinates for the Jakarta EE dependencies, then we're not affecting the API in the least.  So, we should not be confusing the consumer with a minor version update when there is no way that this version update would affect them.  That's the key message.

Hope this helps,

Kevin

[Emily Jiang]

There is a slight different angle to look at this. If some specs do micro releases, these releases will not make to MP 3.3 as we don't pick micro changes. With this, I think we should ask all specs to release a minor version.

Emily

[Edwin Derks]

Hi Kevin,

So in this case of no Config api changes (minor or major), the MP parent will refer to a major.minor.micro release of Config because of just the Jakarta adoption? I’m just trying to fully understand what the plan is.

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/3af2985d-f02b-4cbb-954d-bf2179a1f24a%40googlegroups.com.

[Emily Jiang]

To add a big more justification: micro release is a bug fix release. Moving up the dependency is a lot of more significant than a bug fix. Therefore, I think minor release makes more sense.

Thanks

Emily

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/cDx5TlPFY1o/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/c92fc11c-5e4b-44cc-a040-5586c59cb4a1%40googlegroups.com.

--

Thanks
Emily

[Kevin Sutter]

That's a fair point, Emily.  But, the reason we don't pick up service/micro versions is because there should not be any API updates -- which is the case for the simple Jakarta EE update.  As far as "picking up the changes", what would there be to "pick up"?  The top level platform pom that creates the overall pom/bom will bring in the necessary Jakarta EE APIs.  And, each individual component can specify their Jakarta dependencies (unless they are also using the parent pom) in their micro version update.

Whether a customer is using Java EE 8 or Jakarta EE 8, it really shouldn't matter.  And, delivering this update via a micro release accomplishes that goal -- it shouldn't matter.

-- Kevin

[Kevin Sutter]

Edwin,

Per my reply that I just did for Emily's response...  The MP parent would *not* refer to a major.minor.micro release.  The API has not changed.  So, only the minor version is desired.  The top level dependencies for Jakarta EE would be brought into the resulting MP 3.3 release artifacts.

This should all work as it does today...  For example, I took a look at Health 2.1.  Their pom still references CDI 1.2, even though the MP 2.x and 3.x releases have all declared a dependency on CDI 2.0 (as part of Java EE 8).  This "override" seems to have worked out okay.  So, what's different?

Actually, maybe that's an even greater simplification of the problem.  Only change the top-level pom to bring in the Jakarta EE dependencies.  I bet that would continue to work.  But, it would still be a good idea to break the connection with Java EE.  So, I still like the idea of re-releasing each component.  I just think it's a micro update and not a minor update.

- -Kevin

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

[Kevin Sutter]

In this particular case, I don't think that changing from Java EE 8 dependency to Jakarta EE 8 dependency is a significant bug fix.  It actually should be a no-op.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c92fc11c-5e4b-44cc-a040-5586c59cb4a1%40googlegroups.com.

--

Thanks
Emily

[Emily Jiang]

I don't think doing micro release is sufficient.

Let's image: MP Health does a micro release 2.1.1 to align with Jakarta EE8

MP 3.3 just includes MP Health 2.1 becasue umbrella releases don't include sub spec's micro releases.

2.1 means 2.1.0. The release 2.1.1 will not be picked up.

Thanks

Emily

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/c92fc11c-5e4b-44cc-a040-5586c59cb4a1%40googlegroups.com.

--

Thanks
Emily

[Ladislav Thon]

I would like to highlight one thing that surprised me when updating MP Fault Tolerance to use Jakarta artifacts. The Jakarta CDI API has a dependency on Jakarta EJB API, which wasn't the case with Java EE CDI API. I don't know if there are other cases of this, but I have to suspect so. This means that on the API artifact dependency level, replacing Java EE with Jakarta is NOT a 1:1 change.

Whether that's meaningful to the discussion about version numbers, I don't know :-)

LT

Dne čt 19. 12. 2019 0:08 uživatel 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> napsal:

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/0adcfce8-ce9d-47b8-8443-2efbce6f67bd%40googlegroups.com.

[Edwin Derks]

Emily,

that’s exactly how I understand it. Therefore I can’t grasp that in my head how Kevin pictures the version numbers in the umbrella spec.

Kevin, I’m not doubting your expertise in this, I just can’t paint the picture in my head with the details that I read.

Is it maybe a good idea to paint this idea in a picture or make it visible in other ways to clarify the details?

Edwin

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

[Jan Martiška]

On Thursday, December 19, 2019 at 9:27:27 AM UTC+1, Ladislav Thon wrote:

I would like to highlight one thing that surprised me when updating MP Fault Tolerance to use Jakarta artifacts. The Jakarta CDI API has a dependency on Jakarta EJB API, which wasn't the case with Java EE CDI API. I don't know if there are other cases of this, but I have to suspect so. This means that on the API artifact dependency level, replacing Java EE with Jakarta is NOT a 1:1 change.

That's a bug which was fixed but the fix is not yet present in any released artifact: https://github.com/eclipse-ee4j/interceptor-api/issues/31

I suppose that we should just exclude it as a workaround for now?!

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/0adcfce8-ce9d-47b8-8443-2efbce6f67bd%40googlegroups.com.

[Kevin Sutter]

Ouch!  This is kind of a major item that needs to be resolved before we can pull CDI 2.0.x into MP 3.3.  Is CDI planning a 2.0.3 update to get this corrected?  Or, how can the MP do a workaround to prevent this EJB inclusion?

Thanks for catching this!

-- Kevin

[Kevin Sutter]

Emily and Edwin,

I decided to show you via a PR...  https://github.com/eclipse/microprofile/pull/157

You'll notice a couple of things... 

• The API versions for the Jakarta EE specs all use a micro version (to differentiate jakarta.* from javax.* artifacts in Maven).  So, avoiding micro versions for the Jakarta dependencies is not doable.
  
• With this change, I built MP 3.3-SNAPSHOT (platform) without any changes to the MP components.  The dependencies are all with jakarta.* and no changes were required for the child components.  So, if somebody would utilize the 3.3-SNAPSHOT pom in their application pom, they would get the jakarta dependencies.

The individual components should still update their respective poms for the jakarta dependencies that they utilize.  This would allow applications that only bring in Config (for example) to only specify the Config 1.3.1.  That's how they would get the jakarta dependencies on an individual basis.  But, at the platform level, it would be taken care of by the top-level pom.

I'm happy to be proven wrong on this.  But, I really think we are over-complicating this jakarta move.  Just like Jakarta EE 8 was a breeze to support for the App Servers and Applications, it should be just as easy for MP.

-- Kevin

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

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0adcfce8-ce9d-47b8-8443-2efbce6f67bd%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+unsubscribe@googlegroups.com.

[Emily Jiang]

Kevin,

On MP BOM, we only specify major.minor, we would not be able to bring in Config 1.3.1, which was Edwin was asking for? I think you try to show how to bring in Jakarta EE dependences. However, that was not the question though unless I am on a different question. 

Thanks 

Emily 

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/25257228-6fa4-4c27-a379-6e10ed77fb52%40googlegroups.com.

[Kevin Sutter]

I understood the question...  I was just pointing out that we can't avoid micro versions for the jakarta dependencies.  And, at the platform level, it doesn't matter if we only pull in Config 1.3 (as an example), even if Config 1.3.1 has the jakarta dependencies.  The API for Config 1.3 is what the platform is concerned with.  The jakarta dependencies are satisfied with the platform pom, not the component pom.

-- Kevin

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/25257228-6fa4-4c27-a379-6e10ed77fb52%40googlegroups.com.

[Emily Jiang]

Not really. If you specify config 1.3, you will not get the config 1.3.1 API. With the old version of Config 1.3, it will get the dependence on Java EE8 not Jakarta EE8. This is what we want. Right? Maybe just try it out, Edwin. 

Emily 

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/205e91e5-1924-4301-b06d-48b2cc44be9d%40googlegroups.com.

[Kevin Sutter]

Yes, please experiment.  You'll either end up agreeing with me, or you can prove me wrong.  Either way, I'm happy.  :-)

-- Kevin

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/205e91e5-1924-4301-b06d-48b2cc44be9d%40googlegroups.com.

[Edwin Derks]

Emily, that is exactly the behavior I expect. 

This is not about me being right or not, but Kevin seems pretty sure of his solution so I will definitely check it out. I/we might learn something here. :)

I will get back to you both whenever I have been able to look at it.

Cheers!

Edwin

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/0adcfce8-ce9d-47b8-8443-2efbce6f67bd%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/CALbocO%3DdR1j76fcMH0vmbdCxMtkGUDJ4jNDmERpv_PaUWgjdCg%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/cDx5TlPFY1o/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/25257228-6fa4-4c27-a379-6e10ed77fb52%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/cDx5TlPFY1o/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/205e91e5-1924-4301-b06d-48b2cc44be9d%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/87de4a2f-c51c-42ab-b341-a12c7f0d27c6%40googlegroups.com.

[John Clingan]

Oh boy, that coulda hurt.  Ladislav, huge thanks for pointing it out.  I wonder if there are other issues like this lurking out there. Me-thinks we'll have to be extra diligent this release.

[Edwin Derks]

Hi Kevin,

I looked at the PR, thanks for providing that! I think I now understand better what you were aiming for in the first place, so here goes:

1. MP 3.3 (Snapshot) now contains the Jakarta dependencies, and will indeed still allow you to build the MP 3.3 platform project. The MP platform has now adopted the Jakarta EE API's.

2. In the meantime, to continue with Config as example, this specific Specification can update to 1.3.1, also adopting the Jakarta EE API's as required for all core Specifications.

3. I think at this point is where I got confused. I understood initially that it was now required that the MP platform adopts Config 1.3.1 and all other Specifications that are required to adopt the Jakarta EE API's for the 3.3 release. My train of thought was: why would the Specifications otherwise be required to adopt the Jakarta EE API's for MP 3.3, as that Specification patch release is not taken into the MP platform 3.3 release. But if I understand you correctly, that is not the case. The MP platform is fine with MP 1.3, as long as the next functional version of Config (e.g. 1.4 or 2.0) is based on the Jakarta EE API's.

Are these assumptions correct? I think it is a summary of your comments earlier, but in that case, I understand the way to go here and will go perfectly along with it. :)

Edwin

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/96277a17-4b38-4efc-ad08-deb9b19ae7e7%40googlegroups.com.

[Kevin Sutter]

Yes, Edwin, that's what I've been thinking.  Thanks for the experimenting and reviewing.

The only exception is the last sentence in your number 3 bullet:

>. The MP platform is fine with MP 1.3, as long as the next functional version of Config (e.g. 1.4 or 2.0) is based on the Jakarta EE API's.

TBH, at the platform level, the component APIs can be upgraded to Jakarta EE APIs at any time.  If Config updates the dependencies at 1.3.1 (due to no other changes) or in 1.4 (due to additional changes), it doesn't matter.  The platform dependencies override what is brought in at the component level.  My example with Health shows that.  They didn't update to the Java EE 8 APIs until much later than the Platform pom.  That allowed them to use the Java EE 8 APIs with the Platform, but they continued to depend on the Java EE 7 APIs in their standalone pom.  But, since we want to break this dependency on the javax dependencies, we want all of the component features to update to the Jakarta EE 8 API dependencies -- in a micro release for no other MP 3.3 changes, or in a minor release if additional changes are coming in MP 3.3.

Thanks again!

Kevin

[Martin Stefanko]

I also tested this a little in [1] - plain jar with:

With MP 3.2 as the only dependency - `mvn dependency:tree`:

[INFO] \- org.eclipse.microprofile:microprofile:pom:3.2:provided

[INFO]    +- javax.enterprise:cdi-api:jar:2.0:provided

[INFO]    |  +- javax.el:javax.el-api:jar:3.0.0:provided

[INFO]    |  +- javax.interceptor:javax.interceptor-api:jar:1.2:provided

[INFO]    |  \- javax.inject:javax.inject:jar:1:provided

[INFO]    +- javax.ws.rs:javax.ws.rs-api:jar:2.1:provided

[INFO]    +- javax.json.bind:javax.json.bind-api:jar:1.0:provided

[INFO]    +- javax.json:javax.json-api:jar:1.1:provided

[INFO]    +- javax.annotation:javax.annotation-api:jar:1.3:provided

[INFO]    +- org.eclipse.microprofile.config:microprofile-config-api:jar:1.3:provided

[INFO]    |  \- org.osgi:org.osgi.annotation.versioning:jar:1.0.0:provided

[INFO]    +- org.eclipse.microprofile.fault-tolerance:microprofile-fault-tolerance-api:jar:2.0:provided

[INFO]    +- org.eclipse.microprofile.health:microprofile-health-api:jar:2.1:provided

[INFO]    +- org.eclipse.microprofile.metrics:microprofile-metrics-api:jar:2.2:provided

[INFO]    +- org.eclipse.microprofile.jwt:microprofile-jwt-auth-api:jar:1.1:provided

[INFO]    +- org.eclipse.microprofile.openapi:microprofile-openapi-api:jar:1.1:provided

[INFO]    +- org.eclipse.microprofile.rest.client:microprofile-rest-client-api:jar:1.3:provided

[INFO]    \- org.eclipse.microprofile.opentracing:microprofile-opentracing-api:jar:1.3:provided

Looks as expected.

With MP 3.3-SNAPSHOT built from Kevin's PR (https://github.com/eclipse/microprofile/pull/157) as the only dependency - `mvn dependency:tree`:

[INFO] \- org.eclipse.microprofile:microprofile:pom:3.3-SNAPSHOT:provided

[INFO]    +- jakarta.enterprise:jakarta.enterprise.cdi-api:jar:2.0.2:provided

[INFO]    |  +- jakarta.el:jakarta.el-api:jar:3.0.3:provided

[INFO]    |  +- jakarta.interceptor:jakarta.interceptor-api:jar:1.2.5:provided

[INFO]    |  |  \- jakarta.ejb:jakarta.ejb-api:jar:3.2.6:provided

[INFO]    |  |     \- jakarta.transaction:jakarta.transaction-api:jar:1.3.2:provided

[INFO]    |  \- jakarta.inject:jakarta.inject-api:jar:1.0:provided

[INFO]    +- jakarta.ws.rs:jakarta.ws.rs-api:jar:2.1.6:provided

[INFO]    +- jakarta.json.bind:jakarta.json.bind-api:jar:1.0.2:provided

[INFO]    +- jakarta.json:jakarta.json-api:jar:1.1.6:provided

[INFO]    +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:provided

[INFO]    +- org.eclipse.microprofile.config:microprofile-config-api:jar:1.3:provided

[INFO]    |  \- org.osgi:org.osgi.annotation.versioning:jar:1.0.0:provided

[INFO]    +- org.eclipse.microprofile.fault-tolerance:microprofile-fault-tolerance-api:jar:2.0:provided

[INFO]    +- org.eclipse.microprofile.health:microprofile-health-api:jar:2.1:provided

[INFO]    |  \- javax.inject:javax.inject:jar:1:provided

[INFO]    +- org.eclipse.microprofile.metrics:microprofile-metrics-api:jar:2.2:provided

[INFO]    +- org.eclipse.microprofile.jwt:microprofile-jwt-auth-api:jar:1.1:provided

[INFO]    +- org.eclipse.microprofile.openapi:microprofile-openapi-api:jar:1.1:provided

[INFO]    +- org.eclipse.microprofile.rest.client:microprofile-rest-client-api:jar:1.3:provided

[INFO]    \- org.eclipse.microprofile.opentracing:microprofile-opentracing-api:jar:1.3:provided

The `javax.inject:javax.inject` in health is a leftover dependency without `provided` scope (going to be fixed in https://github.com/eclipse/microprofile-health/pull/217 and Health 2.2 for February release). All other specifications have Java EE dependencies in the `provided` scope. So I believe this should be working.

Martin

[1] https://github.com/xstefank/microprofile-3.3-test

[Emily Jiang]

Thank you Edwin and Martin for further experimenting this! I also spent a bit more time before I log off for vacation and I think I now understand what Kevin meant.

Basically, as long as platform specifies the jakarta dependency, even though MP 3.3 pulls in the old version of spec such as Config 1.3, which depends on Java EE8 and it does not matter much because the package name has not changed between Jakara EE8 and Java EE8. The old config jar can still function. I was on the context of getting the up-to-date spec jars. Thank you Kevin for your patentience!

As for the annotation-api wrongly pulls in ejb dependency (https://github.com/eclipse-ee4j/interceptor-api/issues/31) noticed by LT, I think a micro release on interceptor-api needs to be done. Does anyone know how to push that forward?

Thanks

Emily

[Ken Finnigan]

Catching up on this thread as was on PTO for most of it.

While I agree it appears that we could do a patch/service release of specs to include Jakarta EE APIs and things may not break, I think it would cause confusion.

If we only have a few specs that are explicitly mentioned as part of MP 3.3 as being updated (by minor versions) while promoting MP 3.3 as a Jakarta EE 8 aligned release, that will create confusion as to the status of all the remaining specifications as to whether they're using Jakarta EE 8 APIs. Users then need to do their own digging to find out the detail that patch/service updates to all the other specifications include the Jakarta EE 8 APIs.

Another concern would be users that choose to "piecemeal" things together themselves. If they're updating the "new" releases from MP 3.3 directly, they could easily end up in a situation of duplicate classes being found. Although Java EE 8 and Jakarta EE 8 are API compatible, they're contained within completely different artifacts which means Maven won't pick one over the other (unless there's Maven artifact relocation done I'm not aware of), so you will end up with both!

It's a lot cleaner and clearer to force a minor release of each spec for the Jakarta EE 8 update.

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/fc9971b9-3a00-437c-974c-91fbdc06e9e3%40googlegroups.com.

[Andy McCright]

Hi All,

I'm also just getting back from PTO - sorry for being late to this discussion.  

MP Rest Client has a more interesting situation... In all of the 1.X releases, we supported Java EE 7 technologies (i.e. CDI 1.2, JAX-RS 2.0, etc.).  Moving from Java EE 7 to Jakarta EE 8 is therefore a breaking change for users.  Anybody who pulled in Apache CXF's MP Rest Client into their EE 7 application would be broken when they move to the next MP Rest Client release (or might only be working by sheer luck depending on the Java/Jakarta APIs used).  So, I was planning to release MP Rest Client 2.0 that basically just has the Java EE 7 -> Jakarta EE 8 change (plus a few minor tweaks).  

If my understanding is correct, we cannot allow breaking changes in the February MP umbrella release, so I'm kinda stuck as to what to do... Functionally, there are no breaking changes in MP Rest Client 2.0 other than the EE7 vs EE8 dependencies.  I know that some customers use MP Rest Client in EE7 apps, so they will definitely see this as a breaking change, so I think the 1.X -> 2.X version change is correct.  Maybe we could get an exception to ship a "breaking" change in MP 3.3?  (I put breaking in quotes because from the umbrella's perspective, there is no breaking change - the umbrella spec already requires EE8 - it's only a breaking change from the standalone spec's point of view).

Thanks,

Andy

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

[Alasdair Nottingham]

In your case I think I’d probably suggest leaving MP Rest Client as is for 3.3 and interpret the goal as switching from Java EE 8 to Jakarta EE 8 dependencies and then in the MP 4.0 release in June switch to Jakarta EE 8.

Alasdair

> 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/2c59b297-6958-4861-808b-172102e994ff%40googlegroups.com.

[Kevin Sutter]

I agree.  This is actually a good example in support of only requiring the Jakarta EE API change at the platform level.

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

[Ken Finnigan]

I'm confused as to what the breaking change is for MP REST Client?

Sure it's still on Java EE 7, but as Java EE 8 is backward compatible with Java EE 7, and Jakarta EE 8 is backward compatible with Java EE 8, I'm confused as to why it's a breaking change?

> 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/2c59b297-6958-4861-808b-172102e994ff%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/75011630-16bf-45df-b0c9-38716aca0a8e%40googlegroups.com.

[Alasdair Nottingham]

I think if MP REST Client updates to Jakarta EE 8 then it is saying that you can’t implement MP REST Client on a Java EE 7 runtime anymore. In the past we have treated that as a breaking change that would require a major version upgrade.

I know technically there is nothing to stop an implementation supporting Java EE 7, but if I were to define my maven dependencies I’d be looking to ensure everything was on a consistent version and once you compile against Jakarta EE 8 it becomes much harder to deploy to Java EE 7. This is less about what works vs what it looks like.

Alasdair

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

[Ken Finnigan]

Ok, but doesn't leaving MP REST Client on Java EE 7 dependencies for MP 3.3 negate updating all other specs to Jakarta EE 8?

Having different artifacts on the classpath will lead to duplicate class exceptions, etc.

Do all MP 3.3 implementors then need to exclude all Java EE 7 dependencies from MP REST Client, so that they can work on Jakarta EE 8?

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/F8A0AA67-E4F6-4BE0-A422-C62E1E77757E%40gmail.com.

[Alasdair Nottingham]

Isn’t that already a problem though? Does doing nothing make that worse?

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe6zqJq6U8XPq%3DEuEWPT%2BmFZ9PVjqRMrfZbXYA2a%3Di2__g%40mail.gmail.com.

[Ken Finnigan]

It might be a problem today that isn't found because Java EE 7 to Java EE 8 is the same Maven groupId and artifactId, so Maven could "pick" the newest, Java EE 8.

However, if the rest of MP is on Jakarta EE then the Maven groupId and artifactId is no longer the same, which results in duplicate artifacts on the classpath as Maven doesn't think they're the same

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/A089B15C-2FDD-4FE3-BF52-F0483D115F60%40gmail.com.

[Alasdair Nottingham]

This probably gets worse when you consider my pom likely has the microprofile-rest-client which depends on the individual Java EE 7 specs, like annotation and JAX-RS, but my pom for my application probably has the uber jar for the platform API which means I probably have this problem today even if MicroProfile is self consistent.

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

[Ken Finnigan]

Today I don't think you'd have that problem due to Maven's artifact version selection (granted not always true as it can be funky depending on the hierarchy)

However, with other specs updating to Jakarta EE 8 if MP REST Client stayed "as is", there is guaranteed to be duplicate classes on the classpath without adding exclusions somewhere

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/817C60A6-EBCA-40EF-A284-FBBE262B2295%40gmail.com.

[Alasdair Nottingham]

I’m not sure I follow why it isn’t a problem for the Java EE 7 api jar dependency vs the individual spec ones, but is for the Jakarta EE apis.

I agree having a mix of versions on the classpath isn’t good, but I don’t know why we don’t already have that problem.

Alasdair

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

[Ken Finnigan]

I don't believe we have that problem at present because Java EE 7 and Java EE 8 both have a Maven artifact, for CDI, of javax.enterprise:cdi-api

In this case, Maven is able to choose a specific version of that single artifact, hopefully the Java EE 8 one but you never know.

With most specs moving to Jakarta EE 8, that artifact dependency for CDI is now jakarta.enterprise:jakarta.enterprise.cdi-api

Such a change means we have two completely different artifacts on the classpath, as Maven doesn't know that one is a newer version of the other.

Does that help explain it? Am I off base in this thinking?

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7C8E255D-FBB7-49D2-A9B8-BC58EDF246D5%40gmail.com.

[Alasdair Nottingham]

I think the bit I was missing is that javax:javaee-api:8.0 pom has dependencies on all the component specification apis so if you use it maven should be able to resolve it as you describe.

Alasdair

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4_NKCcF6FE72SvFBYK6VRPM3o8Bpv7ARAM6-47cLCpRw%40mail.gmail.com.

[Emily Jiang]

Back to my vacation and try to catch up with the threads and prep for Jakarta EE8 alignment. Further to Andy's comment on Rest Client, I did a search on all other specs. I found out the highlighted impact is on most MicroProfile specs.

The following specs used to depending on CDI 1.2:

MP Config

MP Health

MP Metrics

MP Open Tracing

MP Rest Client

The following spec depends on Java EE7

MP JWT Auth

=======================

The following specs depends on CDI 2.0: no issue to move to Jakarta EE8

MP Fault Tolerance

The following spec has no dependency on Java EE

MicroProfile Open API.

All of the specs depending on Java EE7 or CDI 1.2 will introduce a break changes as it drops its support on Java EE7. Accroding to the release versioning policy, the changes moving towards Jakarta EE8 will be a major change.

With this, I think we need to reconsider our plan:

Plan A: Just do what Kevin suggested on moving the platform dependencies only

Plan B: Do a major release with a clearer rebase. Since Jakarta EE9 is planned for 2Q, IIRC, this might be ok.

Please think about this. We can discuss more on the MP hangout.

By the ways, the specs in bold should not start their minor releases with the Jakarta EE8 alignment changes.

Thanks

Emily

[Ken Finnigan]

Does this mean that the MicroProfile 2.0 release, and therefore any release since, is completely broken?

MP 2.0 release [1] states that we're targeting Java EE 8 technology, except that all but one spec are still using Java EE 7 dependencies.

But [2] states "When an umbrella specification is released, all included component specs must be interoperable". If MP FT is based on Java EE 8, aren't we then saying that the platform is only interoperable on Java EE 8, therefore Java EE 7 support was removed in MP 2.0?

Irrespective of what [2], or semantic versioning, might define, can we not "make an exception" and release every component spec with Jakarta EE 8 dependencies and update the platform to Jakarta EE 8 in MP 3.3? To my understanding, there are actually no API breaking changes by doing so, the only possible breaking change is removing support for Java EE 8. But for me, MP 2.0 removed direct support for Java EE 7 already

Ken

[1] - https://projects.eclipse.org/projects/technology.microprofile/releases/microprofile-2.0

[2] - https://wiki.eclipse.org/MicroProfile/SpecVersioning

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/3cfe982b-cd6c-4d85-a1b0-14cb1c983dce%40googlegroups.com.

[Emily Jiang]

For MicroProfile 2.0, the platform requires Java EE8. However, most of included specs works with both Java EE7 and Java EE8. In the case of MicroProfile most specs versioned at 1.x, they work with both Java EE7 and Java EE8. If we change the dependency from Java EE7 (CDI 1.2) to Jakarta EE8 (CDI 2.0), this means they no longer work with Java EE7. This is a major change for them, see this wiki on component versions.

MP 2.0 release [1] states that we're targeting Java EE 8 technology, except that all but one spec are still using Java EE 7 dependencies.

Most specs works with both Java EE7 and EE8.

But [2] states "When an umbrella specification is released, all included component specs must be interoperable". If MP FT is based on Java EE 8, aren't we then saying that the platform is only interoperable on Java EE 8, therefore Java EE 7 support was removed in MP 2.0?

Java EE7 is removed from the umbrella release but not from component spec release. The specs such as Config, Health, Metrics, JWT, Rest Client, etc are still using Java EE7 dependencies.

Irrespective of what [2], or semantic versioning, might define, can we not "make an exception" and release every component spec with Jakarta EE 8 dependencies and update the platform to Jakarta EE 8 in MP 3.3? To my understanding, there are actually no API breaking changes by doing so, the only possible breaking change is removing support for Java EE 8. But for me, MP 2.0 removed direct support for Java EE 7 already

This is an exception on dropping Java EE7 support on many specs. We should discuss further on the call. By the way, if we just update the umbrella release to Jakarta EE8 without bothering with the component specs. In this way, we align with Jakarta EE8 from the umbrella release sense without any other exceptions. In June, we can force all specs to move the baseline to Jakarta EE8 and drop Java EE7. I think this might be a workable plan.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/3cfe982b-cd6c-4d85-a1b0-14cb1c983dce%40googlegroups.com.

[Ken Finnigan]

If it was a change from Java EE 8 to Java EE 9, then yes we can just update the platform.

However, moving the platform to Jakarta EE 8 changes the artifacts that are present on the classpath.

I don't see how we can have the platform with Jakarta artifacts and the specs with Javax artifacts without resulting in duplicate classes.

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/4ad33136-c137-42e7-9184-1f7a78f4f1b3%40googlegroups.com.

[Emily Jiang]

The spec jars does not require javax artifacts but only the javax class import, after the jars have been built. At runtime, it will resolve ok against jakarta jars as the imported javax packages exist in the jakarta jars.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4ad33136-c137-42e7-9184-1f7a78f4f1b3%40googlegroups.com.

[Ken Finnigan]

That only applies if every spec has the Java EE dependencies in "provided" scope, correct?

From a quick look, that's not the case as several specs have Java EE / Jakarta EE dependencies in "compile" scope

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/cd443440-e0db-4a5c-ae99-5f94c448e8ec%40googlegroups.com.

[Emily Jiang]

Right. For the specs (I found two) with JavaEE dependencies in "compile" scope, they should do a minor release to change the scope to "provided", as "Provided" is the right thing to do anyway. I think this is managable.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cd443440-e0db-4a5c-ae99-5f94c448e8ec%40googlegroups.com.

[Kevin Sutter]

We had a great discussion on our community hangout today on this topic...  Especially as this relates to our "provided" vs "compile" scope for the Java EE / Jakarta EE dependencies...

One additional observation before we throw the baby out with the bath water...   As I pointed out on the call, our microprofile platform pom does not explicitly state a <scope>.  Thus, this defaults to "compile" scope if no other scope is specified.

But, our documentation and release notes have always indicated to use the "provided" scope when bringing in the microprofile platform dependency:

<dependency>
    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile</artifactId>
    <version>3.2</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>

Thus, if the applications are following this documented convention of using the "provided" scope designation, then there wouldn't be a problem with modifying the platform pom with Jakarta EE 8 dependencies for MP 3.3 (as we thought on the call today).

Some recent experimentation from Martin confirms this "provided" scope as well for these dependencies.

I know we came to a "decision" on the call today, but based on this information, can we revisit this again?  As I mentioned on the call, moving from Java EE 8 to Jakarta EE 8 should be a walk in the park.  If we have messed up our pom's or documentation that prevents this nice walk, then I will concede.  But, based on our documented usage pattern, I think we're okay with moving to Jakarta EE 8 at the Platform level.

Thoughts?

Kevin

[Emily Jiang]

Hi Kevin,

The dependency scope we talked about is for CDI 1.2 and other Java EE7 dependencies such as JAX-RS. For an instance, Health pom.xml has the following:

<dependency>
     <artifactId>javax.inject</artifactId>

<groupId>javax.inject</groupId> <dependency>

The above dependency will default the scope to compile, which means CDI 1.2 jars will end up on its classpath.  If we change the platform to pull in Jakarta jars, there will be Java EE7 and Jakarta EE8 jars on the classpath, which might cause problems. The plan is to update the dependency scope to "Provided", but it is a break change. I know on the call, there was a kind of agreement of "updating scopes is a break change" . I thought it further after the call. I am not sure why updating "Compile" scope to "Provided" scope is a break change. Can someone explain further? Thanks Emily

[Kevin Sutter]

Emily,

Once the user applies the "provided" scope to the top level platform MP pom, then it looks like it gets propagated to the dependency tree...  Take a look at Martin's post that I referenced.  It's my understanding that Martin's app was a simple app just to pull in the top level pom with the "provided" scope...

[INFO] \- org.eclipse.microprofile:microprofile:pom:3.2:provided

[INFO]    +- javax.enterprise:cdi-api:jar:2.0:provided

[INFO]    |  +- javax.el:javax.el-api:jar:3.0.0:provided

[INFO]    |  +- javax.interceptor:javax.interceptor-api:jar:1.2:provided

[INFO]    |  \- javax.inject:javax.inject:jar:1:provided

[INFO]    +- javax.ws.rs:javax.ws.rs-api:jar:2.1:provided

[INFO]    +- javax.json.bind:javax.json.bind-api:jar:1.0:provided

[INFO]    +- javax.json:javax.json-api:jar:1.1:provided

[INFO]    +- javax.annotation:javax.annotation-api:jar:1.3:provided

[INFO]    +- org.eclipse.microprofile.config:microprofile-config-api:jar:1.3:provided

[INFO]    |  \- org.osgi:org.osgi.annotation.versioning:jar:1.0.0:provided

[INFO]    +- org.eclipse.microprofile.fault-tolerance:microprofile-fault-tolerance-api:jar:2.0:provided

[INFO]    +- org.eclipse.microprofile.health:microprofile-health-api:jar:2.1:provided

[INFO]    +- org.eclipse.microprofile.metrics:microprofile-metrics-api:jar:2.2:provided

[INFO]    +- org.eclipse.microprofile.jwt:microprofile-jwt-auth-api:jar:1.1:provided

[INFO]    +- org.eclipse.microprofile.openapi:microprofile-openapi-api:jar:1.1:provided

[INFO]    +- org.eclipse.microprofile.rest.client:microprofile-rest-client-api:jar:1.3:provided

Now, of course, if you just go to our source directory at the top-level and invoke "mvn dependency:tree" it will show the "compile" scope because that's the default.  But, when you pull in our top-level pom with the "provided" scope, then it looks like we're okay...

-- Kevin

[Martin Stefanko]

Hi all,

the definitions:

- compile: This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.

- provided: This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.

So why is the addition of provided scope a breaking change? Take for instance a simple project which has only a dependency on org.eclipse.microprofile.health:microprofile-health-api:2.1 - https://github.com/xstefank/mp-health-dependencies. The project contains one class called POJO which uses @Inject annotation (wouldn't work, but it's sufficient for demonstration). `mvn dependency:tree` on this project:

[INFO] io.xstefank.mp:mp-health-dependencies:jar:1.0-SNAPSHOT

[INFO] \- org.eclipse.microprofile.health:microprofile-health-api:jar:2.1:compile

[INFO]    +- javax.inject:javax.inject:jar:1:compile

[INFO]    \- org.osgi:org.osgi.annotation.versioning:jar:1.0.0:compile

so the dependencies are in compile scope and we can run `mvn clean package` successfully.

Now I took the same MP Health 2.1 dependency with the following change - https://github.com/xstefank/microprofile-health/commit/22c74248c73618faf19bfda394500fa0995be3b8

Now the `mvn dependency:tree`:

[INFO] io.xstefank.mp:mp-health-dependencies:jar:1.0-SNAPSHOT

[INFO] \- org.eclipse.microprofile.health:microprofile-health-api:jar:2.1:compile

[INFO]    \- org.osgi:org.osgi.annotation.versioning:jar:1.0.0:compile

Note the missing javax.inject:javax.inject dependency. And `mvn clean package` fails as the Inject annotation can't be found and thus this is a breaking change.

Hope this helps.

Martin

[Emily Jiang]

Martin,

Now the `mvn dependency:tree`:

[INFO] io.xstefank.mp:mp-health-dependencies:jar:1.0-SNAPSHOT

[INFO] \- org.eclipse.microprofile.health:microprofile-health-api:jar:2.1:compile

[INFO]    \- org.osgi:org.osgi.annotation.versioning:jar:1.0.0:compile

Note the missing javax.inject:javax.inject dependency. And `mvn clean package` fails as the Inject annotation can't be found and thus this is a breaking change.

In your app, you demonstrated just using mp health jar standalone without any app server presence. I don't think anyone will use these jars without any app server presence. I don't think it is a real use case.

My agrument is that the microprofile jars are not used in isolated. They are packaged in app servers, which provides the CDI jars. Besides the umbrella release pulls in the dependencies any way.

Thanks

Emily

[Martin Stefanko]

Hi Emily,

not necessarily. Not all servers/runtimes package themselves together with the app (for instance WildFly). So if you can't compile you can't deploy.

Thanks,

Martin

To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/microprofile/3cfe982b-cd6c-4d85-a1b0-14cb1c983dce%40googlegroups.com?utm_medium=email&utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/msgid/microprofile/3cfe982b-cd6c-4d85-a1b0-14cb1c983dce%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" onclick="this.href='https://groups.google.com/d/msgid/microprofile/3cfe982b-cd6c-4d85-a1b0-14cb1c983dce%40googlegroups.com?utm_medium\x3demail\x2

[Emily Jiang]

Well... Are you saying that once you have changed the scope to "Provided", the apps cannot work any more on Wildfly? In this case, how do other MP api work on Wildfly?

Thanks

Emily

To view this discussion on the web visit <a href="<a href="https://groups.google.com/d/msgid/microprofile/3cfe982b-cd6c-4d85-a1b

[Martin Stefanko]

No, I am saying that the jar cannot be built. Wildfly isn't the only runtime that is not bundled within the application. Meaning the users build the jar/war themselves. So if the user needs to build the deployment externally and then deploy it to the server then there is nothing that the server can do. But of course, this is an extreme example. It was just a demonstration to show that the change to provided scope may break apps that rely on it. 

Martin

</blockqu

[Ken Finnigan]

Sometimes it's annoying being in another time zone, so much going on!

With respect to the discussion between Emily/Martin around compile vs provided scopes. The issue is not about what might be present in an implementation by virtue of where it's deployed, such as an application server. The issue is that if a developer has a dependency in their project that transitively brings in APIs that they use for compilation, not execution, then if those dependencies are made provided their application will no longer compile without "changes" by the developer to re-add the now provided dependencies.

This is the reason that switching from compile to provided scopes on our spec API dependencies is a breaking change.

With respect to Kevin's proposal about the documentation indicating that "provided" should be used on the MP platform pom, and Martin's validation that the dependencies are then in a provided scope. I have confirmed that is the case, however, if a specific dependency on a spec is present within the project any transitives for base specs are then included in the scope that the spec defines and not "provided" from the platform pom dependency.

For instance, this means that an MP REST Client dependency converts javax.inject into a compile dependency from a provided one, even though the MP platform pom is imported as provided.

In addition, if the user chose to use the pom in dependencyManagement with "import" scope, which doesn't auto add all MP pom dependencies to the project, adding a dependency brings it in with compile scope, unless the user specifies otherwise.

With the two above issues with the usage of the MP platform pom, and relying on users having followed documentation to the letter to not have an issue, I still see our best option as delaying Jakarta EE 8 API updates for specs and platform until MP 4.0 in June.

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/f3479ced-764a-44f4-9bf0-96c2ed3e0b20%40googlegroups.com.

[Kevin Sutter]

Ken,

Thanks for the pulling the discussion back on track...  Although I appreciate the scenarios you described, they do seem to be edge cases.  In both cases, if the user defines the dependencies with provided scope as documented, then there is no issue.  When I ran this idea by John, he asked "who reads documentation?", which is a fair point.  When I googled this scenario, the only example I found that didn't show the use of "provided" scope was with some project called Thorntail.  What's Thorntail?  ;-)

Seriously, I just wanted to bring up this documented usage pattern to see if it would sway some thinking.  Personally, I still think we're making a mountain out of a mole hill.  We could move to Jakarta EE 8 dependencies at the Platform level for MP 3.3 and then do the major cleanup for MP 4.0 in June.  But, if that's not the desire of the community, then I'm okay with that.

-- Kevin

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

[Kevin Sutter]

I cleaned up my draft PR to exclude EJB and EL from the CDI dependency (per the earlier discussions).  I think this is now pretty clean for the Jakarta EE dependencies.

I'm actually thinking of creating an RC1 so that people could actually try this out.  If there are testing issues with this approach, then let's stop discussing it.  But, my guess is that our test efforts will be clean and we could go ahead with Jakarta EE 8 at the platform level.

I have to ask...  I thought MicroProfile was supposed to be innovative.  And, we might have some rough edges along the way.  This proposed change seems relatively benign for almost all of our usage scenarios.  Why the hesitancy?  And, also to be clear...  I am not pushing this idea due to something we're doing at IBM.  TBH, virtually nobody at IBM even knows that I am pushing this envelope -- except for Emily and Alasdair that are already chiming in on this thread.  Whether we do this or not for MP 3.3 has no consequence on our Open Liberty development efforts (except for the normal work required to support the new releases).  This is just a personal wild hair on my part...  :-)

-- Kevin

[Ken Finnigan]

If the change was a "slam dunk", I'd be all for it.

However, what you refer to as "edge cases" are actually problems that we know will occur if users haven't followed the documentation "to the letter". If we know there's the possibility of problems, wouldn't it be remiss of us to knowingly release it into the community?

--

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/a6f0fa91-e2ce-4a45-a149-3a2362ca9203%40googlegroups.com.

[Ladislav Thon]

Hey,

st 8. 1. 2020 v 15:36 odesílatel Kevin Sutter <kwsu...@gmail.com> napsal:

Ken,

Thanks for the pulling the discussion back on track...  Although I appreciate the scenarios you described, they do seem to be edge cases.  In both cases, if the user defines the dependencies with provided scope as documented, then there is no issue.  When I ran this idea by John, he asked "who reads documentation?", which is a fair point.  When I googled this scenario, the only example I found that didn't show the use of "provided" scope was with some project called Thorntail.  What's Thorntail?  ;-)

current Thorntail lead here. I think we would both agree that we would want to have a penny for each user who doesn't read documentation, right? ;-)

LT

 

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/f3479ced-764a-44f4-9bf0-96c2ed3e0b20%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/c45a9388-2226-41c5-b287-41a302a4b070%40googlegroups.com.

[John Clingan]

We should check StackOverflow to see what developers are copying and pasting, LOL :-)

[Martin Stefanko]

I've updated the milestone to include only specifications that plan feature releases - https://github.com/eclipse/microprofile/milestone/4. Please feel free to update the milestone if I missed something.

Martin