Skip to content
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

[Java][Spring][#2901] remove unused import from spring template #3843

Closed

Conversation

bilak
Copy link
Contributor

@bilak bilak commented Sep 5, 2019

closes #2901

@bilak bilak force-pushed the bugfix/2901_remove-unused-import branch from 9b4c3ee to ce3b7c5 Compare September 6, 2019 05:10
@bilak
Copy link
Contributor Author

bilak commented Sep 6, 2019

@wing328 is it possible to add this pr to upcoming release?

@bilak bilak changed the title 2901 remove unused import from spring template [Java][Spring][#2901] remove unused import from spring template Sep 6, 2019
@macjohnny macjohnny requested review from cbornet and jmini September 10, 2019 07:05
@bilak
Copy link
Contributor Author

bilak commented Sep 10, 2019

cc @bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04)

@macjohnny macjohnny added this to the 4.1.2 milestone Sep 10, 2019
@jimschubert
Copy link
Member

This will break the JavaSpring templates… for example:

Maybe a good way around this, since the template modified in this PR is used by multiple library options which apparently provide their own build scripts… would be to fully qualify the occurrences of JsonNullable (change JsonNullable to org.openapitools.jackson.nullable.JsonNullable).

@cbornet does that seem like a valid fix to get the import out of the shared template?

For anyone affected by this in an already released version, you can create a new directory with a single file called model.mustache and the contents of this PR's fix:

package {{package}};

import java.util.Objects;
{{#imports}}import {{import}};
{{/imports}}
{{#serializableModel}}
import java.io.Serializable;
{{/serializableModel}}
{{#useBeanValidation}}
import javax.validation.Valid;
import javax.validation.constraints.*;
{{/useBeanValidation}}
{{#performBeanValidation}}
import org.hibernate.validator.constraints.*;
{{/performBeanValidation}}
{{#jackson}}
{{#withXml}}
import com.fasterxml.jackson.dataformat.xml.annotation.JacksonXmlRootElement;
import com.fasterxml.jackson.dataformat.xml.annotation.JacksonXmlProperty;
{{/withXml}}
{{/jackson}}
{{#withXml}}
import javax.xml.bind.annotation.*;
{{/withXml}}
{{^parent}}
{{#hateoas}}
import org.springframework.hateoas.ResourceSupport;
{{/hateoas}}
{{/parent}}

{{#models}}
{{#model}}
{{#isEnum}}
{{>enumOuterClass}}
{{/isEnum}}
{{^isEnum}}
{{>pojo}}
{{/isEnum}}
{{/model}}
{{/models}}

During generation, pass the new folder to the template directory option for your tool:

  • CLI: -t
  • gradle plugin: templateDir
  • maven plugin: templateDirectory

The generator should fall back to embedded templates for any not found in the target directory.

@wing328 wing328 modified the milestones: 4.1.2, 4.1.3 Sep 11, 2019
@wing328 wing328 modified the milestones: 4.1.3, 4.2.0 Oct 4, 2019
@wing328 wing328 removed this from the 4.2.0 milestone Oct 30, 2019
@mateusz-nalepa
Copy link

Hi @jimschubert ,

What about solution like this?
{{#isNullable}}import org.openapitools.jackson.nullable.JsonNullable;{{/isNullable}}

@jmini @cbornet does this looks like a valid solution?

@RockyMM
Copy link
Contributor

RockyMM commented Jun 23, 2020

To be honest looks fine to me. To be honest #6154 looks more complete.

@jimschubert
Copy link
Member

Following up for visibility… 

What about solution like this?
{{#isNullable}}import org.openapitools.jackson.nullable.JsonNullable;{{/isNullable}}

This would be an excellent option, and users can do this for any version of the tool by extending the templates.

Since this PR would be a breaking change and that hasn't been addressed, I think we'll move forward with #6154 as this would accomplish the same while also moving us toward more vanilla output by default (without the JSON Nullable library).

@jimschubert
Copy link
Member

Thanks again for the PR. We've merged #6154 so the issue should be addressed in a way that allows for both scenarios.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

remove unused import org.openapitools.jackson.nullable.JsonNullable from generated model
6 participants