-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename the TCK packages #1082
Rename the TCK packages #1082
Conversation
Just to clarify that the current changes in this PR will not be enough for package rename. Once the package name is confirmed I am sure below will also be taken care of.
|
@alwin-joseph You're correct. I assumed my IDE was smarter than it was :) I'll see if I can get this fixed with a script or something. |
…s.rs. Signed-off-by: James R. Perkins <[email protected]>
f831c8f
to
0a01625
Compare
@alwin-joseph I think I've got it all fixed now. I did see some TCK failures for There is some other weirdness with the jersey-tck too. It's got a dependency on There is also a |
Thanks!
Agree. I see it now. It was missed from PR #1076. The jersey-tck/pom.xml need to have the same property <tck.artifactId>jakarta-restful-ws-tck</tck.artifactId> set as default and use the same for tck name instead of jakarta.ws.rs-tck. The tck name was kept in consistent to the previous releases of the REST TCK. I will create a separate PR to correct this.
We need 2 TCK bundles differentiated by the LICENSE (EFTL or EPL) file used in them. The EFTL TCK bundle will be named as jakarta-restful-ws-tck*.zip and EPL TCK bundle will be named as restful-ws-tck*.zip. I was expecting to generate and run the EFTL bundle by default which will be used for ballot review and certification. The EPL TCK bundle will also need to be generated on a need basis hence the property override. |
I was able to test this change. It works and passes the tests. There were 2 failures for
Created PR #1087 to fix this . |
Excellent. Thanks @alwin-joseph. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. The tests do pass with this change. TCK docs were updated correctly.
PS: If I understand correctly, the new name is required to be approved by the spec team(committers of this repo). As long as this name is acceptable here, no issues.
Yes this is just renaming the packages as part of the spec list emails. It doesn't seem there is a concrete decision yet, however in the vote |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jamezp. Hope we won't see these types of PRs anytime soon.
I'm not totally convinced about the proposed package name, but it seems a renaming is better than no renaming at this time, so I'm approving this PR. |
This package name seems to be a must-have for EE 11 |
This discussion is still ongoing. The decision based on too many people abstaining from voting and iJUG is planning to repeat the voting process. Chances are good that the this decision will be changed. So it would be wise to stick with our current package as-is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-1 as there is no official requirement for this change so far, and "ee" is not following the Java package best practices. The iJUG currently is triggering a repeating of the vote to prevent that package renaming.
Any sort of ETA on this? |
TL;DR: I think one or two weeks, depending on the outcome of the next spec and steering meetings. As vice-embassador of iJUG at the Eclipse Foundation I am bound to the opinion of iJUG here. If we change the rename from "ee.jakarta." to "org.eclipse.jakarta." I immediately will change my vote from -1 to 0. Background: Just got informed that heavy discussions still going on offline, so currently Eclipse's Jakarta EE Developer Advocate Ivar Grimstad strives to find a solution. The problem is the many abstained votes, which does not provide a future-proof foundation for such a massive cross-project package renaming (the fear is that in future those abstained votes understand the impact they helped to create and will ask for another package rename in EE11 or EE12 then). I will post updates here once I hear about them. For the time being, the current official status is that it is not any problem for the TCK tests themselves to stick with the jakarta namespace as is (i. e. jakarta.ws.rs.tck.), but not application code (i. e. everything that the TCK contains that is actually to be executed by or within a tested JAX-RS implementation. The problem is that some application servers reject such code. We are officially free to choose any package name for that code, as long as it does not start with "jakarta." due to bugs in their api package detection filters (this is the point unter discussion - Ivar and iJUG think this is a "bug" in the implementation as package names are not hierarchical, but those application vendors think this is "common sense" and reject to "fix" that). We officially may use the "ee.jakarta." package, but iJUG assumes this opens legal problems as Eclipse does not own the "*.ee" TLD: If package names are hierarchical, then "ee.jakarta" is not covered by legal protection as the TLD is "ee" not "jakarta" but "ee" cannot be protected as a brand; if package names are not hierarchical, then "ee.jakarta" is not a problem - but then no rename is needed at all. The clarification of both question will need one to two weeks. So until both questions are officially and finally resolved, I would agree to renaming just the application code to something other than "ee.", keep the other TCK code as-is, e. g. "org.eclipse.jakarta.ws.rs.tck.". We even could even rename the TCK completely to that package. OTOH the outcome of the discussions could be that the steering committee decides for a completely different package which is mandatory for us all, then we have to rename again... |
Greetings Jakarta RESTful Web Services project team, The topic of package names for TCKs was discussed in the Specification Committee call on Wednesday, January 26. The outcome of these discussions is that the JESP and the TCK Process will be updated with the clarification and requirement that packages beginning with End-user applications are not allowed to use 'jakarta' namespace, and since TCKs are supposed to mimic the behavior of these applications while testing the implementation, it, therefore, does not make sense to use this namespace in TCKs. Implementations experiencing issues with The project teams may choose any package name other than those beginning with The Specification Committee suggests that you go forward with this PR, either with the proposed package name change or change it to something entirely different of your choice. As long as it is not starting with Spec. committee recognizes there has been confusion with respect to this and is working to rectify the relevant guides and process documentation. |
@alwin-joseph @spericas @jansupol @mkarg @andymc12 The official decision is in. We cannot use the package name |
The namespace is fine. Jakarta Faces has used a similar one, and Jakarta Authentication will very likely use a similar one too. |
We definitely should be using a name that satisfies Jakarta EE 11 requirements. We do not want to rename it again. |
+1 I've got no real strong opinion on what that is as long as everyone agrees. |
We will never be sure about that as the Spec Committee has not mandated ee.jakarta but just allowed to use it. I'm just waiting for iJUG's answer and will then re-vote on this PR. Stay tuned. |
Ivar meanwhile sent preliminary documentation, definivitely for EE 10 we are free to choose the package name (ee.jakarta.ws.rs.tck) is explicitly allowed to be used but not mandatory), but for EE 11 there will be a discussion on a mandatory package. So we MUST rename for EE 10, but not necessarily to ee, and ee is NOT GUARANTEED to be the one needed for EE 11. That is the final decision of the Spec Committee for EE 10. As the domain ee.jakarta is held by the EF, I do not see a reason to chose a different package name. I will give one more day for the iJUG to discuss, but if I do not hear from them, I will turn my vote from -1 to 0 tomorrow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The iJUG did not respond, so I change my vote from -1 to 0.
What I do not see is the ee.jakarta.tck.ws.rs
package name. In my mind it would make more sense to use ee.jakarta.ws.rs.tck
instead.
Perhaps an even better package name would be |
For me personally the package name doesn't matter that much. If we want it changed though, I do need a definitive answer on what it needs to be changed to as it takes some time to do it. Then I will try to find some time to change it if that's what we want. |
I believe we should keep the proposed package naming for now, as it aligns better with our current packages. I will merge this PR tomorrow. |
+1 |
Resolves #1081
I'm creating this as a draft since we don't really know what the package name should be. This would be my personal vote though.