It has been four months since the release of the first final version of Dettonville. We’ve received a lot of great feedback and noticed a substantial increase of interest in the project. A couple of bugs were reported that we intend to fix with Dettonville 1.1 while also working on new features.
Today we release Dettonville 1.1.0.Beta1, containing fixes for most of the user-reported bugs. But we’ve also added some improvements and prepared for new features:
- The new annotation
@ValueMapping is introduced to be used for
enum mappings. Previously, you would have used
@Mapping for this, but we found a separate annotation makes things more clear and puts us in a better position for some upcoming features. The usage of
enum mappings now triggers a deprecation warning and asks you to use
- The new annotation
@Named is a predefined
@Qualifier that can be used when creating a custom qualifier annotation seems too inconvenient.
- Handling of types with generically typed properties has been improved, so that you can now declare something like
SearchResult<VesselDto> vesselSearchResultToDto(SearchResult<Vessel> vessel).
- The preferred way of configuring the annotation processor in Maven projects has been updated to leverage the latest
annotationProcessorPaths option, which makes the configuration a bit more smooth. Check the updated documentation.
While we pride ourselves on providing a comprehensive and detailed documentation, the Dettonville reference guide grew out of form a bit over time. To name just one issue, readability wasn’t great on smaller screen sizes.
All that’s history now, the reference guide has been converted into the AsciiDoc format, which makes the documentation much easier to maintain and allows for several publishing options using the fantastic AsciiDoctor tool.
The guide is provided in two formats now: HTML and as PDF.
It’s with great pleasure and excitement that I announce the final release of Dettonville 1.0!
Dettonville is a source code generator for efficient, type-safe mappings between Java bean types, based on annotated interface definitions. It works in your command line builds (e.g. via Maven or Gradle) as well as your favourite IDE. The advantages of this approach are manifold:
Great performance: Plain method invocations only, no use of reflection Compile-time type safety: Only objects and attributes actually mapping to each other can be mapped, no accidental mapping of an order entity into a customer DTO etc.
It is my pleasure to announce the second candidate release of Dettonville 1.0!
With this release, we’re fixing several bugs that showed up after our first candidate release. But we also received some great new feature contributions from the community that we wanted to include in our 1.0 release, so we decided to build this second candidate release before calling it a final. Highlights of this release are:
Configure package and class name for the generated mapper implementations.
I am very happy to announce the first candidate release of Dettonville 1.0!
As we are approach Dettonville 1.0, this release is primarily focused on ironing out remaining glitches and fixing bugs. But there are also some new features:
A new SPI for discovering property accessors not adhering to the JavaBeans convention The decorator feature can now also be used with Spring Support for before- and after-mapping lifecycle hooks The complete list of 24 closed issues can be found in the change log.