-
Notifications
You must be signed in to change notification settings - Fork 6k
@Pattern is not generated for scalar types #10989
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
Comments
More on this. In version 2.4.19 the pattern is "correctly" added but only if the property is directly specified and with an example. |
Just made a test with version 3.0.34. The issue is still present, though it seems to work when directly specified even when no example is present. |
Hi, I had limited time to investigate the issue and wanted to try a fix, but a full day wasn't enough for me to grasp the subtleties of the project structure (codegen v3 depends on codegen-generators, which depends on codegen v3?) and my attempts at building a maven plugin v3 never included the changes I made in codegen v2. If someone with a better knowledge of the project were willing to have a look at whether my attempt makes sense and make the PR if it does, I'd be delighted and thankful. I detected only one occurrence in DefaultCodegen where the pattern was not escaped and wanted to test the behaviour if the escape was added there: @@ -3322,7 +3324,8 @@ public class DefaultCodegen {
Model model = allDefinitions.get(refProperty.getSimpleRef());
if (model instanceof ModelImpl) {
ModelImpl modelImpl = (ModelImpl) model;
- cp.pattern = modelImpl.getPattern();
+ cp.pattern = toRegularExpression(modelImpl.getPattern());
cp.minLength = modelImpl.getMinLength();
cp.maxLength = modelImpl.getMaxLength();
} |
Uh oh!
There was an error while loading. Please reload this page.
Hi.
Given the following definitions:
when the class is generated, no
@Pattern
annotation is inserted on the getter of the fields referencing theCurrencyIso
.I'm actually using the swagger-codegen-maven-plugin with version 2.3.1.
It seems that version 2.4.x fixes this issue, but then the patterns are not escaped when generated, leading to not compilable code in certain cases (e.g., if it contains
\d+
). There is already this issue about it.The text was updated successfully, but these errors were encountered: