Jakarta Staging Repository

mkarg commented 2 years ago

This PR adds the Jakarta Staging Repository (additionally to the local machine's repository settings) to the jersey-tck pom. This addition allows to use binary Jersey instead of mvn install Jersey from scratch without knowledge where to find pre-release builds. As such, it makes test-driving the TCK much more agile, as no local Jersey source code is needed at all.

jansupol commented 2 years ago

using mvn -Pstaging should be working fine. Is this any better?

arjantijms commented 2 years ago

The repo should already been defined in the super parent:

https://github.com/jakartaee/rest/blob/master/pom.xml#L25

https://github.com/eclipse-ee4j/ee4j/blob/master/parent/pom.xml#L100

spericas commented 2 years ago

If -Pstaging works, that should be sufficient.

mkarg commented 2 years ago

The problem with the alternatives mentioned in the above discussion is that it simply does not work without additional knowledge or constraints:

My solution works out of the box, at any time, in any state Jersey is.
-Pstaging implies that the TCK developer who simply wants to check his latest hack using jersey-tck needs to know that Jersey currently is in staging. Unless he is a Jersey developer, he typically would have a tough time finding out that truth.
Even if he found it out, every other week he has to check again as eventually Jersey got released, so no more -Pstaging is needed. This is tedious and not much repeatable. Test-driving a TCK change should not imply any need to check about the recent status of Jersey.
The super POM is meant for Jakarta APIs, not for implementations. jersey-tck is a copy-paste template for third party implementations. Nobody would like to refer to the Jakarta parent POM in his non-Jakarta implementation POM.

Hence, all your proposals stand in the way of a clean fire-and-forget experience for others.

jamezp commented 2 years ago

The issue with just adding the staging repository to the default profile is that it would pollute anyone that builds the projects local repository. Especially since the current staging repository has the released version set to 3.1.0 in the current staging repository. By using a profile the user somewhat explicitly acknowledges that they know they're going to pollute their local repository.

mkarg commented 2 years ago

The issue with just adding the staging repository to the default profile is that it would pollute anyone that builds the projects local repository. Especially since the current staging repository has the released version set to 3.1.0 in the current staging repository. By using a profile the user somewhat explicitly acknowledges that they know they're going to pollute their local repository.

The problem is, how should the user know when to use that profile and when not to?

jamezp commented 2 years ago

The problem is, how should the user know when to use that profile and when not to?

Actually, I'm going to redact my argument here. I didn't realize the jersey-tck module required a profile to be enabled to build it. I do think it makes sense to add the repository here in that case. It's really only temporary anyway right?

spericas commented 2 years ago

The issue with just adding the staging repository to the default profile is that it would pollute anyone that builds the projects local repository. Especially since the current staging repository has the released version set to 3.1.0 in the current staging repository. By using a profile the user somewhat explicitly acknowledges that they know they're going to pollute their local repository.

The problem is, how should the user know when to use that profile and when not to?

Normal users shouldn't need to use the staging repo. Expert users should know what they are doing and requiring an explicit profile seems very reasonable.

jansupol commented 2 years ago

The problem is, how should the user know when to use that profile and when not to?

The user can use the profile all the time. In staging, there are all releases, too.

mkarg commented 2 years ago

The user can use the profile all the time. In staging, there are all releases, too.

So this means, it is safe to do mvn -Pstaging jersey-tck verify always without further thinking? In that case, I would reject this PR.

chkal commented 2 years ago

So this means, it is safe to do mvn -Pstaging jersey-tck verify always without further thinking? In that case, I would reject this PR.

Yes, according to my understanding, -Dstaging just adds an additional repository for Maven to fetch artifacts from.

BTW: Sonatype actually recommends to not use <repositories> directly in the pom.xml.

See: https://central.sonatype.org/publish/requirements/

mkarg commented 2 years ago

BTW: Sonatype actually recommends to not use <repositories> directly in the pom.xml.

To be fair, the correct cite would be: "instead publish to Maven Central", which Jersey unfortunately does not do so far.

jansupol commented 2 years ago

So this means, it is safe to do mvn -Pstaging jersey-tck verify always without further thinking? In that case, I would reject this PR.

Yes, it does.

To be fair, the correct cite would be: "instead publish to Maven Central", which Jersey unfortunately does not do so far.

Correct, Jersey can publish to maven central only releases that have all dependencies available (such as in maven central), i.e. not in the staging repository that might go away next purging cycle. Otherwise, the Jersey release could become broken.

jakartaee / rest

Jakarta Staging Repository #1105