Tuesday, November 8, 2016

Add custom Nexus Repository OSS to your Grails 3 Gradle build

After creating Grails 3 plugins and publishing them to your private/public Nexus Repository OSS server, you will want to use them in your projects. To use your custom Grails 3 plugins just add the following closure block to the repositories closure in build.gradle:

As with previous examples, NEXUS_USERNAME and NEXUS_PASSWORD are project parameters that you can store in file or pass on the command line.

Publishing Grails 3 plugins to Nexus Repository OSS using Gradle

To publish a Grails 3 plugin to Nexus Repository OSS is extremely simple because the necessary Gradle plugin is already included in the build.gradle file by default. Just add a publishing closure to the build.gradle file and you are ready to push to your private Nexus Repository OSS server.

As in the Grails application publishing example, the NEXUS_USERNAME and NEXUS_PASSWORD keywords are parameters that you store in and can overwrite with command line parameters, such as

** Edit **

Per Amad's comments, the grailsPublish closure may be required. I modified the attributes in the closure supplied by the create-plugin script as follows:

Publishing Grails 3 applications to Nexus Repository OSS using Gradle

To publish a Grails 3 application to Nexus Repository OSS you just need to make a few tweaks to the build.gradle file.  Just add the Gradle maven-publish plugin and a publishing closure to the build.gradle file and you are ready to push to your private Nexus Repository OSS server.

Above, the NEXUS_USERNAME and NEXUS_PASSWORD are parameters that you store in and can overwrite with command line parameters, such as

Tuesday, June 21, 2016

Angular 2 Exceptions: TypeError: Cannot read property 'annotations' of undefined

After playing with the newest incarnation of the Angular 2 Router (version 3.0.0-alpha.7) on a seperate test branch, I came back to my mainline branch and cleared my node_modules, build, tmp, and typings directories just to be safe. After reinstalling my npm modules (npm install), I received this gem, "TypeError: Cannot read property 'annotations' of undefined". Knowing that it was working prior to creating my test branch, and after some frustration examined the error a bit closer and saw that the html template causing the issue was related to the the routerLink directive, or more generally the Angular Router package. Digging into it a bit more I discovered that my npm semver for @angular/router-deprecated was "^2.0.0-rc.1" instead of "2.0.0-rc.1" and therefore was installing the Angular 2 RC-2 version of the deprecated router and was causing the error. After correcting the package, more specifcially the semver, for router-deprecated to 2.0.0-rc.1 and re-running npm install, all was well with the world.

The full exception is:

Friday, June 17, 2016

Angular 2 Exceptions: TypeError: (msg || "").replace is not a function

While performing tdd using the Angular CLI, I have come across this exception a few times. In most cases this is caused by a missing import.  The Angular CLI kicks off a test before an import has been added to the component (or service, etc).  If you have the benefit of an IDE, check that it has not highlighted a problem with one of your imports.

The full exception is:

Tuesday, April 5, 2016

Grails 3 war file naming issues in Jenkins

Correcting the war file/artifact/package name in grails package

By default my Jenkins build server puts its projects into a directory called 'workspace' so when I run grails package it creates a war/jar called workspace-0.1.war/jar.  In order to generate the correct jar/war file name, you can create a file called settings.gradle in the root of the project with a single property and specify the name you would like:

and when you run grails package it will create the appropriate my-project-0.1.jar/war



Saturday, January 23, 2016

Spring Cloud - Config Server

Setting up the Spring Cloud Config Server

In this post we will be setting up a Spring Cloud Config Server to externalize configuration properties for future Grails 3 applications.  This will be a bare bones application without security for now.


The easiest method to get started is to create a Spring Boot application from the Spring Initializr and include the Spring Cloud Config Server.  I will be using a Gradle project and Spring Boot 1.3.2.  Enter your desired group (com.morkenbarware) and artifact (config) in the Spring Initializr and download a new project.

Spring Initializr


Configuration changes to this ConfigApplication will be pretty minimal as most of the default Boot application settings will be sufficient for now, but we do need to add an annotation and a few config settings to enable the configuration endpoints.


In order to enable the configuration endpoints that other applications will use, we need to add one annotation to the Application class (ConfigApplication) in the application.

Add the import import; and the annotation @EnableConfigServer to the Application (ConfigApplication) class as follows:

Configuration Settings:

Spring Cloud Config Server primarily uses Git repositories to store properties, so we first need to create a new Git repository to hold our application properties.

Create Local Git Repository (to hold our external properties)

In production this would probably be a web-based Git repo or at least a remote repo, but for simplicity, I will create a local repo to hold my configuration information.  I keep all of my development projects in a projects folder under my user directory, so my config repo will be in /home/me/projects/config.  In this directory, create a file or application.yml depending on your configuration preference.

In addition to the or yml file create another file called or example.yml depending on your configuration preference.
Once these two files have been created, commit the changes (git commit -am 'initial properties') to the Git repo.

By adding an file to the repo, any Cloud Config Client application that connects to this Config Server will receive these properties unless overriden by a more specific property/yml file.  In our case, when we specify:
 audit.config.source = cloud in the application.yml and
 audit.config.source = cloud example in the example.yml file,
if we create an application called example, it will receive "cloud example" because the example.yml file is more specific to that application. (application.yml > example.yml > example-production.yml)

Config Server Settings:

Next, we need to configure the actual Config Server Application.  We need to "connect" to our local Git repo using and expose the config server on the conventional cloud config port 8888 using server.port. Your should look like the following.

With that done... let's fire up the config server and see what we have accomplished.
./gradlew bootRun

After executing the gradle task, you should see a lot of output and eventually something that says:
Tomcat started on port 8888.  If you go to the running application and change the url to http://localhost:8888/example/development/ you should see two different property values for audit.config.source and if you go to http://localhost:8888/someapp/development/ you will only see one audit.config.source from that applies to all applications.

Next, we will create a Grails 3 application to connect to our Cloud Config Server and see how they work together.