[WFCORE-7114] Deprecate use of ModuleIdentifier in ModuleDefinition #6302
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
| } | ||
|
|
||
| /** @deprecated use {@link #getModuleName()} */ | ||
| @Deprecated(forRemoval = true) |
There was a problem hiding this comment.
As a rule of thumb, we are always asking for the since attribute on all @deprecated annotations so we can make an idea without looking at the Git history when it was deprecated.
This can be done later though
| public String getModuleName() { | ||
| return moduleIdentifier.toString(); // inefficient but this is unused. When we switch the use to this we'll store the string. | ||
| } |
There was a problem hiding this comment.
I wonder if getModuleName is what we would want. The ModuleIdentifier is composed by name and slot attributes. So getModuleName() returning the result of moduleIdentifier.toString() maybe is not what we want since it could drive into confusion since someone could be expecting to get just the ModuleIdentifier name.
As additional detail, the JBoss Modules documentation still makes a distinction about what a module name is (https://jboss-modules.github.io/jboss-modules/manual/#names) and what are module identifiers https://jboss-modules.github.io/jboss-modules/manual/#slots
There was a problem hiding this comment.
getModuleIdentifier() is already taken, so ....
| public String getModuleName() { | ||
| return moduleIdentifier.toString(); // inefficient but this is unused. When we switch the use to this we'll store the string. | ||
| } |
There was a problem hiding this comment.
getModuleIdentifier() is already taken, so ....
yersan
added
the
ready-for-merge
https://issues.redhat.com/browse/WFCORE-7114