-
Notifications
You must be signed in to change notification settings - Fork 466
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
[WFCORE-7095][WFCORE-7108][WFCORE-7111][WFCORE-7112][WFCORE-7113][WFCORE-7114] Module identifier in api fixes #6301
Conversation
…ntifier into name and slot and process the tuple
…removal of ModuleIdentifier
Core -> Full Integration Build 14469 outcome was UNKNOWN using a merge of 120e431 |
Core -> Full Integration Build 14167 outcome was UNKNOWN using a merge of 120e431 |
Core -> Full Integration Build 14168 outcome was UNKNOWN using a merge of 120e431 |
Core -> Full Integration Build 14169 outcome was UNKNOWN using a merge of 120e431 |
Core -> Full Integration Build 14170 outcome was UNKNOWN using a merge of 120e431 |
This comment was marked as off-topic.
This comment was marked as off-topic.
Core -> WildFly Preview Integration Build 14256 outcome was UNKNOWN using a merge of 60a3f32 |
Core -> Full Integration Build 14173 outcome was UNKNOWN using a merge of 60a3f32 |
This comment was marked as off-topic.
This comment was marked as off-topic.
"Windows - JDK 11 (Pull Request) - merge" failure seems unrelated, same error trace in other Jobs |
Thanks @bstansberry |
This is an aggregate of:
#6282
#6293
#6298
#6299
#6300
#6302
In total this deals with what I think are all the places where WF Core exposes ModuleIdentifier in API that full WildFly or an external extension might use. It deprecates all such places and provides an alternative for all but two things that I don't think external modules will use.[1]
I realize this is a lot to deal with at the last minute for WF Core 27, and if it's too much that's ok. Doing this though will give us more freedom to change things right away in Core 28 / WF 36, and gets the deprecation out of the way for downstream. (These APIs are not supported for external use downstream, but we'd likely want to deprecate them anyway before removing them in some future release.)
#6282 is the most substantive. #6293 is already approved. The others are new but pretty simple.
[1] Those two things deprecated without alternatives provided in this PR are:
Attachments.CLASS_PATH_ENTRIES which we should just break (by changing its list element type) with no migration path. It's not used outside the kernel and shouldn't be.
Attachments.ADDITIONAL_ANNOTATION_INDEXES for which we will need to do a simple migration dance in a couple core Betas to let the one 'ee' subsystem use migrate.
@yersan @ropalka @dmlloy FYI.