Dogen v0.92.0, "Praia Amélia"

Praia das Miragens, Namibe, Angola. (C) Pearce. Sourced from Fans Share.

Overview

The sprint's headline feature is the completion of the JSON frontend. In the past, the JSON frontend was used solely to supply "proxy models" to Dogen - i.e. top-level type definitions for external libraries such as std and boost, required so that user models could consume external types.

With this release, we finally got the JSON frontend to provide the same level of support as the Dia frontend (modulus any undetected bugs). Note that Dia will remain the preferred frontend for Dogen's own development but - significantly - users are now free to choose their preferred frontend and are no longer required to install/use Dia in order to code-generate models.

As with everything else in Dogen, regrettably, the documentation is scarce. However, there are examples of JSON models in the JSON test data pack, which largely mirror the Dia test data pack.

Other user visible changes

• References are now supplied as part of the diagram rather than via the command line. This means you do not need to manually keep track of transitive references - you are only required to supply the models you directly depend on, and their references are automatically picked up. Use yarn.references to supply References via meta-data.
• External Modules are now supplied as part of the diagram rather than via the command line. This also means that references no longer require you to provide External Modules for each model that consumes them. Use yarn.dia.external_modules to supply External Modules in the Dia frontend, via meta-data. In the JSON frontend, use "external_modules": "X" directly. As always, Dogen's own Dia frontend models provide modeling examples as well as examples for the the corresponding dogen.knitter invocation.
• A new command line utility was added to convert Dia models into JSON models called tailor. It was added primarily to simplify the work on JSON support, but it may also be useful for users wishing to migrate frontends.
• We are now uploading binary packages to Bintray. At present we only upload Debs for Linux and DMGs for OSX. These packages are experimental. Any feedback is highly appreciated.
• Dogen no longer adds a trailing line in comments.

For more details see the sprint log.

Project Status

With this release, we have more or less implemented all the major architectural features we needed internally at Domain Driven Consulting, so we will focus more on using the product and fixing problems as we find them.

On the other hand, we have also successfully engaged a customer who requires C# support. It is likely that the next few iterations will focus on adding support for other languages.

Dogen v0.91.0, "Namibe"

Hotel Moçamedes, Namibe, Angola. (C) Maria N. Jardim, 2007. Sourced from BlogSpot.

Overview

With this sprint we have concluded the bulk of the work on internal refactoring. There were also a number of user visible changes:

• Integration of knit and stitch: its no longer necessary to run the stand alone executable to transform stitch templates; elements can be configured to run this automatically as part of knitting.
• Introduction of wale: in addition to stitch, a simpler type of templates was introduced.
• Stitch templates can make use of profiles: it is now possible to avoid duplication in stitch templates by creating profiles.

For more details see the sprint log.

Dogen v0.90.0, "Aida"

Aida, Namibe, Angola. (C) Ravid Cohen1, 2012. Sourced from Panoramio.

Overview

One more sprint of internal refactorings, leading us close to the end result. The focus continued on the quilt.cpp model.

There were still a number of user visible changes:

• introduction of profiles: meaning its no longer necessary to setup each facet's configuration on each diagram; users can create or reuse profiles.
• integration of stereotypes with profiles: it's now possible to annotate an element with a stereotype and, if a profile with the same name exists, dogen will apply the profile to the element.
• deprecation of the service stereotype: it has been replaced by handcrafted. With this change we now generate class skeletons for hand-crafted code.
• mixing of hand-crafted and generated code code is now possible at the element level: if a hand-crafted element declares a number of attributes and marks the IO facet as overwritable, dogen will generate IO support (and serialisation and so forth) for this element.
• rename of a lot of the meta-data tags: removed the postfix _formatter.

For more details see the sprint log.

Title: Dogen v0.89.0, "Cubal"

Aida, Namibe, Angola. (C) SkyTrax. Sourced from SkyScrapperCity.

Overview

The refactorings continue, mainly focusing on the quilt.cpp model but with changes all over the code base. The only user visible change is:

• improvement on visitor inclusions for descendants.

For more details see the sprint log.

Dogen v0.88.0, "Caraculo"

Estação do Caraculo, Namibe, Angola. (C) João M. Neto, 2013. Sourced from Panoramio.

Overview

We continue our long road of internal refactorings, focusing on the quilt.cpp model. There are no user visible changes in this release.

For more details see the sprint log.

Dogen v0.87.0, "Cambongue"

Ruins in the outskirts of town, Namibe, Angola. (C) Luis Abegão, 2007. Sourced from Panoramio.

Overview

This release is still mainly focused on internal refactorings of both the yarn and quilt.cpp models, but added a couple of user visible features:

• Support for cross-model inheritance: it is now possible to inherit types from referenced models. In addition, if the parent type was visitable, an "augmented" visitor is generated that takes into account the new derived types.
• Performance improvements: due to the changes required for cross-model inheritance, the overall performance of the code generator has gone up a bit; finger in the air measurements reveal its taking 60-50% of the time to generate the dogen models.
• Visitor's accept methods have been moved to the cpp file: in the past, adding a new descendant to a visitable parent resulted in large rebuilds because the parent included the visitor and the visitor had to change to accommodate the new descendant. Thus, all code that depended on the parent would get rebuilt. To avoid this, the accept methods have now been moved to the cpp file, resulting in smaller builds. We are also now using forward declarations in the visitor.

For more details see the sprint log.

v0.86.0

Sprint 86

v0.85.0

Sprint 85

v0.84.0

Sprint 84

v0.83.4499

Sprint 83