Added support for enum with custom constructor

[cvgaviao]

eclipse-vertx/vertx-codegen#295

Signed-off-by: Cristiano V. Gavião [email protected]

Motivation:

Explain here the context, and why you're making that change, what is the problem you're trying to solve.

Conformance:

Your commits should be signed and you should have signed the Eclipse Contributor Agreement as explained in https://github.com/eclipse/vert.x/blob/master/CONTRIBUTING.md
Please also make sure you adhere to the code style guidelines: https://github.com/vert-x3/wiki/wiki/Vert.x-code-style-guidelines

[cvgaviao]

@vietj, it is ready and I also added some tests

[vietj]

I think we need the test to be in codegen TCK and have an implementation for vertx-rx as well.

[cvgaviao]

I think we need the test to be in codegen TCK and have an implementation for vertx-rx as well.

@vietj , there is no use of any enum in the rx codegen projects, I run it's building and all tests have passed.

So, why this and vertx-codegen PR for custom enums should wait for vertx-rx?

[vietj]

there should be an example in TCK that uses an enum mapped with a mapper and the vertx-rx should handle it fine (I think there is nothing to do) but nevertheless such test should be in TCK, because some other impls like ES4X will need this.

…

On 5 Jun 2020, at 14:20, Cristiano Gavião ***@***.***> wrote: I think we need the test to be in codegen TCK and have an implementation for vertx-rx as well. @vietj <https://github.com/vietj> , there is no use of any enum in the rx codegen projects, I run it's building and all tests have passed. So, why this and vertx-codegen PR for custom enums should wait for vertx-rx? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#115 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABXDCUJXOIZKOSNZOKS5HLRVDPJRANCNFSM4NNBIRTQ>.

[cvgaviao]

there should be an example in TCK that uses an enum mapped with a mapper and the vertx-rx should handle it fine (I think there is nothing to do) but nevertheless such test should be in TCK, because some other impls like ES4X will need this.

Well, I think I did it.