- 
                Notifications
    You must be signed in to change notification settings 
- Fork 84
[issue-713] - Add a test to the TCKs in order to verify the usage of the "@ExternalDocumentation" annotation #714
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
base: main
Are you sure you want to change the base?
Conversation
| Can one of the admins verify this patch? | 
e3c66f2    to
    20c1a80      
    Compare
  
    | I'm a bit surprised we allow  | 
| 
 I was thinking the same thing. For reference, the JavaDoc was added here. It's not clear if the use on any type was intentional. I wonder if we should investigate other implementations and if it's not supported anywhere, maybe we alter the JavaDoc accordingly. | 
| We discussed this change on today's spec call and the thinking is that it make sense to go ahead with having the TCK check the use of  We're generally hesitant about support on any class (which is what the annotation specifies) and we're likely to make some adjustment to that part of the JavaDoc, perhaps limiting it to only REST resource classes. That would need to be in a new major version v5 since it's technically a break in the spec, even if that functionality is not supported by any implementation currently. | 
| Thanks @MikeEdgar - I didn't make it to the call, due to conflicts, but I generally agree with your considerations. | 
| 
 IIUC, then the test which is checking the method should stay, correct? 
 Nevertheless, users could object that implementations do not honor what the spec Javadoc states. | 
| 
 Yes, that's right. We would target that change for 4.2 (4.1.1 was just released yesterday). 
 I see your point and it's true that users could object, but I'm dubious that allowing the annotation on any type as stated in the Javadoc was implemented by any runtime or even intended originally. It's not clear what use case it would cover that couldn't be supported using one of several other approaches to having external docs in the root of the produced OpenAPI document. It would probably be best to remove or somehow clarify it in v5 rather than enforcing something that isn't actually going to be used very much. | 
…the "@ExternalDocumentation" annotation
20c1a80    to
    d8f2928      
    Compare
  
    | vr.body("paths.'/a'.externalDocs.description", equalTo("Find more information about this application resource")); | ||
| vr.body("paths.'/a'.externalDocs.url", equalTo( | ||
| "https://github.com/microprofile/microprofile-open-api/blob/main/tck/src/main/java/org/eclipse/microprofile/openapi/apps/scanconfig/a/AResource.java")); | 
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.
| vr.body("paths.'/a'.externalDocs.description", equalTo("Find more information about this application resource")); | |
| vr.body("paths.'/a'.externalDocs.url", equalTo( | |
| "https://github.com/microprofile/microprofile-open-api/blob/main/tck/src/main/java/org/eclipse/microprofile/openapi/apps/scanconfig/a/AResource.java")); | |
| vr.body("paths.'/a'.get.externalDocs.description", equalTo("Find more information about this application resource")); | |
| vr.body("paths.'/a'.get.externalDocs.url", equalTo( | |
| "https://github.com/microprofile/microprofile-open-api/blob/main/tck/src/main/java/org/eclipse/microprofile/openapi/apps/scanconfig/a/AResource.java")); | 
Should be this I think?
externalDocs is on the operation object, not the path item object.
We recently found an issue in the SmallRye OpenAPI implementation, which reveals missing test coverage for the
@ExternalDocumentationannotation usage in the MicroProfile OpenAPI TCKs.This PR provides a new test to cover some basic cases.
Resolves #713