DEV-NOTES|Gradle: Reading Eclipses codeformatter xml file

This little code snippet transforms the code formatter XML description file into a properties structure which could be applied to the JDT properties later on.

def initializeFormatter() {
  def formatterDefinitions = new XmlSlurper.parse("$rootDir/misc/codeformatter.xml")
  assert formatterDefinitions instanceof GPathResult

  def Properties props = new Properties()

  formatterDefinitions.'**'.findAll{ node ->
    node.name() == 'setting'
  }*.each { n ->
    props.put(n.@id.text(), n.@value.text()
  }

  return props
}

DEV-NOTES|Gradle: Injecting project version and Jenkins build number into project resources

Gradles project model provides a consistent way of expressing a version of an artifact. The following task uses the version number and makes it accessible to application code. Furthermore it adds the number of the build given by the Jenkins CI server.

/**
 * Read the version number from gradle (multi-) project definition
 * and add the build number from Jenkins-ci if available, otherwise use "IDE"
 */
task injectVersion << {
    def lineSep = System.getProperty("line.separator", "n")

    def file = file("$sourceSets.main.output.resourcesDir/version.properties")
    file.newWriter().withWriter { w ->
        w << "version=" << rootProject.version << lineSep
        w << "buildNumber=" << (System.getenv("BUILD_NUMBER") as String ?: "IDE") << lineSep
    }
}

// the inject version task requires the output folders to be already created
injectVersion.mustRunAfter processResources

// the version properties file have to be added to the classpath resource
classes.dependsOn injectVersion

It is worth to notice that the inject version task relies on the existence of the resource output directory from the „main“ source set. Therefore it is not allowed to run before the processResources has been completed and it depends on the classes task.

Someone might consider extending the processResources task putting the version.properties file creation into the doLast step like:

processResources.doLast {
    def lineSep = System.getProperty("line.separator", "n")

    def file = file("$sourceSets.main.output.resourcesDir/version.properties")
   file.newWriter().withWriter { w ->
        w << "version=" << rootProject.version << lineSep
        w << "buildNumber=" << (System.getenv("BUILD_NUMBER") as String ?: "IDE") << lineSep
    }
}

This works well except for changing numbers without cleaning, because gradle could not decide whether the build number has changed or is still unchanged during its configuration phase.


References

DEV-NOTES|Gradle: Use gradle wrapper with self-signed / organization local certificates

Automated provisioning of the required build environment is one of the great promises by gradle. Using gradle wrapper allows the rapid workspace setup for a new developer or on a new machine.

In organizations there are sometimes restrictions in accessing public networks and it local hosting becomes inevitable. The actual example is based on the idea hosting the gradle distribution inside the local document management system which is accessible using https only.

# gradle-wrapper.properties
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

distributionUrl=https://provisioning-url/gradle-2.2-bin.zip

Unfortunately the server identity is assured by a self-signed resp. signed by a local authority certificate. Running the gradle wrapper screws up yielding the following exception:

&lt;br /&gt;&gt; gradlew tasks
Downloading https://provisioning-url/gradle-2.2-bin.zip

Exception in thread &quot;main&quot; java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:78)
        at org.gradle.wrapper.Install.createDist(Install.java:44)
        at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:126)
        at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:58)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1884)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1341)
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java
:185)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1300)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
        at org.gradle.wrapper.Download.downloadInternal(Download.java:56)
        at org.gradle.wrapper.Download.download(Download.java:42)
        at org.gradle.wrapper.Install$1.call(Install.java:57)
        at org.gradle.wrapper.Install$1.call(Install.java:44)
        at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:65)
        ... 3 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
        at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
        at sun.security.validator.Validator.validate(Validator.java:260)
        at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
        at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
        at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1323)
        ... 19 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:196)
        at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268)
        at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
        ... 25 more

The problem is that the HTTPS connection could not be validated because there is no trusted certificate for the provisioning url available.

The solution is to enhance the truststore with the certificate or the authority used in the provisioning url:

#create or copy an existing truststore eq. form jdk
&gt; cp $JAVA_HOME/jre/lib/security/cacerts certs.jks
# import your certifiact into certs.jks
&gt; keytool -importcert -file self-signed.pem -keystore certs.jks

and tell gradlew to use this truststore instead of the original one. Gradles behavior can be adjusted by modifying the gradle.properties file in the root directory of your gradle project (for more information see „The Build Environment“ from the user guide).

# gradle.properties
systemProp.javax.net.ssl.trustStore=certs.jks
# could set password as well
# javax.net.ssl.trustStorePassword=changeit

Calling gradlew again should kick off downloading the gradle distribution and running your tasks like a charm.


Update 27/10/2016

Changed password property to match the truststore. Thanks to Thomas for his advice.

Book Review|Mastering AngularJS Directives

1588OS_Mockupcover_normal

Mastering AngularJS Directives“ by Josh Kurz is a deep dive into the magic of writing directives using the AngularJS framework by Google. This review is based on the eBook which was amply sponsored by Packt Publishing. The book is divided into nine chapters on roughly 200 pages.

„Book Review|Mastering AngularJS Directives“ weiterlesen

DEV-NOTES|SoapUI: Run random tests in a load test

Sometimes it is useful to set up a SoapUI test for simulating different usage scenarios randomly. The following solution provides a random selection from prepared test steps resulting in a different behavior of the tested service. „DEV-NOTES|SoapUI: Run random tests in a load test“ weiterlesen

Fixing Aftershot Pro 2 X64 update dialog on ubuntu 14.04

Aftershot Pro X64 starts with an information dialog that there is a new version available, but after hitting on the given links nothing happens. Starting Aftershot from the command line shows up that there is some problem with the Mozilla XUL library and the Aftershot provided libstdc++.so.6 lib. Instead of using the system default library, it relies on the delivered version. This could be easily fixed by removing any read access right on the symbolic link target:

cd /opt/AfterShotPro2\(64-bit\)/lib
chmod -r libstdc++.so.6*

Afterwards the links are working and refer to the download location for the new version.

Book Review|Scala for Java Developers

Thanks to Packt Publishing I have got a free ebook copy of „Scala for Java Developers„.

Preface

All Java code samples are covered by the features of the Java language specification whereas the upcoming functional extensions of Java 8 are not part of the discourse.

Review / Summary

The book “Scala for Java Developers” by Thomas Alexandre is an introduction to the Scala language from a Java Developers perspective. It does not explain basic programming paradigms like object orientation beside a very small wrap up of the functional paradigm as it might not be well known to every Java coder. The book is organized into 10 sections which should be read in order and mostly build upon each other.
„Book Review|Scala for Java Developers“ weiterlesen

DEV-NOTES|AngularJS: Global fault handler

„Dev Notes“ is a small column about practical hints on certain problems or solutions taken from real world applications.

AngularJS is a great framework simplifying the development of JavaScript applications. The following example shows how to setup a global error handler to notify the user about the applications state.

fault-handler_sampleTo benefit from angulars super powers the global fault handler part visible to the user is encapsulated into an angular directive which is an easy but powerful way to enhance the HTML tag cloud with your own components. Building the handler involves roughly the following steps:

Note: For those who are not fluent in CoffeeScript the code can be ‚compiled‘ to JavaScript on the CoffeeScript homepage using the ‚Try CoffeeScript‘ tab.

  1. Add global fault handler and clear method
    app.run ($rootScope, $log) ->
      ###
      # fault handler
      ###
      $rootScope.faultHandler = (data) ->
        $log.debug "[faultHandler] error data[#{data}]"
        # handle and process error data here
        # assign error message to global fault message
        $rootScope = "ERROR: #{data}"
    
      ###
      # clear fault
      ###
      $rootScope.clearFault = () ->
        $log.debug "[faultHandler] clearing fault[#{$rootScope.errorMessage}]"
        $rootScope.errorMessage = undefined
    
  2. Create custom tag to include the error handler
    'use strict'
    
    angular.module('myApp')
      .directive('errorMessages', () ->
        template: "<div class='alert alert-danger' data-ng-show='errorMessage'><strong>Achtung:&nbsp;</strong><span data-ng-bind='errorMessage'></span></div>"
        restrict: 'E'
      )
    
    
  3. Refer to fault handler
    'use strict'
    
    angular.module('myApp')
    .controller 'UserprofilCtrl', ($scope, $rootScope, $log, UserProfilService) ->
        $scope.profil = $rootScope.user
    
        # query userprofile by UID
        result = UserProfilService.get({id: $scope.profil.uid})
    
        result.$promise.then (profil) ->
          $scope.profil = profil
          $rootScope.clearFault()
        .catch $rootScope.faultHandler
    
  4. Use it
    <!-- include the following place holder tag into your page -->
    <x-error-messages></x-error-messages>
    

Quick tip: Running Sonarqube on a Synology Diskstation DS214play

The Synology Diskstation DS214play is an Intel based NAS device with 1GB of RAM. It provides a MariaDB and Java support nearly out of the box, both packages are installable using the systems own package manager.

Sonarqube is an ‚continuous inspection‘ formulator providing insights in your code and assuring quality metrics. It is an open platform for managing your code quality which could be enhanced by various plugins for different languages, code metrics and reports.

To install Sonarqube on the DS214play just download thelatest release (at time of writing 4.1.2) from the Sonarqube homepage and unzip it to a directory of your choice on the diskstation. Basically it is possible to run Sonarqube from that point, but it will yield some error messages due to the fact that the diskstation system supports only subset of the command options of a full flavored UNIX installation.

To get Sonarqube started with out error messages inside the gitpid function the pidtest expression must be replaced as shown in the following fragment (new version at line 19):

getpid() {
    if [ -f "$PIDFILE" ]
    then
        if [ -r "$PIDFILE" ]
        then
            pid=`cat "$PIDFILE"`
            if [ "X$pid" != "X" ]
            then
                # It is possible that 'a' process with the pid exists but that it is not the
                #  correct process.  This can happen in a number of cases, but the most
                #  common is during system startup after an unclean shutdown.
                # The ps statement below looks for the specific wrapper command running as
                #  the pid.  If it is not found then the pid file is considered to be stale.
                
                # not supported by the diskstation environment
                #pidtest=`$PSEXE -p $pid -o args | grep "$WRAPPER_CMD" | tail -1`
                
                # trying instead:
                pidtest=`$PSEXE | grep $pid | awk '{print($5)}' | grep "$WRAPPER_CMD" | tail -1`
                
                if [ "X$pidtest" = "X" ]
                then
                    # This is a stale pid file.
                    rm -f "$PIDFILE"
                    echo "Removed stale pid file: $PIDFILE"
                    pid=""
                fi
            fi
        else
            echo "Cannot read $PIDFILE."
            exit 1
        fi
    fi
}

Sonarqube should startup without any annoyance now, but the stop call will still complain. To fix this to it is needed to replace the second call to the ps command as well (new version at line 6):

testpid() {
	# diskstation cannot even handle the following command
    #pid=`$PSEXE -p $pid | grep $pid | grep -v grep | awk '{print $1}' | tail -1`
    
    #therefore replace with
    pid=`$PSEXE | grep $pid | grep -v grep | awk '{print $1}' | tail -1`
    
    if [ "X$pid" = "X" ]
    then
        # Process is gone so remove the pid file.
        rm -f "$PIDFILE"
        pid=""
    fi
}

Starting and stopping Sonarqube should now work like a charm and you can focus on the insights of your code.