Configure interfaces for generated top-level classes

[jrehwaldt]

Add configuration to add interfaces to all top-level generated classes.

This depends on gh-917 in order to know if a rule is applied top-level or sub-level.
Alternatively, if gh-906 is fixed by providing sub-schemas for sub-levels
this could be used to check nesting.

Fixes gh-909, depends on gh-917.

[joelittlejohn]

Could you explain what is meant by 'top-level' and 'base' classes? Is the change proposed here functionally equivalent to adding this:

"javaInterfaces": ["com.foo.Bar", "com.baz.Qux"]

to all of your schemas?

[jrehwaldt]

The change is equivalent to adding these attributes to the schema file itself. Top-level means files in schema folder resulting in a class or enum, e.g. like adding Event interface to all processed event definition files.

I know I can add these properties inline in my schema, but in a project with many consumers in different languages this is not really desired. Nonetheless, I understand if you think this requirement is wrongly scoped, not working out or just not useful enough.

[joelittlejohn]

I definitely think this is a useful change, I just wanted to clarify a couple of things.

I think, as I understand things, the words 'base' and 'top-level' aren't necessary here. I also think that we should split the interfaces for classes from the interfaces for enums (because a lot of people will only use the former).

Could we rename these config options to:

additionalInterfacesForClasses

additionalInterfacesForEnums

?

[jrehwaldt]

Sure thing.

Q: Should we maybe drop the support for Enum interfaces completely, because as you say it is probably not used?

[joelittlejohn]

Okay, let's go with additionalInterfaces and we can add additionalInterfacesForEnums later if this is ever needed in future.

[jrehwaldt]

I squashed and rebased this commit and applied the changes.

[joelittlejohn]

I think your decision to limit this to the top-level types is highly specific to the way you use this plugin and I fear that this isn't generalisable in the way that it would need to be to include this setting in the core.

You're raising a lot of PRs that related to crafting Java types exactly as you want them. The goal of this tool is to generate classes that can work with data-binding, not to satisfy everyone's individual preferences regarding how they would like Java types to be if they were written by hand. We end up supporting a huge number of configuration options and there's combinatorial explosion in possible configurations and also bugs. Given the wide variety of PRs you're raising, it may be better for you to simply maintain your own fork of this tool to use within your organisation.

[jrehwaldt]

I do see a use case to have interfaces such as interface Identifiable { Long getId(); } on top-level classes, which are not specific to my case. Also, marker interfaces are a used pattern. I haven't been able to find a use case where interfaces on nested objects might be used.

Having said that, I understand your concern. While disagreeing with your premise in this case I do understand that you are not going to merge some of my proposals. That's fine. And that's the reason I raised issues first, which, imho, were mostly ignored.

I am always a friend of contributing back instead of just running an own fork without at least trying. Thank you for your support.

[lucjross-favor]

I would have found this very handy today.