Skip to content

Latest commit

 

History

History
44 lines (28 loc) · 2.72 KB

readme.md

File metadata and controls

44 lines (28 loc) · 2.72 KB

Sundrio Java Model

There are multiple ways java types are represented. To name a few:

  • Source
  • Reflection
  • Annotation Processing
  • 3rd party libraries

The sundrio model is a simple, abstract, fluent way of describing / generating java types. All model related classes can be under io.sundr.model. Below a description of the basic types is provided:

Terminology

All code is usually included in source file (io.sundr.model.Source). A source may contain one or more types definitions (io.sundr.model.TypeDef), which are usually classes, interfaces or enums. Each definition may contain a couple of methods (io.sundr.model.Method) and classes may also contain fields/properties (io.sundr.modle.Property). All types may also contain nested types (io.sundr.model.TypeDef).

Each property has usually two parts a name and a type. The type is never provided inline (is usually defined seperately), so in practice we have a type reference (io.sundr.model.TypeRef).

Type refernces are also used to in refering to super classes, interfaces, method return types and so on ... Such references may refer to:

  • Primitive types (io.sundr.model.PrimitiveRef).
  • Classes (io.sundr.model.ClassRef).
  • Generic types / Type parameters (io.sundr.model.TypeParamRef).

When it comes to generics we also have the ? opertor which is usually represented as wildcard ref (io.sundr.model.WildcardRef).

References may also have dimensions (when we have references to arrays), and type arguments. Type arguments may be provided for types (io.sundr.model.TypeDef) that have type parameters (io.sundr.model.TypeParamDef).

Understanding the structure

  • Module base contains the domain model
  • Module generator is generating the fluent builders
  • Module builder contains the generated code (the output of generator) and depends on the base.

We deliberately avoid using the generator module as a dependency, because itself depends on earlier versions of sundrio and it would pollute the reactor. So, instead we copy the generator output inside the builder, which is cleaner.

Generating the Model

As mentioned in the previous section the fluent builders are generated by the generator module and the generated code is copied into the buidler module. This is something that needs to be performed manually by calling make build in the current folder. In other words, when a change in the model that affects the model is performed, a make is required and the generated code needs to be committed. Note: The release process will NOT generate the model. It assumes that all changes to the builders have been already committed prior to the release. Pull requests that cause changes to the builders need to also include those files.