Resolved instances don't know where their inheritance comes from. We will mark it in the model using a custom domain property or such

This should be helped with the migration of the builders.

This is because of subtypes are not handled correctly.

Faulty code is here

    private Shape findParentType(Shape typeDeclaration) {
        if (typeDeclaration instanceof NodeShape) {
            NodeShape otd = (NodeShape) typeDeclaration;
            return otd.inherits().size() > 0 ? otd.inherits().get(0) : otd;
        } else {
            return typeDeclaration;
        }
    }

This returns the wrong type.

Resolved specs leave ResursiveShapes in the mix when a class refers to itself in the properties. We need to fix that (as we fixed the unions?)

Cover requirements from jaxrs to raml

Some annotation not being added because of subtype calculations we now do.

I've seen some code JAXRS related but bare conversion to POJO does not seem to support additional properties. The following type:

types:
  salutation:
    type: object
    additionalProperties: true

Will generate the following POJO:

public interface Salutation {
}

public class SalutationImpl implements Salutation {
}

I'm also attaching a project to replicate: additionalProperties.tar.gz

Generated pojos have the import java.util.Objects; line. In the hashCode generated method, it uses Objects. But in the equals method, the code shows it is using java.util.Objects. This is just to clean that bit up.. remove the java.util. generated bits.

To avoid having to rename all the classes in libraries, develop a plugin that will repackage all classes generated from libraries.

If the builder migrate to AMF, everything that uses the builders should fall in line

mulesoft-labs/raml-for-jax-rs#414

When using a RAML that has for instance a response envelope:

myEnvelope that has some members in it, when creating a subtype, eg: EnvelopeForParticularResource it will generate enums and other types again, creating a change in the Java signature and therefore not compiling for the subtype.

See the following example project to reproduce raml-defined-example.tar.gz

As a dirty workaround I've been able to change the type: mylib.myType for an type: !include ... which does the trick but is a far cry from ideal.

I dont know if this is in place yet.. but because this tool generates the pojo methods, it would be beneficial that it could also generate modern day equals() and hashCode() methods (making use of Objects.equals() and Objects.hash()).

I think it's a nice idea to add a full constructor to the implementation classes, as changes in the raml file can be missed. By using a full constructor with all fields, changes in the raml will result in compilation errors, so there can't be uninitialized fields.

Make sure they work

Instaceofing everything has become problematic and fragile....

We want to support different inheritance models

I have RAML1.0 with traits , and when I use raml-to-pojo-maven-plugin and it fails with nullpointer exception @ org.raml.ramltopojo.CreationResult.java [Line #56]

Also , note the same RAML is working with raml-to-jaxrs-maven-plugin , Is it recommended to use raml-to-jaxrs-maven-plugin for client stubs ?

The generated equals code uses the approach of getClass comparison. According to Josh Bloch and elsewhere, the better approach is to use instanceOf:

https://www.artima.com/intv/bloch17.html

It also allows the remove of the null check at the start of the equals method:

The generated code should be something like:

@OverRide
public boolean equals(Object o){
if (this == o) return true;
if (!(o instanceof Other)) return false;
// call super.equals to account for any parent class equals impl
if (!super.equals(o)) return false;
Other other = (Other) o;
return Objects.equals(getSomething(), other.getSomething());
}

use the raml to allow for disabling the additionalProperties with the object "additionalProperties" facet.

The parsed model know which types are actually inline types. This is lost in the resolved model. Mark using custom domain properties. This will allow us to handle more types.

example generated RAML

#%RAML 1.0
title: 
    value: Integration API
mediaType: application/json
version: 
    value: 1.0

Aypoint studio 7.3 wants following format

#%RAML 1.0
title: Integration API
mediaType: application/json
version: 1.0

If I have:

types:
  Base:
    type: object
    properties:
      name:
        type: string
      phone;
        type: string

  Profile:
    type: Base
    properties:
      address:
        type: string
      country:
        type: string

I would expect raml2pojo to generate two classes (or in the case of interfaces and classes, 2 of each). Base interface/impl would simply be something like:

public class Base [
  private String name;
  private String phone;

  ... methods to get/set name and phone ...
}

public class Profile extends Base {
  private String address;
  private String country;

... methods to get/set address and country ...
}

However.. what Raml2Pojo is currently doing.. is it generate the base class (and it includes json property annotations..which I left out) just fine. BUT the Profile class while it extends Base it ALSO adds ALL the properties and methods of the parent. So instead of inheriting the name/phone properties/methods from the parent, it is re-implementing them.. thus defeating the purpose for extending the parent class.

Maybe I am missing something... but I would think that RAML type inheritance should only include the properties/methods for the specifically defined RAML Type, and inherit the methods/properties from the parents.

Change raml to pojo interface for that. Avoid retrieving from names.

They are being handled double: in the parent and child.

New plugin that will implement toString();

#%RAML 1.0
title: My API With Types
types:
  Person:
    properties:
      name:
        required: true
        type: string
      age:
        required: false
        type: number
      /somepattern/: # force all additional properties to be a string
        type: string

I have to check that jackson supports this (I think it does).
I have to support the additionalProperties facet correctly. (I always set to true now).

Currently, there are type collisions if libraries use the same names for types.

Going through the parsing would appear to be the right way to go. The builder's allow stuff that the parser does not build.

This can be done with inline strings.

The current buildLooksLike code verifies the document to deserialize contains all the properties (required and non-required) from the RAML object declaration. This causes the object identification (and thereby the deserialization) to fail if any of the non-required properties is missing from the response document.

By adding the following code only the mandatory properties are verified:

List<TypeDeclaration> mandatoryProperties = otd.properties().stream().filter(propertyTypeDeclaration -> propertyTypeDeclaration.required())
					.collect(Collectors.toList());

This results into code like the following (with no optional attributes in the containsAll):

    private boolean looksLikeMortgageAccount(Map<String, Object> map) {
      return map.keySet().containsAll(Arrays.asList("accountId","type")) && map.get("type").equals("MORTGAGE");
    }

AMF's parsing of arrays does not exactly correspond to the programmatic builders interface.

It's just a cosmetic thing really, but quite annoying.
This issue is due to this line:

Shouldn't you rather create a new NameFixer for this, that prepends an underscore in it's fixOthers method? Or maybe even change the ALL_UPPER name fixer to do that?
We recently upgraded from raml-to-jaxrs-maven-plugin version 1.3.4 to 3.0.4 and back then underscores were preserved in enum constant names. Or is there a specific reason for the way it works right now?

Why you'd want to do this is beyond me. But it's a case.

Probably not generate a type ?

The code generator for equals methods produces a self comparing statement, like
(this.field == field) for primitive types.

This has to be something idiotic :-)

Jackson has a special null value handler that should be overriden to return a result.

JsonDeserializer.getNullValue(DeserializationContext ctx)

The builders we have now are pretty flimsy. Make them better.

If you add SimpleEnum to the pojo-to-raml/src/test/java/org/raml/pojotoraml/Fun.java and run tests, it fails:

org.raml.builder.ModelBuilderException: model errors: Invalid reference 'SimpleEnum'
	at org.raml.builder.Util$2.apply(Util.java:129)
	at org.raml.builder.Util.buildModel(Util.java:62)
	at org.raml.builder.RamlDocumentBuilder.buildModel(RamlDocumentBuilder.java:108)
	at org.raml.pojotoraml.PojoToRamlImplTest.createApi(PojoToRamlImplTest.java:155)
	at org.raml.pojotoraml.PojoToRamlImplTest.simpleStuff(PojoToRamlImplTest.java:43)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

Is this expected behavior? This way I cannot convert any pojo, that contains Enum.

Currently, the regex pattern property, which is part of RAML for string types, is not being parsed and/or converted in to JSR303 validation annotations.

Annotations and such seem to be problematic (not uniform) with the rest of the objects, as are Facets (they may me extensions)

Getting a runtime exception in ramltopojo.Names class, joptsimple no such method found. I dont see anything about having to depend on that library, and even when I do add the maven dependency, it still fails.

java.lang.NoSuchMethodError: joptsimple.internal.Strings.join(Ljava/util/List;Ljava/lang/String;)Ljava/lang/String;

at org.raml.ramltopojo.Names.typeName(Names.java:61)
at org.raml.ramltopojo.object.ObjectTypeHandler.javaClassName(ObjectTypeHandler.java:41)
at org.raml.ramltopojo.object.ObjectTypeHandler.javaClassReference(ObjectTypeHandler.java:49)
at org.raml.ramltopojo.TypeDeclarationType.calculateTypeName(TypeDeclarationType.java:394)
at org.raml.ramltopojo.RamlToPojoImpl.buildPojos(RamlToPojoImpl.java:27)

Right now DeclaredType handles user types pretty well, but not scalar type names. They are null.

They should not.