Major feature of Gradle is extensibility. Developer can store common logic in a custom task class.

class GreetingTask extends DefaultTask {
    String greeting = 'hello from Y Soft'

    @TaskAction
    def greet() {
        println greeting
    }
}

task hello(type: GreetingTask)

// Customize the greeting
task greeting(type: GreetingTask) {
    greeting = 'greetings from Brno'
}

It’s not very flexible approach. All classes and the build logic are stored together in one build.gradle file.

It’s possible to move classes into separate Groovy files in buildSrc. Here is the description of transformation process.

Step 1. Create directory buildSrc/main/main/groovy/PACKAGE. E.g.: buildSrc/src/main/groovy/com/ysoft/greeting.

Step 2. Move custom class from build.gradle to GreetingTask.groovy in buildSrc/…/greeting directory.

Step 3. Add package declaration and imports from Gradle API to GreetingTask.groovy.

package com.ysoft.greeting

import org.gradle.api.DefaultTask
import org.gradle.api.tasks.TaskAction

class GreetingTask extends DefaultTask {
    String greeting = 'hello from Y Soft'

    @TaskAction
    def greet() {
        println greeting
    }
}

Step 4. Update build.gradle, add groovy plugin and import of the custom class.

apply plugin: 'groovy'

import com.ysoft.greeting.GreetingTask

task hello(type: GreetingTask)

task greeting(type: GreetingTask) {
    greeting = 'greetings from Brno'
}

Alternatively you can use full package name with class name when specifying task type. In that case you can omit import.

Step 5. Type ‘gradle tasks’ and enjoy.

You can find examples of custom tasks at our GitHub.

Probably every programmer knows switch-case keywords. They are often used to convert data, e.g. some string from another (sub)system to your enum. While working with those, I found two patterns I call best practices.

The first one uses return outright. Its code is short and elegant:

transformGender(String gender) {
    switch(gender) {
        case "M": return Gender.MALE;
        case "F": return Gender.FEMALE;
        case "I": return Gender.INTERSEX;
        default:  return Gender.UNKNOWN;
    }
}

However, some might argue it doesn’t follow the single-exit pattern. If you happen to add e.g. logging, it makes it complicated. Since copy-pasting code would make it a direct opposite of what you were trying to do there, a different pattern should be used. I found one:

transformGender(String gender) {
    final Gender result;
    switch(gender) {
        case "M": result = Gender.MALE;
                  break;
        case "F": result = Gender.FEMALE;
                  break;
        case "I": result = Gender.INTERSEX;
                  break;
        default:  result = Gender.UNKNOWN;
    }
    return result;
}

Obviously, the price for single exit is a longer code (breaks, storing the value). However, it still keeps one advantage of the previous pattern (the basic Java tutorial doesn’t teach it): You can be sure your result is not modified, thanks to final keyword. If you fail to write the value exactly once, a compiler error warns you instantly. Also, it makes it hard to write messy code with preset value and no default branch.

I was curious if the pattern can be used in C#, but it seems it can’t. The keyword final has no equivalent in C#, with readonly not really working in the same manner. Where readonly states that it can only be written in constructor or declaration, final means that the field or variable can only be written once.

Let me invite you to a next Technology hour, which will be kind of a special. This time, we are very pleased to host Mark Seemann, who accepted our invitation. Mark is a seasoned developer, known primarily in .NET community as an author of Dependency Injection in .NET, however, he is also a long time blogger at http://blog.ploeh.dkpluralsight author, international speaker and open source developer.

When I said this time will be special, it is because this will be the first topic primarily focused on .NET platform, which is a platform I spent the most of my professional life as a developer so far. And Mark had a great influence on how I write the code today.

Mark will be talking about Equivalency classes, as a way to think about inputs for your functions and how can you leverage that in TDD. This concept is more commonly referred to as Property-based testing and Mark is going to show you both, general concept, as well as tools which you can use in .NET development. The samples presented here will be written in F#, using primarily FsCheck testing library. But don’t worry, no prior F# knowledge is required. If you are C#, Java, or Scala developer, you’ll be fine.

So, you might be thinking right now, is this going to be interesting for me, when I am, say, Java developer or Scala or Ruby? Sure, it is! Property-based testing is now a hot topic, not only in functional world and Mark is really great in explaining things, simply but accurately. And with the knowledge and examples gathered on this TH you can then apply them on your particular platform of choice.

So, if you are still deciding whether or not to come, I would really encourage you to visit us and RSVP at, I hope by today, well known place http://www.meetup.com/ysoft-th/events/219802203/. As usual, after the talk, there will be a bit to eat, something to drink and a lot to talk about. See you there.

Sometimes you may need to setup Continuous Integration server to build VS solutions without installing VisualStudio there. But MSBuild is not able to build all solution, you’ve created on your local machine.

The first error you can start getting will be something like:

The imported project ” C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WCF\ Microsoft.VisualStudio.ServiceModel.targets” was not found.

Solution is quite simple:

  • Copy targets from your local machine to MSBuild folder on CI server.

Unfortunately this doesn’t solve all problems. MSBuild will keep throwing exceptions. This time it will be about missing dll:

Could not load file or assembly ‘Microsoft.VisualStudio.ServiceModel.Core, Version=11.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies.

This time solution will require few more steps:

  • Find the missing dll on your local machine and copy it to the same location on your CI server. It can look like “c:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Microsoft.VisualStudio.ServiceModel.dll”.
  • Install this dll into GAC: open “Developer Command Prompt for VS2013”, go into directory with dll and register it to the GAC using command “gacutil.exe -i Microsoft.VisualStudio.ServiceModel.Core.dll”

gac

When all these steps are done, MSBuild will be able to build your solution successfully.