Jaxrs-api: Release to OSSRH staging repository

[m0mus]

The previous 2.1.2 release didn't uptake the new Eclipse dependencies. It's been released to public, so there is no way of changing it. The new release (2.1.3) is needed. Please release it to OSSRH staging only. Don't deploy it to Maven Central until everything is tested.

• [x] Uptake new Eclipse versions of dependencies (if any). Use GlassFish 5.1 Release Tracker wiki to find components versions to use (see #692).

• [x] Release to OSSRH staging repository

• [x] Update GlassFish 5.1 Release Tracker with released version number.

[spericas]

We should fix the OSGi issues as well #686.

[mkarg]

Guys, just as an good advice from a long-time Github user: Try to open one issue per problem. This makes it easier to manage the parallel work on all of them. :-) We now have two issues open both with a collection of problems inside it. Nobody knows who is working on which item. :-(

[mkarg]

@m0mus This big-bang-approach won't work outside Oracle. To be able to build against Jakarta dependencies, these dependencies MUST be available on Github: Travis CI will fail otherwise, in turn blocking the PR on Github, so we cannot merge it into JAX-RS 2.1.3. So the right way is to not stop the world, but to bootstrap the dependencies bottom-up on Maven Central or on Eclipse Nexus. Note that not all projects pull dependencies from OSSRH staging because the EF wants us to use Eclipse Nexus for this purpose.

@bravehorsie When can we expect to have a public release of JAXB available to committers outside Oracle?

@bshannon When can we expect to have a public release of JAF available to committers outside Oracle?

[bshannon]

Markus KARG wrote on 10/30/2018 11:17 AM:
>

Note that not all projects pull dependencies from OSSRH staging because the EF
wants us to use Eclipse Nexus for this purpose.

Can you point to this statement from Eclipse and instructions for how to
implement what they want?

@bshannon https://github.com/bshannon When can we expect to have a public
release of JAF available to committers outside Oracle?
As soon as I figure out how to do a release properly.  I currently have it
staged at OSSRH (I think), but if something else is required I need to know what
to do.

[mkarg]

@bshannon I doubt there is a written official statement of the EF regarding this. @gaelblondelle told me in Summer the EF tries to have everything on their own infrastructure "just in case", and @fredg02 proposed in some other discussion we shall use Eclipse Nexus to allow the Jakarta projects to depend on each other's nightly builds (staging is roughtly a special form of a nightly build).

Okay, so if it is available on OSSRH staging then I will try to convince Maven to pull dependencies from there. Can you please share the repository URL? I assume I have to explicitly tell it to Maven because OSSRH staging areas are not automatically discovered.

[jansupol]

@mkarg Let's wait on the @chkal 's PR #686 to finish. Let's wait for JAX-B and JAF to be released. If any work still will need to be done, I'll help with the PR/OSGi and then you will use the release job of yours. Sounds good?

[jansupol]

@mkarg I do not think we need to use staging repo, JAF is used in so many projects, sooner or later it gets released. We need to wait for JAXB API anyway

[bshannon]

Markus KARG wrote on 10/30/2018 12:13 PM:

Okay, so if it is available on OSSRH staging then I will try to convince Maven
to pull dependencies from there. Can you please share the repository URL? I
assume I have to explicitly tell it to Maven because OSSRH staging areas are
not automatically discovered.
My understanding is that, assuming you're using the EE4J parent pom, you just
need to build using the "staging" profile and that will allow the build to used
staged artifacts.

(I haven't verified this myself yet, although I wrote a wiki page explaining how
this should work but I'm waiting for the moderator to approve it.)

[mkarg]

@jansupol I will just wait for anybody fixing the OSGi stuff, and JAF and JAXB being released somewhere (either OSSRH or Maven Nexus) and file a PR for that pom change then. After that I will initiaite 2.1.3 release.

@bshannon Unfortunately this is not the case, as each project has its own staging area with different access rights. I just checked the list Sonatype provided me, and I only can see JAX-RS's staging areas. So unless you either release to Maven Central or stage on Eclipse Nexus or grant me read access to JAF's OSSRH staging areas, I cannot download your artifacts.

[chkal]

Unfortunately this is not the case, as each project has _its own_ staging area with different access rights.

I think @bshannon is refering to this entry in the EE4J parent pom.

https://github.com/eclipse-ee4j/ee4j/blob/20c7b207dccbcaf2bd4e5fb743f4db8fe129c07a/parent/pom.xml#L251-L263

[m0mus]

@mkarg

GlassFish is a big project consuming most (all) of EE4J projects. All components are tied together. Here is the dependencies graph. It makes sense to use the same staging infrastructure for all components. I respect the independence of projects, but they are a part of a bigger project, so some common rules are required.

All components are available on GitHub and they will be released to OSSRH staging repository. They will be released to Maven Central after integration between components is completed, all tests are passed and Eclipse release review is completed. It will help avoiding the situation we have with JAX-RS, which was released too early.

JAXB and JAF will be released this week.

[mkarg]

@m0mus I understand your view, but see, Jakarta != GlassFish. Some of us care for GlassFish, others do not. So no, JAX-RS is not part of a bigger project "GlassFish", it is just part of a bigger project "Jakarta" and for that one we do not need neither synchronized releases nor shared staging. GlassFish is just any consumer of JAX-RS. There are others that can use 2.1.2 without problem, and I will not withhold 2.1.x from them just because GlassFish release is then easier to manage. You need to accept that you personally cannot dictate that OSSRH must be used just because it makes your personal work easier or just because the GlassFish team doesn't want to use the EF's Nexus. In fact, JAX-RS was not released too early, there is no "situation", JAX-RS will simply release a 2.1.3, 2.1.4, 2.1.x... JAX-RS could even decide to not support OSGi anymore! The correct way to reach what you want is to simply update the dependencies version numbers until you reach a stable state. Bottom-up. Not top-down.

[bshannon]

@mkarg I think one of us is confused, or means something different when we talk about staging.
I successfully deployed JAF to the OSSRH staging repository. I can access it from other projects
by (e.g.) using the "staging" profile in the ee4j parent pom.

We want to get all components to at least this state, of being deployed to the OSSRH staging
repository. That allows the components to be integrated into GlassFish and tested with the CTS
before being released.

If a component wants to go further and fully release an updated version, that's fine. Of course,
any such release needs to be tested with the component TCK. And if the component fails when
integrated into GlassFish, further updates and releases may be required.

The relationship between GlassFish and its components is neither top-down nor bottom-up,
but rather is more cooperative and collaborative. We assume the JAX-RS Project Leads will
ensure JAX-RS evolves with that in mind.

[spericas]

@mkarg GlassFish is a very important part of Jakarta EE and we should work together in JAX-RS to deliver it into GlassFish. As stated by @bshannon, this should be a cooperative and collaborative effort, while at the same time providing independence to each individual project.

[chkal]

Just to make sure I understand this correctly. So the JAF release currently in release review will be kept in the staging repository for now and will not be released to Maven central in the next days?

I think what @mkarg meant when talking about "bottom up" was the dependency tree. My impression was always that it would make most sense to do full releases (to Maven Central) of the leafs in the dependency tree first so that other projects further up in the tree can pick them up.

BTW: I just saw that even the EJB project pushed a release to Maven Central today.

[mkarg]

@bshannon Thanks for the clarification. I actually misunderstood "staging" as "only staging". Fine, so I can rewrite the dependencies soon. :-)

@chkal Yes, like you said, I only meant the dependency tree with "bottom up" so JAX-RS can be released once JAF and JAXB are released, not the governance model (but in fact, now that it was mentioned, I also love bottom-up governance).

@spericas I'm sorry but I need to emend here. Due to the Jakarta EE Spec Committee's decision, the idea of "RI"s do not exist anymore. So while the product Eclipse GlassFish still will be managed by the EE4J PMC (there is no Jakarta EE PMC), it is not part of the platform Jakarta EE anymore, as it will only be one (among many competitive) implementations of Jakarta EE. This is a huge change in its status, and to be fair to all vendors, I will not support the idea of particularly supporting GlassFish in any way more or less than any other product. So I am sorry to say that (particularly as a Jersey contributor and Payara customer), but from the view of JAX-RS as a cross-vendor specification, GlassFish is in not an important part of Jakarta EE anymore, it only is some implementation of it. Just as we will not stop the world for IBM, Red Hat or Apache having problems with releasing their implementations, we should not stop the world for Eclipse / Oracle.

[bshannon]

Christian Kaltepoth wrote on 11/01/2018 09:44 AM:
>

Just to make sure I understand this correctly. So the JAF release currently in
release review will be kept in the staging repository for now and will not be
released to Maven central in the next days?

It can't be released to Maven Central until the release review completes.

I think what @mkarg https://github.com/mkarg meant when talking about
"bottom up" was the dependency tree. My impression was always that it would
make most sense to do full releases (to Maven Central) of the leafs in the
dependency tree first so that other projects further up in the tree can pick
them up.

Releasing them to the staging repository should be good enough to allow other
projects to make progress and update their dependencies.

BTW: I just saw that even the EJB project pushed a release to Maven Central
today https://search.maven.org/search?q=jakarta.ejb.

That's probably a violation of the EDP since they haven't completed a release
review.

[mkarg]

Bill Shannon wrote on 11/01/2018:

BTW: I just saw that even the EJB project pushed a release to Maven Central today https://search.maven.org/search?q=jakarta.ejb.

That's probably a violation of the EDP since they haven't completed a release review.

As the EJB project lead is @dblevins, this assumption would imply that an PMC member actually broke the EDP by intention or was not fully aware of its core rules. Who will tell him? ;-)

[spericas]

@spericas This is a huge change in its status, and to be fair to _all_ vendors, I will not support the idea of particularly supporting GlassFish in any way more or less than any other product.

Is anyone asking you to support it more or less than other products? Has anyone said, let's not support product X in favor of Glassfish or vice versa?

[mkarg]

@spericas

@spericas This is a huge change in its status, and to be fair to _all_ vendors, I will not support the idea of particularly supporting GlassFish in any way more or less than any other product.

Is anyone asking you to support it more or less than other products? Has anyone said, let's not support product X in favor of Glassfish or vice versa?

Reading all the comments of this thread again I still have the impression that Dmitry asks for (a) that the JAX-RS team updates the release tracker of the particular product of GlassFish and (b) delaying JAX-RS release 2.1.3 to Maven Central for the sole sake of checking against the compatibility with the exact product of GlassFish. This is a rather clear preference for one particular product and has nothing to do with our work on the common standard of JAX-RS.

[bshannon]

Markus KARG wrote on 11/01/2018 01:48 PM:
>

Reading all the comments of this thread again I still have the impression that
Dmitry asks for (a) that the JAX-RS team updates the release tracker of the
particular product of /GlassFish/ and (b) delaying JAX-RS release 2.1.3 to
Maven Central for the sole sake of checking against the compatibility with the
exact product of /GlassFish/. This is a rather clear preference for one
particular product and has nothing to do with our work on the common standard
of JAX-RS.

We need JAX-RS to work in GlassFish, and we need to track the progress so that
we can better manage the release of GlassFish.

If you release JAX-RS 2.1.3 and we later discover that it fails some tests when
integrated with GlassFish, you'll need to release another version of JAX-RS to
fix those problems, and we'll need to wait for that release before we can
release GlassFish.  That's not ideal from our perspective, but if it's necessary
to do it that way, that's acceptable.  Of course, any JAX-RS release needs to
pass the standalone JAX-RS TCK before release.  Admittedly the likelihood that
it would then fail in GlassFish is small, but these sorts of problems have
happened in the past.

[mkarg]

Bill, who is "we"? I don't need JAX-RS work in GlassFish. ;-) Okay, I "want" JAX-RS work in GlassFish. :-)

I fully understand the negative impact on GlassFish and would love to see progress on the bug fix, but for the sake of being product-independent and self-governed I must insist on the independence of release processes. Anyways, looking at the current status of GlassFish, I doubt that there is any bug in JAX-RS that will be a de-facto showstopper for GlassFish. The problem will be rather missing manpower on other projects, as I could simply release another JAX-RS patch release within days. The time to fix the actual bug is the same whether you have no time to do that before or after the release. So this argument is a weak one. BTW, all JAX-RS releases passed the TCK, passed the PR review, passed the EMO and PMC review: Nobody simply detected that bug, as what is failing is not covered by the TCK or the spec or any rule - the fact that OSGi is essential by Jersey/GlassFis but is not part of the JAX-RS spec is the actual reason for the current situation.

Anyway, we certainly will do our best that GlassFish can be released soon. All I ask for is to fully respect the independence of the projects, in particular of the API projects from the product implementations. GlassFish might have a deadline, JAX-RS does not.

[bshannon]

Markus KARG wrote on 11/01/2018 03:02 PM:
>

Bill, who is "we"?

For now, let's say "Oracle", because Oracle is the one who committed to
producing the Eclipse GlassFish 5.1 release.  But after that it will be whoever
steps up to lead Eclipse GlassFish, and the community helping them.

Anyway, we certainly /will/ do our best that GlassFish can be released soon.
All I ask for is to fully respect the independence of the projects, in
particular of the API projects from the product implementations.

As I said, that's fine.  You understand the issues and have accepted the
consequences.  I don't see a conflict here.

[edbratt]

Please think of it as this way:

Oracle just contributed about 13 million lines of code to Eclipse
Foundation. Early on, we established that we'd need to build it and test
it, to be sure that the code we've contributed is, in fact,
representative of Java EE -- which will provide the basis for Jakarta EE
moving forward.

Once this is verified, we have a formal basses to claim that Java EE has
been contributed to Eclipse Foundation and we have achieved the goal we
set out for this effort. With this out of the way, the code becomes
subject to the rules and customs of the Eclipse Foundation and the
Jakarta EE procedures.

You can think of this as a verification marker.

I would add that Eclipse Foundation and the Jakarta EE Steering
Committee have continued to assign a high degree of importance to
accomplishing these goals so, I think the "we" here is a bit broader
than just Oracle.

Thank you very much for helping us all accomplish these goals. We really
do appreciate your support.

-- Ed

On 11/1/2018 3:26 PM, Bill Shannon wrote:

Markus KARG wrote on 11/01/2018 03:02 PM:
>

Bill, who is "we"?

For now, let's say "Oracle", because Oracle is the one who committed to
producing the Eclipse GlassFish 5.1 release.  But after that it will
be whoever
steps up to lead Eclipse GlassFish, and the community helping them.

Anyway, we certainly /will/ do our best that GlassFish can be
released soon.
All I ask for is to fully respect the independence of the projects, in
particular of the API projects from the product implementations.

As I said, that's fine.  You understand the issues and have accepted the
consequences.  I don't see a conflict here.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/eclipse-ee4j/jaxrs-api/issues/690#issuecomment-435208043,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALtmboQGT_13mNYxXij1DkB_F3DyugrJks5uq3UlgaJpZM4YBpZc.

[chkal]

@bshannon

It can't be released to Maven Central until the release review completes.

Sure, but will it be released to Maven Central after the release review or will it stay in the staging area and wait for other projects which depend on JAF? I just want to understand if we can expect JAF to appear in Maven Central in the next days or if it will take more time.

Admittedly the likelihood that it would then fail in GlassFish is small, but these sorts of problems have happened in the past.

I think it would be really helpful to have some kind of checklist for projects to go through before promoting a release. Of course all the projects will have a good overview about the project specific aspects to check, but things like the OSGi manifest entries are important especially for Glassfish and are difficult to get right (as we saw in the JAX-RS case). It would be great to provide others projects some guidance on how they can ensure that the aspects which are important for the Glassfish integration are fine.

[bshannon]

Christian Kaltepoth wrote on 11/01/2018 11:46 PM:
>

@bshannon https://github.com/bshannon

It can't be released to Maven Central until the release review completes.

Sure, but will it be released to Maven Central after the release review or
will it stay in the staging area and wait for other projects which depend on
JAF? I just want to understand if we can expect JAF to appear in Maven Central
in the next days or if it will take more time.

I expect to release it to Maven Central shortly after the release review is
approved.

[mkarg]

@bshannon Great! :-) I will change JAX-RS's POM accordingly in preparation!

[jansupol]

@m0mus JAX-RS release depends on JAXB-RI impl

[m0mus]

Folks, this is the only API not released to OSSRH staging now. Can you please review and release it ASAP? You are blocking other projects.

[spericas]

PR #701 dropping JDK 11 from Travis for EE4J_8 branch is now merged.

[waynebeaton]

I'm coming to this a bit late, so I'll apologize for not reading every word in this thread.

There is no specific requirement to use The Eclipse Foundation's Nexus instance (I'll make sure that my colleagues are on the same page). The requirement is that milestone/snapshot builds be labeled as such (milestone, release candidate, pre-release, beta, snapshot, ... ) The PMC determined that using OSSRH is the place for staging everything while the projects all work together on the common goal of getting everything onboard and realizing Eclipse GlassFish 5.1.

Eclipse Project for JAX-RS has already gone through a release review for version 2.1.1; no further reviews are required for any service releases that patch that release.

I take exception to any notion that projects are independent of one another. The other EE4J projects are your consumers: they are your community and you are fully dependent on them. We'll see how this manifests in time, but it is completely reasonable for the community to expect related projects to align release schedules and themes, share practices, and more. If anybody takes exception to this statement or wants to discuss it further, I suggest that you connect with me directly.

[mkarg]

@m0mus By all due respect. We are not blocking anybody. We work as fast as we can, but we will do it with care and with respect to our rules. That might imply some annoying delay to others, but this is quite normal in open source projects. BTW, there would have been no delay if you simply would give up the silly idea of having pre-releases staged in a release repo and start using SNAPSHOTs correctly. THAT is the reason why we cannot stage JAX-RS, if you still did not understand our problem.

[mkarg]

Last order! I am about to stage to OSSRH, but there are two open PRs against EE4J_8!

• [x] https://github.com/eclipse-ee4j/jaxrs-api/pull/692 (merged meanwhile)
• [x] https://github.com/eclipse-ee4j/jaxrs-api/pull/699 (skipped)

Please review both so I can perform the staging! :-)

[chkal]

@mkarg I don't think that #699 is required for the release. So +1 for starting with the release procedure!

[spericas]

@mkarg Agree with @chkal. +1 for release!

[mkarg]

@chkal @spericas Thanks for your reply. I press the red button now. ;-)

[mkarg]

https://ci.eclipse.org/jaxrs/job/Publish%20Release/17/

[mkarg]

OSSRH Staging done for 2.1.3-SNAPSHOT: https://oss.sonatype.org/content/repositories/snapshots/jakarta/ws/rs/jakarta.ws.rs-api/2.1.3-SNAPSHOT

As I assume that we shall stage a non-SNAPSHOT next, I have prepared a fast-track PR https://github.com/eclipse-ee4j/jaxrs-api/pull/703 to fix that and will re-stage once that is approved for merge.

[mkarg]

OSSRH Staging done for 2.1.3: https://oss.sonatype.org/content/repositories/jakartawsrs-1001/jakarta/ws/rs/jakarta.ws.rs-api/2.1.3

[mkarg]

@jansupol This issue is assigned to you. Feel free to close it. :-)

[jansupol]

@mkarg thank you :)