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
support wildcards #5756
support wildcards #5756
Conversation
Code analysis and actionsDO NOT DELETE THIS COMMENT.
|
#build |
Your personal build request is at https://wasrtc.hursley.ibm.com:9443/jazz/resource/itemOid/com.ibm.team.build.BuildResult/_9DIzsOgYEeiB5J8_tOvcPQ Target locations of links might be accessible only to IBM employees. |
The build benjamin-confino-5756-20181114-1535 |
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.
I like the concept of this change, but I would like the wildcard detection to be more tolerant (see previous comment).
Also, please javadoc this so people know about it!
@@ -347,6 +363,20 @@ private static String getReplacementFeature(String originalFeature, Set<String> | |||
return null; | |||
} | |||
|
|||
private static boolean removeWildcardFeature(Set<String> features, String removeFeature) { | |||
String matcher = removeFeature.substring(0, removeFeature.length() - 1); //This assumes the feature string is in the format "feature-*" |
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.
I don't think we should make this assumption that wildcards are always feature-*
, mainly because if I do something slightly different but valid like feature*
or feature-1.*
it would be tricky to figure out why the features are not being removed.
4aedc52
to
7e0ebe0
Compare
fixes #5755