Jaxrs-api: Deliver jaxrs-api Specification Version update for Jakarta EE 9

[kwsutter]

Is your feature request related to a problem? Please describe.
Jakarta EE 9 is the next major release, with the main focus of moving from the javax namespace to the jakarta namespace.

Describe the solution you'd like
This issue will be used to track the progress of this work effort via the Jakarta EE 9 Project board.

Additional context
Jakarta EE Specification Process
Eclipse Project Handbook
Eclipse Release Record for Jakarta EE 9

ToDo

• [x] Create Eclipse Release Record in your respective Jakarta Specification Project.
  Most Component Release Records will just reference the Jakarta EE 9 Platform Release Plan. But, if your Component deviates at all from the Platform Release Plan, then a description of the changes will be required in the Release Record.
• [x] Initiate a ballot for your Jakarta Release Record/Plan.
  Again, if your component is only doing the required minimum as defined by the Jakarta EE 9 Platform Release Plan, then no separate ballot is required. You are already approved. But, if your component deviates from the Platform Release Plan, then you will need to initiate your own ballot as defined by the Jakarta EE Specification Process.
• [x] Jakarta-ize your Specification document (if applicable)
  Many of the Jakarta EE components now have the source for their Specification documents. It is strongly recommended that these Specification documents are properly updated to represent Jakarta EE instead of Java EE. Some helpful instructions are documented here.
• [x] javax -> jakarta Spec updates
  If your component has Specification source, then all javax package references need to be updated to use jakarta package references.
• [x] javax -> jakarta API updates
  Your component APIs need to move from using the javax namespace to using the jakarta namespace.
• [x] Release Candidate (RC) of Jakarta API in Maven Central
  A Release Candidate of your component API should be pushed to Maven Central as soon as humanly possible. This will allow other dependent components to utilize your APIs as they are updating their APIs. Multiple revisions of these Release Candidate APIs are allowed (and probably expected) during the development cycle.
• [x] javax -> jakarta TCK updates
  Your component TCK needs to be updated to use the jakarta namespace.
• [x] javax -> jakarta Compatible Implementation updates
  Your compatible implementation that will be used to demonstrate completeness of the Specification needs to be updated to use the jakarta namespace.
• [x] Final Jakarta API available in Staging Repo
  When ready, your final version of the API needs to be staged to get ready for the PR review and approvals.
• [x] Draft Specification and Apidoc PRs ready for review
  Like we did for Jakarta EE 8, draft PRs need to be created and reviewed in preparation for the final ballots.
• [x] Release Review Ballot started
  Each Jakarta EE component will need to initiate a separate Release Review ballot after proper reviewing has completed. To be clear, there will not be a blanket Release Review for all of Jakarta EE 9 like we did for the Plan Review. Each component needs a separate Release Review.

[kwsutter]

Can I ask this team to please create and assign the following labels to this Issue? Thank you!
[wave:4]

[andymc12]

@kwsutter FYI, Santiago created the JAX-RS 3.0 release record for Jakarta EE 9.

We should not need a separate ballot since the 3.0 release only includes the package namespace change.

[chkal]

@mkarg I guess "javax -> jakarta API updates" has been fixed by #761 you created, correct? Or is there anything still missing for that?

[mkarg]

@chkal Yes, I just checked this bullet as fixed. :-)

[andymc12]

Hi All - two of our dependencies (Jakarta Activation and JAXB) have published release candidates that include the javax.* to jakarta.* package rename. I have been working on pulling them in, but there is a catch...

We use the JAXB RI for unit testing, but the JAXB RI does not have a published release that includes the package rename. I may be able to help expedite getting a JAXB RI with the rename - but before I do that I was wondering if anybody objected to us temporarily commenting out the tests that require the RI. What do you all think?

[chkal]

We use the JAXB RI for unit testing, but the JAXB RI does not have a published release that includes the package rename. I may be able to help expedite getting a JAXB RI with the rename - but before I do that I was wondering if anybody objected to us temporarily commenting out the tests that require the RI. What do you all think?

Any idea when the RI is planning to release a first version supporting the new namespace?

To be honest, I don't like the idea of disabling tests just because we want to update the API version so early. We are in wave 4 and JAXB is in wave 2. Why not wait for wave 2 to finish the releases before we do the update of our dependencies?

Of course, we can prepare a pull request NOW, but let's wait for all our dependencies to be available.

Just my 2 cents. :-)

[mkarg]

Let's just wait for wave 2 to be over. No need to hurry.

-Markus

Von: Christian Kaltepoth [mailto:[email protected]]
Gesendet: Samstag, 15. Februar 2020 11:39
An: eclipse-ee4j/jaxrs-api
Cc: Markus KARG; Mention
Betreff: Re: [eclipse-ee4j/jaxrs-api] Deliver jaxrs-api Specification Version update for Jakarta EE 9 (#832)

We use the JAXB RI for unit testing, but the JAXB RI does not have a published release that includes the package rename. I may be able to help expedite getting a JAXB RI with the rename - but before I do that I was wondering if anybody objected to us temporarily commenting out the tests that require the RI. What do you all think?

Any idea when the RI is planning to release a first version supporting the new namespace?

To be honest, I don't like the idea of disabling tests just because we want to update the API version so early. We are in wave 4 and JAXB is in wave 2. Why not wait for wave 2 to finish the releases before we do the update of our dependencies?

Of course, we can prepare a pull request NOW, but let's wait for all our dependencies to be available.

Just my 2 cents. :-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/jaxrs-api/issues/832?email_source=notifications&email_token=AAM7PN22DXEZUE57POOOA43RC7A5XA5CNFSM4KGUGLZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3HI4Q#issuecomment-586577010 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM7PN4YIIGZMWGUXLTZK3LRC7A5XANCNFSM4KGUGLZQ . https://github.com/notifications/beacon/AAM7PN2ESPSZBISBF4KILKLRC7A5XA5CNFSM4KGUGLZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3HI4Q.gif

[andymc12]

@chkal @mkarg Thanks for the response - and I agree that we should not disable tests if we don't have to. I don't think the RI has a release date for the javax-to-jakarta conversion. I will go ahead and plan to help them move forward with publishing a jakarta-ified release.

[kwsutter]

Since the javax->jakarta package rename has completed, what is holding up the delivery of a Milestone or RC driver of the API jar file? I realize some components are not comfortable with delivering an RC until the tests have passed. And, it sounds like you have a dependency on the RI, which may need to wait. But, how about a Milestone driver published to Maven with the API updates? It would be great to get the APIs all updated and available in some form in Maven for other projects' usage (both internal and external to EE4J). Thanks!

[mkarg]

Kevin,

you find that here already: https://repo.eclipse.org/content/repositories/snapshots/jakarta/ws/rs/jakarta.ws.rs-api/3.0-SNAPSHOT/ and here is how to use it: https://github.com/eclipse-ee4j/jaxrs-api/wiki/Nightly-Builds.

That is the repo inteded by the EF for exactly such use cases. It is a good thing if Jakarta also uses it, too. Instructions how to do use the EF's infrastructure manual are found here: https://wiki.eclipse.org/Services/Nexus#Snapshots_Group.

We do not want to clutter The Central Repository (what you call "Maven" below) with pre-releases, as this is not what The Central Repository is intended for.

Have fun testing it! :-)

Regards

-Markus

Von: Kevin Sutter [mailto:[email protected]]
Gesendet: Montag, 17. Februar 2020 17:53
An: eclipse-ee4j/jaxrs-api
Cc: Markus KARG; Mention
Betreff: Re: [eclipse-ee4j/jaxrs-api] Deliver jaxrs-api Specification Version update for Jakarta EE 9 (#832)

Since the javax->jakarta package rename has completed, what is holding up the delivery of a Milestone or RC driver of the API jar file? I realize some components are not comfortable with delivering an RC until the tests have passed. And, it sounds like you have a dependency on the RI, which may need to wait. But, how about a Milestone driver published to Maven with the API updates? It would be great to get the APIs all updated and available in some form in Maven for other projects' usage (both internal and external to EE4J). Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/jaxrs-api/issues/832?email_source=notifications&email_token=AAM7PN7J45QYJZS6HLF4YTLRDK6IJA5CNFSM4KGUGLZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7CSEI#issuecomment-587082001 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM7PN2MPOEYR3RSTFWNXOTRDK6IJANCNFSM4KGUGLZQ . https://github.com/notifications/beacon/AAM7PN2T7KU3BWOA3JOCKH3RDK6IJA5CNFSM4KGUGLZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7CSEI.gif

[kwsutter]

@mkarg, thanks for the pointer. But, we're looking for more than just a SNAPSHOT build. Most of the other Jakarta EE projects have already posted their Milestone or RC driver. There are just a few stragglers which are being worked. Sure would be nice to get JAX-RS posted as well. Thanks!
https://github.com/orgs/eclipse-ee4j/projects/17#column-7346435

Having some type of designated Milestone/RC driver that indicates you are ready with the API changes has proven useful thus far with Jakarta EE 9. A SNAPSHOT driver has no meaning behind it as to the content. We have external tooling teams (IDEs, runtimes, etc) that are looking to get access to these early API jar files (as well as our internal EE4J teams). If your API jar file is ready, please post it to the Central Repo for our combined usage. Thank you.

-- Kevin

[andymc12]

We do not want to clutter The Central Repository (what you call "Maven" below) with pre-releases, as this is not what The Central Repository is intended for.

Who is "we"? Have we (the JAX-RS committers) discussed this before? If all the rest of the Jakarta EE sub-projects are producing milestone/RC releases, why would we want to be different?

[mkarg]

We do not want to clutter The Central Repository (what you call "Maven" below) with pre-releases, as this is not what The Central Repository is intended for.

Who is "we"? Have we (the JAX-RS committers) discussed this before? If all the rest of the Jakarta EE sub-projects are producing milestone/RC releases, why would we want to be different?

"We" is the people that acted so far. Feel free to discuss this and then act differently. :-)

[spericas]

@kwsutter When the initial plan was announced with the waves, it was not clear (at least to me) that we would need to produce an RC version around this time since JAX-RS was in wave 4. Last week I did see the email about the Feb 14th deadline, but it was a bit late and I didn’t think we were ready. So I updated this page instead:

https://docs.google.com/spreadsheets/d/1EN5UEzxFV1Buk7yqdQAweaynWJ3UNn2BjN7blXn9vh4/edit#gid=0

with some new dates and I was going to bring this up this week. My apologies for the confusion and missing that deadline. Hope producing an RC before the end of the month would help.

[spericas]

Is there anything pending to mark as complete step "Jakarta-ize your Specification document (if applicable)"?

[mkarg]

Is there anything pending to mark as complete step "Jakarta-ize your Specification document (if applicable)"?

Please find the open items in https://github.com/eclipse-ee4j/jaxrs-api/issues/804.

[spericas]

Hi All - two of our dependencies (Jakarta Activation and JAXB) have published release candidates that include the javax.* to jakarta.* package rename. I have been working on pulling them in, but there is a catch...

We use the JAXB RI for unit testing, but the JAXB RI does not have a published release that includes the package rename. I may be able to help expedite getting a JAXB RI with the rename - but before I do that I was wondering if anybody objected to us temporarily commenting out the tests that require the RI. What do you all think?

We should add @Ignore to JaxbLinkTest.java in order to get the release going. #845 requires a few other changes: (1) Update Javadoc change in Link.java and (2) An update of pom.xml and ResourceExample.java in example.

[spericas]

@andymc12 Related to #845, shouldn't our API jar use 3.0.0-SNAPSHOT instead of 3.0-SNAPSHOT?

[kwsutter]

@kwsutter When the initial plan was announced with the waves, it was not clear (at least to me) that we would need to produce an RC version around this time since JAX-RS was in wave 4.

The waves were more for the "final" Spec and API releases since those are more critical to get in the proper order. Since some of the projects produced Milestone/RC API artifacts without full testing, the waves could come in any order for the APIs. Thus, we pushed for APIs first and then the next steps are to deliver the Specs, final APIs, TCKs, and CIs.

Last week I did see the email about the Feb 14th deadline, but it was a bit late and I didn’t think we were ready. So I updated this page instead: https://docs.google.com/spreadsheets/d/1EN5UEzxFV1Buk7yqdQAweaynWJ3UNn2BjN7blXn9vh4/edit#gid=0 with some new dates and I was going to bring this up this week.

Sorry for the confusion. I've been trying to communicate the various goals through various channels (mailing lists, platform calls, spec committee calls, and slack/verbal when available). But, even with that, I know that things can fall through the cracks. We're making good, solid progress on the API artifacts, so I'm still feeling good about the state of the Jakarta EE 9 effort.

My apologies for the confusion and missing that deadline. Hope producing an RC before the end of the month would help.

I think @andymc12 was going to try to do a Milestone API before then, but pushing for a fully-tested RC by the end of the month would be great as well. There are only a couple of outstanding API jars, so it would be good knock these off in short order. Thanks for your help!

[kwsutter]

So I updated this page instead: https://docs.google.com/spreadsheets/d/1EN5UEzxFV1Buk7yqdQAweaynWJ3UNn2BjN7blXn9vh4/edit#gid=0 with some new dates

BTW, that spreadsheet is no longer being tracked. We are using this project board instead. Much more public, easier to maintain, and easier to track the progress. Thanks!

https://github.com/orgs/eclipse-ee4j/projects/17

[andymc12]

The M1 milestone release is now available at Maven Central at https://repo.maven.apache.org/maven2/jakarta/ws/rs/jakarta.ws.rs-api/3.0.0-M1/

Projects that depend on JAX-RS in the new package namespace can use this Maven dependency:

<dependency>
    <groupId>jakarta.ws.rs</groupId>
    <artifactId>jakarta.ws.rs-api</artifactId>
    <version>3.0.0-M1</version>
</dependency>

[mkarg]

The M1 milestone release is now available at Maven Central at https://repo.maven.apache.org/maven2/jakarta/ws/rs/jakarta.ws.rs-api/3.0.0-M1/

I do appreciate this, but I wonder if we did a mistake in the EF's process rules. AFAIK we have to vote upon _each_ public release, so all committers have the chance to veto (because you cannot remove anything from Maven Central). As it is the project lead's role to guard these rules, I'd like @spericas to check this and teach us in case we did it wrong. Maybe @waynebeaton can comment, too, just for safety. Thanks.

[spericas]

The M1 milestone release is now available at Maven Central at https://repo.maven.apache.org/maven2/jakarta/ws/rs/jakarta.ws.rs-api/3.0.0-M1/

I do appreciate this, but I wonder if we did a mistake in the EF's process rules. AFAIK we have to vote upon _each_ public release, so all committers have the chance to veto (because you cannot remove anything from Maven Central). As it is the project lead's role to guard these rules, I'd like @spericas to check this and teach us in case we did it wrong. Maybe @waynebeaton can comment, too, just for safety. Thanks.

@mkarg We have been asked to produce an RC/M release for weeks for the purpose of integration with other Jakarta EE 9 technologies. Everyone here knew about this _non-final_ release coming, and several people (excluding you) have been voting in favor of it. This release should not be a surprise to anyone. Again, this is an integration release and not the final release for Jakarta EE 9.

[spericas]

The M1 milestone release is now available at Maven Central at https://repo.maven.apache.org/maven2/jakarta/ws/rs/jakarta.ws.rs-api/3.0.0-M1/

Projects that depend on JAX-RS in the new package namespace can use this Maven dependency:

<dependency>
    <groupId>jakarta.ws.rs</groupId>
    <artifactId>jakarta.ws.rs-api</artifactId>
    <version>3.0.0-M1</version>
</dependency>

Thanks @andymc12 !

[mkarg]

We have been asked to produce an RC/M release for weeks for the purpose of integration with other Jakarta EE 9 technologies. Everyone here knew about this _non-final_ release coming, and several people (excluding you) have been voting in favor of it. This release should not be a surprise to anyone. Again, this is an integration release and not the final release for Jakarta EE 9.

Nobody is surprised. My question is, whether there was an open voting among the committers. Maybe I simply missed or forgot it. You say we had a voting? Do you have a pointer to that?

[andymc12]

@mkarg - we discussed it in PR #850. You abstained, but we had 3 committers vote +1. HTH

[mkarg]

@mkarg - we discussed it in PR #850. You abstained, but we had 3 committers vote +1. HTH

Thanks for the summary. As I said, maybe it's just me having amnesia. ;-)

Maybe we could clearly mark those MR that effectively will trigger the release with some special label (like "release"), to separate them from those just setting the version in the POM. Or we could agree that MR's titled "Release" to be the official votings (so we can tell this rule in our Wiki)?

[andymc12]

I’d be fine with adding a “release” label.

[kwsutter]

@spericas Just assigned this Issue to you as Assignee... There were several of these Epic Issues without having a central contact for questions. If you would rather assign someone else, feel free to do so. You just drew the short straw.. :-)

[spericas]

@kwsutter NP. I'm sure this info is elsewhere, but would it be possible to update this issue with the relevant dates to deliver the spec, TCKs, etc.?

[kwsutter]

@spericas This Epic can be used in any way your team wishes. I'm tracking progress by the Checklist, but if you wish to include dates, etc, that's fine with me. FYI, overall, we are not tracking to the release dates very well... You can see the original dates as outlined in the Project Board. We are working with the Steering Committee to possibly adjust these expectations.

Question for you or the wider team... I see in the Checklist that the javax->jakarta namespace change is complete for the Specification. I would assume that the basic "Jakarta-izing" of the Specification source is also completed? If there is some reason that Checkbox isn't checked, let me know. Thanks.

[spericas]

@kwsutter Good question about the checkbox. I think it should be checked, but others feel free to correct that if I'm missing something.

[mkarg]

@kwsutter @spericas The problem is that there is no clear definition of "complete" wrt. Jakarta-izing. I would say, we're fine since long time, but legals might say, we missed a detail. IANAL, so I tried to get a clear set of rules and were provided with this list https://github.com/eclipse-ee4j/jaxrs-api/issues/804 by @ivargrimstad. Unfortunately he himself did not want to confirm, that this list is legally comprehensive.

So I would say, we're done. But maybe it is best if the guys that requested these changes simply check the latest nightly build of the PDF to decide on their own?

[spericas]

This version of Jersey already uses our API version 3.0.0-M1. Will be updated to use the final bits from staging when they become available (https://projects.eclipse.org/projects/ee4j.jersey/releases/3.0.0-m6).

[spericas]

https://github.com/eclipse-ee4j/jakartaee-tck/issues/457

[spericas]

https://jakarta.oss.sonatype.org/content/repositories/staging/jakarta/ws/rs/jakarta.ws.rs-api/3.0.0/

[arjantijms]

https://repo1.maven.org/maven2/jakarta/ws/rs/jakarta.ws.rs-api/3.0.0/

[arjantijms]

@kwsutter I think we can close this now?

[mkarg]

@arjantijms There are the following bugs open, so @kwsutter should decide if we close this issue with open bugs, or if the bugs have to get fixed before:

• https://jakarta.ee/specifications/restful-ws/3.0/jakarta-restful-ws-spec-3.0.html - It says released September 23rd, but it was released in November. The spec committee must decide what the release date is: The finish of the ballot or the uploading to Maven Central?
• https://jakarta.ee/specifications/restful-ws/3.0/ - The result of the ballot is not published.
• https://jakarta.ee/specifications/restful-ws/3.0/ - Eclipse Jersey 3.0.0 is told to compatible, but it is neither published nor certified yet.

@kwsutter You opinion please!

[mkarg]

Anybody having an opinion here besides me...?

[chkal]

A few thoughts:

• The release record states that the release date is November 5, 2020. I agree that having a completely different date in the spec document is weird. We should definitely find a way to be more consistent regarding this for the next release.
• The release ballot results are now available here
• Regarding Jersey: It looks like we have a completed certification request for 3.0.0-R2 and this version is also in Maven Central. For Jersey 3.0.0 the release review was successful, but this version was not officially release yet (neither on the official homepage nor on Maven Central). There is also no certification request yet.

To sum up: Currently the overall release process is very confusing, especially regarding how the different steps are synchronized between the spec and the corresponding compatible implementation.

[arjantijms]

The release record states that the release date is November 5, 2020. I agree that having a completely different date in the spec document is weird. We should definitely find a way to be more consistent regarding this for the next release.

I've been somewhat "annoyed" (not the exact right word, but you know what I mean), by that as well.

It's not exactly our fault. The problem is that the documents have a given date that's inserted automatically at the time the document is generated. This document is then put up for ballot, and when it passes, everyone is happy and starts the Eclipse release process, with a release record date typically somewhat after the first moment that the EMO does its reviews. If that passes, the jars which were previously under ballot are released to Maven central.

This entire process makes it hard to impossible to have a single date.

[mkarg]

If the fault is the automatic date, then the template simply must changed to include a static date.

[chkal]

Looks like the date is basically the build timestamp:

https://github.com/eclipse-ee4j/jaxrs-api/blob/3c4941be798aba7986916b26e3f17e5b6c4ef85a/jaxrs-spec/pom.xml#L37

TBH: I'm not 100% sure if I like that or not. It will never match the release date from the release record. But on the other hand it is the "creation date of the release artifact", which somehow makes sense to me.

[arjantijms]

Since this is done, let's close the issue.