Separate javaType into 'existingJavaType' and 'javaType'

[joelittlejohn]

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.

[tviegut]

Thanks!!

[joelittlejohn]

Benefits I think we'll get after implementing this:

1. People can use existingJavaType to reference a class even if that class is not on the classpath

2. People can re-run their build without having to 'clean', because the generated output will not depend on the current state of the classpath

[tviegut]

Yes, this is a big plus for us. We've observed the limitation that you're calling out in resolving our own existing classes within our gradle builds. So needless to say, when we caught that this was going to be in this next release we were pleased.

[pnmalav]

It seems the feature of "existingJavaType" already works if we specify only "javaType" and no "type".

{
  "type":"object",
  "properties": {
    "baz": {
      "javaType": "my.Custom"
    }
  }
}

[joelittlejohn]

@pnmalav yes, that's right. javaType currently allows you to either create new classes or reference existing classes from the classpath.

In the next release, you will use javaType to give a specific name to a new class. If you want to refer to an existing class, you will use existingJavaType.

[pnmalav]

@joelittlejohn the example I provided works even if my.Custom is not in classpath. There is no Custom class created, unless I specify "type":"object".

This will create a Custom class as well

{
  "type":"object",
  "properties": {
    "baz": {
      "javaType": "my.Custom",
      "type": "object"
    }
  }
}