-
Notifications
You must be signed in to change notification settings - Fork 357
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
Enhancement for docprocessor #5028
Enhancement for docprocessor #5028
Conversation
This one is difficult. On one hand, it breaks backward compatibility. It changes the On the other hand, making the change backward compatible is challenging. Jersey made backward-incompatible changes in the past, but it is not ideal. Will need to give this more thoughts |
The issue can be with users implementing their own DocProcessor, which is being loaded by the How ugly does that sound? |
Would deprecating the old methods and adding new ones with a third arg in |
It looks ugly for a while, but eventually we can remove the deprecated methods and it will look pretty again. I'm fine with this solution. |
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.
LGTM
Current implementation of the
DocProcessor
provides access to types that extend theElement
class such asTypeElement
,ExecutableElement
andVariableElement
. However extracting javadoc from these is not possible without access to aDocTrees
object, example shown in usages here. By providing access to theDocletEnvironment
to theDocProcessor
functions, we can get access to objects that can properly evaluate the javadoc of these elements.