Open 62mkv opened 4 years ago
A thing occurred to me. If it (the enum) already exists, you can do a JDL export and modify the exported JDL as a workaround. That way, no need for a keyword.
I will have to research what does it mean... (JDL export)
but in general, my suggestion does not assume that the enum "exists"; just that it will not be generated (but can be imported and used as a type name for entity fields). so, generated code will not compile until I provide the implementation, but at least I will immediately know where to put it and how it will be named
A JDL export basically means doing jhipster export-jdl
in your JHipster application.
This feature is kinda impossible. It would mean bypassing validations, and build. I may be wrong, but it's a tough one.
ok, I've read about exportJdl
it basically assumes having already generated JHipster app but without jdl file. I never generated a JHipster app without JDL file, so not sure what it could give me, but glad to know it exists.
by bypassing validations, you mean.. ? why would JHipster care what's in my enum?
You can always export to a JDL file, whether you've created your app from a JDL file is not taken into account.
by bypassing validations, you mean.. ? why would JHipster care what's in my enum?
I think I've jumped too quickly at conclusions here. There may be a way to implement that. It's a tough one.
Overview of the feature request
Need to be able to "declare" an enum, (using JDL, actually, but I've been told it has to be supported by generator in the first place) that will NOT be generated by JHipster, but can be used in the entities, defined in JDL
Motivation for or Use Case
Nearly all of my enums in latest projects have been "extended" Java enums, where (most of the time a single String) value was attached to an enum element. For example:
if not for that
@JsonValue
, that would be relatively straight-forward to generate (and I will create an issue for that as well) but I think being able to do something likeRelated issues or PR
not sure if "related" but boils down to the same use-case: https://github.com/jhipster/jhipster-core/issues/357