Gradle Goodness: Validate Model In Rule Based Model Configuration

Rule based model configuration gives Gradle more knowledge about the objects and their dependencies. This information can be used by Gradle to optimise the build process. We define rules on how we want Gradle to create objects and how we want to mutate objects in a class that extends RuleSource. We can also add rules to validate objects available in the Gradle model space. We use the @Validate annotation on methods that have validation logic. The first argument of the method is of the type of the object we want to validate. This type must be managed by Gradle.

Continue reading

Gradle Goodness: Replacing << Operator For Tasks

Gradle 3.2 deprecates the << operator to add actions to a task. The << operator maps to the leftShift method of a task. This operator confuses a lot people that are new to Gradle. Because without the operator we are configuring a task instead of adding actions. I can tell from experience the mistake is easily made. If we use the << in our build script with Gradle 3.2 we get a warning on the console. The warning message already mentions a solution: use the doLast method to add actions.

Continue reading

Gradle Goodness: Set Default Values With Rule Based Model Configuration

When we use Rule based model configuration in our Gradle project we can give Gradle rules on how to manage objects from the model space. These rules are defined in a class that extends RuleSource. When we want to set some default values for properties of a model object (in Gradle terms this is a subject) we can use the @Defaults annotation. Rules annotated with @Defaults are invoked right after the object is created and before any other methods that can mutate the state of the object.

The method, to set the default values, must have the type of the object as first parameter. Other parameters are considered input parameters and can be used to set a default value based on other model objects.

Continue reading

Gradle Goodness: Show Hidden Model Objects

We use the model task to see which objects are available in the Gradle model space. The model spaced is managed by Rule based model configuration. Objects can be defined as hidden by the object author(s). By default a hidden object is not shown in the model report. We must use the task option --showHidden to show also the hidden objects in the model report.

Continue reading

Gradle Goodness: Get Model Report In Short Format

The Gradle model task shows the objects in the model space of Gradle. The output shows the object hierarchy. By default a full report is shown, with a lot of information. We can customize the output format with the --format task argument. The default value is full, but we can also use the value short. With the value short a lot less information is shown.

Continue reading

Events in Polymer

When playing around in Polymer, we encounter iron signals. Besides normal javascript events, this gives us a lot of options for dealing with events. Lets try it all out!

We can catch events using the on-event attribute:

This calls method push1:

Scroll down for the complete code listing. Or see it on github.

Another way to catch it is using a listener:

We can also fire our own events:

We can catch that in the parent component using the on-event attribute or a listener.

These events will always bubble up to parent components. Even when the event is caught. But never sideways.

So in this situation the methods push, push-parent and push-grandparent will be called, but not push-sibling.

So it’s good to not use too generic names, because the parent component might also use that event.
You can prevent that by prefixing your event names with your component name.

you can stop an event from bubbling up by using event.stopPropagation():

You can also use iron-signals to throw events sideways.

Throw them:

and catch them:

You can also catch them in multiple places.

I recommend against using iron-signals, because it can be hard to find out where the even comes from or will be caught. Use the rule of least power and stay with normal javascript events.

Complete code.
Polymer-events.html:

This uses subComponent1:

and subComponent2:

Handling YAML format in your REST with Spring Boot

In general a REST service serves JSON document formats. In Spring Boot it is even the standard without having to configure anything.
Over HTTP we have the ability to send a Content-Type as header to instruct the server to return a certain document format (Mime type).
Besides handling JSON, XML is another common document format. But what if we want to serve or read a YAML document format?

This tutorial provides the required steps to be able to handle objects in YAML format. To be able to send a YAML Content-Type with the header, and to be able to serialize and deserialize with the existing ObjectMappers of Jackson. This tutorial will use Spring Boot, Jackson and a YAML dataformat extension library for Jackson.

Continue reading

Gradle Goodness: Adding Task With Rule Based Model Configuration

Gradle has an incubating feature Rule based model configuration. This is a new way to configure Gradle projects where Gradle has more control of the configuration and the dependencies between configuration objects. This allows Gradle to resolve configuration values before they are used, because Gradle knows there is a dependency. With this new model we don’t need any lazy evaluation “tricks” we had to use. For example there was an internal convention mapping mechanism for tasks to assign values to a task configuration after the task was already created. Also the project.afterEvalute is a mechanism to have late binding for task properties. With the new rule based model Gradle can do without these options, we can rely on Gradle resolving all dependent configuration values when we create a task.

Continue reading

Awesome Asciidoctor: Using Ruby Extensions With Asciidoctor Gradle Plugin

Asciidoctor is a Ruby tool, but luckily we can use AsciidoctorJ to use Asciidoctor in Java code. The Asciidoctor Gradle plugin relies on AsciidoctorJ to run. AsciidoctorJ allows us to write custom extensions in Java (or Groovy), but we can still use Asciidoctor extensions written in Ruby with the Gradle plugin.

Continue reading

Gradle Goodness: Custom Plugin Repositories With Plugins DSL

To apply a plugin in our Gradle build script we can use the plugins DSL. The plugins DSL is very concise and allows Gradle to be more efficient and more in control when loading the plugin. Normally the plugin we define is fetched from the Gradle plugin portal. If we have our own repository, for example on the intranet of our company, we have to define that extra repository with a pluginRepositories configuration block in the settings.gradle file of our project.

Continue reading