Ability to use wildcards in resourcePackages

[openapi-tools]

Ability to use wildcards in resourcePackages

[langecode]

I surely understand your use-case when we created the plugin we had pretty much the same need - to be able to create the OpenAPI/Swagger definition during build time instead of only having it at runtime. However, I am not sure I understand how you would run the plugin. You want to push the configuration of the plugin upwards into a parent Maven pom or similar? Because you are right, currently the scanning for API classes does not recurse through the packages. I think this was a choice to let the user of the plugin have full control. If your service is generated, e.g., from an archetype you could generate the configuration as part of the archetype, however, if you want to push the configuration upwards you will need the recursive behaviour. I guess, it would be quite ok to add an option whether to enable the recursion or not, if I remember correctly this takes place in the "scanner" implementation. You are more than welcome to do a PR for this feature.

…

[harveycggit]

Thank you for the quick response! I am not using an upstream pom; I have a template that is used for new projects where some automated search and replace goes on in the project templates, so the build plugin would exist for every project. My main interest is having this functionality be removed from the developers' stable of responsibilities; I don't have to train them and they make fewer mistakes. I'm using the generated swagger in a Jenkins pipeline to populate both 3scale (my API gateway) and SwaggerHub and would be happier if a developer was never in a situation where they added a new REST resource in a new package and were then puzzled by why they don't see it in SwaggerHub, etc. We work pretty hard here to keep developers writing code as opposed to worrying about configurations :)

I'll have a look and see if I can figure out how to change to scan all classes that are within the project's code given a syntax like:

edu.upenn.isc.*

there would be no need to scan any library jars, etc.

Thank you, I'll get back to you if I can figure it out. From your perspective, would you prefer an additional config property like true or would simply ending the resourcePackage with an asterisk be enough?

Best,
Charles

[harveycggit]

Sorry it ate my examples. From your perspective, would you prefer an additional config property like <recursiveScan>true<recursiveScan> or would simply ending the resourcePackage with an asterisk be enough?

[harveycggit]

Ok, maybe I am confused, but the following setting seems to do exactly what I want to do, which is find @Api in every package under edu.upenn.isc.esb.openshiftUtils - does that seem correct?

<configuration>
<useResourcePackagesChildren>true</useResourcePackagesChildren>
<resourcePackages>
<resourcePackage>edu.upenn.isc.esb.openshiftUtils</resourcePackage>
</resourcePackages>

[langecode]

Yes you are right - we seem to have this feature already. If you enable userResourcePackagesChildren you should get recursive behaviour - implemented here: https://github.com/openapi-tools/swagger-maven-plugin/blob/master/src/main/java/io/openapitools/swagger/JaxRSScanner.java#L72

Been long since we did that code so I actually did not remember. Let me know if it does not work.