Replace @Optional with @OptArg or similar
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by locating the @Optional annotation and its usages in the Intake codebase, then review how command arguments and annotation references are exposed. Determine the replacement name and the affected references; done means the naming conflict is resolved consistently without ambiguity.
Written by the indexing model from the issue text.
Description
Currently if using the @Optional annotation to specify an optional argument, within a class file also using the JDK Optional class, or the Guava Optional class you're forced to use the expanded type name so as to specify which Optional you're referring to.
To resolve this naming conflict, I suggest making the @Optional annotation an @OptArg annotation or similar.
- Dominant language
- Java
- Stars
- 102
- Forks
- 18
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from EngineHub/Intake
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Localization support Open
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in EngineHub/Intake
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
elastic/gradle-plugins#157 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
cryptomator/hub#497 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
johanhaleby/occurrent#1120 ·