Separate javaType into 'existingJavaType' and 'javaType'

At present javaType has two jobs, it can be used to reference an existing classpath type and also to give a newly generated type a fixed fully-qualified name. This was a bad design, for instance:

1. All ‘existing’ referenced classes need to be present on the classpath to avoid getting a new class generated, even though in fact there is no need to require them at generation time.
2. Sources are not regenerated if previous class files are not cleaned from the project, because it’s assumed that these types are ‘existing’ classes that are being used and should not be generated.

We should split these features, so that the schema author needs to be explicit.

[tviegut]

First off, great plugin. If this particular item has not been implemented yet, might it be possible to name it “existingJavaType”?

We use UML modeling toolsets that aid in auto-generating API JSON specifications which in turn we then leverage jsonSchema2Pojo durings builds. We’ve experienced with other jsonSchema2Pojo extensions that deviate a bit from the “norm” that the extension can be improperly named to what seems intuitive which doesn’t get picked up in our build process.

One example is the existing feature for “extendsJavaClass” extension that the plugin supports. It never fails that periodically it will get declared as “extendsJavaType” (which does seem to make logical sense as an extension of “javaType”) but the resulting POJOs don’t pick it up and it takes another cycle to fix. Maybe a wish here…but if the plugin supported both “extendsJavaClass” for backwards compatibility as well as “extendsJavaType” perhaps it would eliminate this for anyone who’s perhaps has also encountered it.

In any event, just throwing out thoughts from day-to-day experience.

[joelittlejohn]

@ajayboseac This change was introduced in 1.0.0-alpha3. Check the CHANGELOG.md (and the ‘Milestone’ field on this issue).