Skip to content
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

Add @DeprecatedFeature annotation. #187

Merged
merged 7 commits into from
Nov 22, 2022
Merged

Add @DeprecatedFeature annotation. #187

merged 7 commits into from
Nov 22, 2022

Conversation

cmnbroad
Copy link
Collaborator

@cmnbroad cmnbroad commented Oct 4, 2022

This also fixes an issue where positional args were previously not showing up in command line help.

@cmnbroad cmnbroad changed the title Add @Deprecated annotation. Add @DeprecatedFeature annotation. Oct 4, 2022
@codecov
Copy link

codecov bot commented Oct 4, 2022

Codecov Report

Base: 76.66% // Head: 76.69% // Increases project coverage by +0.02% 🎉

Coverage data is based on head (89b9f4c) compared to base (7fe37aa).
Patch coverage: 91.75% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #187      +/-   ##
============================================
+ Coverage     76.66%   76.69%   +0.02%     
- Complexity      744      762      +18     
============================================
  Files            32       33       +1     
  Lines          2576     2609      +33     
  Branches        498      505       +7     
============================================
+ Hits           1975     2001      +26     
- Misses          406      409       +3     
- Partials        195      199       +4     
Impacted Files Coverage Δ
...adinstitute/barclay/help/TemplateMapConstants.java 0.00% <0.00%> (ø)
...roadinstitute/barclay/help/TemplateProperties.java 0.00% <ø> (ø)
...a/org/broadinstitute/barclay/help/DocWorkUnit.java 85.71% <66.66%> (-3.65%) ⬇️
...arclay/argparser/PositionalArgumentDefinition.java 74.32% <85.00%> (+3.95%) ⬆️
...nstitute/barclay/argparser/ArgumentDefinition.java 74.61% <93.33%> (+2.44%) ⬆️
...e/barclay/argparser/CommandLineArgumentParser.java 89.44% <100.00%> (+0.13%) ⬆️
...ute/barclay/argparser/NamedArgumentDefinition.java 77.81% <100.00%> (-0.78%) ⬇️
...titute/barclay/help/DefaultDocWorkUnitHandler.java 73.66% <100.00%> (-0.46%) ⬇️
.../org/broadinstitute/barclay/help/GSONArgument.java 100.00% <100.00%> (ø)
.../org/broadinstitute/barclay/help/GSONWorkUnit.java 100.00% <100.00%> (ø)
... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@cmnbroad
Copy link
Collaborator Author

cmnbroad commented Oct 4, 2022

@droazen I can't recall any reason why this was left as draft. I think its ready for review.

@cmnbroad cmnbroad requested a review from droazen October 4, 2022 21:50
Copy link
Member

@lbergelson lbergelson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cmnbroad A few minor comments.

public String getArgumentUsage(final int argumentColumnWidth, final int descriptionColumnWidth) {

final StringBuilder sb = new StringBuilder();
sb.append("--").append("POSITIONAL");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this include which position it should be in? Is that easy to find? I

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how to convey it, but positional args must always be first. But these are hardly ever used.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated this String to say "POSITIONAL (must be first)".

* return true if this argument has the {@code @Deprecated} annotation.
* @return true if this argument is advanced, otherwise false.
*/
public boolean isDeprecated() { return getUnderlyingField().isAnnotationPresent(Deprecated.class); }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So previously this would be triggered by the standard java Deprecated annotation? Should we continue to respect those as well? I don't remember why exactly we decided to use a separate annotation instead of the default one. So that intellij doesn't tag uses of it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old code was carried over from the GATK3 implementation, but never fully embraced, and only worked for args IIRC (not tools or other documented features). I think we used a custom annotation both for the IntelliJ issue, and also because we wanted to be able to specify a reason/detail string, which the Java annotation doesn't have. There are a couple of usages of the old tag in GATK for arguments, but I'd prefer to update them rather than carry around (and test) both annotations.

Utils.printSpaces(sb, numSpaces);

String description = getArgumentDescription();
if (isDeprecated()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this little decorator be factored out so it isn't repeated? Might make it more consistent if we change things in the future.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done - factored out this decorator plus another method to format the description since that was also duplicated on two places.

this.options = options;
@SuppressWarnings("unchecked")
public GSONArgument(final Map<String, Object> argMap) {
this.summary = argMap.get("summary").toString();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving this here seems like an improvement.

Copy link
Member

@lbergelson lbergelson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cmnbroad Looks good, one nitpick abut the positionals still, feel free to merge and we cacn always address that later

public String getArgumentUsage(final int argumentColumnWidth, final int descriptionColumnWidth) {

final StringBuilder sb = new StringBuilder();
sb.append("--").append("POSITIONAL (must be first)");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hate to be a pain about this, what happens if there are multiple positional arguments?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbergelson There can only be one "positional" option per CLP. It can be a collection, so it can have multiple values, but they have to be first in the list. Its basically just an arg without a name. We should probably just get rid of it, but GATK and Picard each have one, I think.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, I thought we supported multiple positionals, sorry, ignore my comment then.

@cmnbroad
Copy link
Collaborator Author

Sorry @lbergelson, I had to add one more commit based on testing with GATK. I messed up the command line display formatting when I factored out display code in this PR, which shows up spectacularly in GATK. We were outputting this:
Screen Shot 2022-11-22 at 9 32 55 AM
instead of the output produced with this last commit:
Screen Shot 2022-11-22 at 9 33 29 AM

@lbergelson
Copy link
Member

@cmnbroad Ugh, good catch. Formatting things is hard.

@lbergelson
Copy link
Member

@cmnbroad Good to merge.

@cmnbroad cmnbroad merged commit bc47857 into master Nov 22, 2022
@cmnbroad cmnbroad deleted the cn_deprecation_tag branch November 22, 2022 16:50
@cmnbroad
Copy link
Collaborator Author

Thanks @lbergelson!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants