Jenkins walldisplay version 0.6.29

It has been some time since the last Jenkins walldisplay plugin release, thanks to numerous contributors a bunch of new features and bugfixes have been added in the meantime:

  • Bug fix – JENKINS-26873 Sorting by Status does not work correctly
  • Bug fix – JENKINS-26745 : fix javascript error on undefined object
  • New Feature – The gravatar URL can now be configured in the plugin configuration
  • New Feature – The Junit result display can be switched of now
  • New Feature – Jenkins display name feature is used for job name display

A screenshot of the configuration page for the plugin shows most of the current features:
walldisplay_0.6.29_1

See here for a live Demo or the screenshot below for the current state:

Jenkins Wall Display  All

By |March 25th, 2015|Uncategorized|

Jenkins GitHub issue updater

For GitHu hosted project that is continuously built using Jenkins I needed the build number in every GitHub issue that was mentioned in the commits that were part of the build, or in other words:

“Scan the commit comments for numbers and check on GitHub if these numbers refer to an issue. If so comment the issue with build information from the running build.”

Quite unusually for Jenkins I couldn’t find a plugin performing this task but thankfully to Jenkins and GitHubs public APIs this problem was easy to solve. The following script need information about the Jenkins server (which build, what build number, etc.) and the GitHub user and repository to match against. Because the script is meant to be run within a Jenkins build, it tries to determine the Jenkins server url, job name and build number from the well known Jenkins environment variables (JENKINS_URL, JOB_NAME and BUILD_NUMBER). An optional security token as well as all GitHub information can be passed as command line parameter, call the script with --help for a overview of the parameters:

help output

If invoked the script will dump its configuration (without the security tokens) and log some information while parsing the commit messages:

example script run

The source code is available on GitHub in form of a gist:

By |March 9th, 2015|development, jenkins|

Mango persistence services

Because Mangos persistence services may not be self explaining on the the first glimpse this post tries to put some light into this topic:

Two low level services provide basic persistence functions for entities/value objects, the IBaseEntityDAO for entities and the IBaseVODDAO for value objects (these two are nearly identical, in fact they are derived from the same basic service interface just with different generic types for entities/value objects).

The IBaseVODAO internally copies the data from/to the entity/value object using the copy service. Despite the fact that one the server you are free to use entities/value objects or both, it is advisable to always use the value object based IBaseEntityService as you would from any client side code. The IBaseEntityService provides some higher level persistence functions as well as validation based on the datatype metadata.

mango_entity_services1

As IBaseEntityDAO and IBaseVODDAO provide generic persistence functionality for all entities or value objects you may want to add specialized persistence behavior for your own entities or value objects. This can be achieved be registering an entity/value object specific EntityDAO/VODAO.

For each entity an basic Base{entity name}EntityDAO/Base{entity name}VODAO is generated. This default implementation defaults to the normal entity/value object DAO behavior. You can override this default implementation to add your own business logic.

entity DAO example

To create a new entity specific DAO extend the generated BaseDAO for the entity:

and register the DAO in your Spring application context:

By |March 5th, 2015|development, gwt, mango|

The Mango framework in three minutes

A screencast showing the key features of the Mango framework for web applications in three minutes.

By |February 25th, 2015|development, gwt, mango|

New feature: Entity webhooks

Mango already offers numerous APIs (SOAP Webservices, REST and plain XML) to access the data contained in an application but to get the data you have to actively ask the application for the data. A new feature resembling the well known webhooks from Github lets you register callback URLs that get triggered with HTTP post requests when certain events occur, for example the creation of a new country entity.

From Wikipedia

Webhooks are “user-defined HTTP callbacks”. They are usually triggered by some event, such as pushing code to a repository or a comment being posted to a blog. When that event occurs, the source site makes an HTTP request to the URI configured for the webhook. Users can configure them to cause events on one site to invoke behavior on another.
Webhooks can be either registered using a REST Api or alternatively using a UI that is included in Mango.

example entity webhook registration

When a webhook is triggered for example when a new entity is created, the request body of the following post request to the webhook URL looks like this:

example request body for an entity ON_CREATE webhook event

list entity webhooks example

delete entity webhook example

Of course all of the above can also be done using the webhook UI webhook UI mango_entity_webhooks1

A running example is as always contained in the Showcase, more information in the documentation.

By |February 18th, 2015|development, gwt, mango|

New feature: Entity REST API

A still experimental but already working feature is the entity REST API. For all modeled entities a REST API is generated supporting the retrieval of entities by id/natural key or even a custom query. The API overview page is can be reached from the entity editor.

API overview page mango_entity_api1

load by id example

$ curl http://mango-demo-dev.elasticbeanstalk.com/remote/api/entity/country/byid/1
{
"id": 1,
"countryIsoCode2": "AF",
"countryIsoCode3": "AFG",
"countryRating": null,
"countryName": "Afghanistan",
[...]
}

load by natural key example

$ curl http://mango-demo-dev.elasticbeanstalk.com/remote/api/entity/country/bynaturalkey/af
{
"id": 1,
"countryIsoCode2": "AF",
"countryIsoCode3": "AFG",
"countryRating": null,
"countryName": "Afghanistan",
[...]
}

load by query expression example

To load more than one entity you can use a query to match the entities send as query parameter {baseUrl}/query?query={query} or as content of the HTTP request. The expression is based on the Spring Expression Language (SpEL).

// query = countryName matches 'a%' $ curl http://mango-demo-dev.elasticbeanstalk.com/remote/api/entity/country/query?query=countryName%20matches%20%27a%%27

<

p>[ { "id": 1, "countryIsoCode2": "AF", "countryIsoCode3": "AFG", [...] }, { "id": 6, "countryIsoCode2": "AS", "countryIsoCode3": "ASM", [...] }, { "id": 7, "countryIsoCode2": "VI", "countryIsoCode3": "VIR", "countryRating": null, "countryName": "Virgin Islands, U.s.", [...] } ]

An small page listing all relevant URLs for each entity that also includes a minimal REST client to try the API right away is automatically provided.

API index page example mango_entity_api2

You can try out the country API from the showcase application at: http://mango-demo-dev.elasticbeanstalk.com/remote/api/entity/country/index

By |February 11th, 2015|development, gwt, mango|

Jenkins walldisplay version 0.6.28

Time for a new Jenkins walldisplay release, version will be 0.6.28 and should show up in the Jenkins repository within the next few hours. This release contains the following changes (nearly 100% from Github pull request, thanks to all comitters):

  • JENKINS-25022 Walldisplay is not shown, if the project has the same name as the current view (thanks to
  • only show “Loading jobs…” in debug mode
    displaying the loading jobs message clears the whole screen from all jobs.
    this commit only displays the message when in debug mode which results
    in a better user experience when not in debug mode. (thanks to linki)
  • JENKINS-23620 Screen repaint without disturbing glitches (thanks to pvelder)
  • Support showing Junit results in the wall whenever available (both thanks to jaby)

walldisplay_0.6.28

By |January 30th, 2015|development, jenkins|

Mango GWT commons available on maven central

I started to extract all GWT utils that are not specific to Mango into an own project that is now available on maven central, so you can use it with your favorite dependency management system. Artifact name is mango-gwt-commons.

mango-gwt-commons_repo

gradle example

maven example

By |January 30th, 2015|development, gwt|

GWT wrapper for toastr

I added an thin wrapper for the toastr non blocking notification library to my GWT commons project. Usage is pretty much straightforward form the usage of toastr in JavaScript itself (same methods in Java/JavaScript) so the toastr documentation mostly applies to the wrapper.

gwt_commons_toastr1

For more example see the online demo here.

By |January 28th, 2015|development, gwt|

Integrating JavaScript libraries into GWT using JSNI

From time to time when developing GWT applications, I reach the point where the functionality I needed is already perfectly implemented by a JavaScript library. Currently I needed some kind of user friendly non-blocking notification system that displays warnings/errors/.. in the form colored overlays depending on the notification message level. The first match in Google (toastr) seemed like a perfect fit:

toastr is a Javascript library for Gnome / Growl type non-blocking notifications. jQuery is required. The goal is to create a simple core library that can be customized and extended. so in this post I will show the key points that need to be done to use a JavaScript library from GWT (Java) code using toastr as an example.

Including the needed resources

The first step is that the JavaScript library itself (and often accompanying cascading stylesheets) need to be available in the HTML page hosting the GWT application. Of course placing the *.js and *.css files in the GWT module public folder and then using them in the page using <stylesheet ..> and <script ..> is a perfectly feasible solution I prefer to inject the needed resources into to page because when you wrap an external JavaScript library, the GWT module wrapping the library tends to get reused in other contexts and injecting the resources can be done in the modules entrypoint so the developer using your module does not need to modify the applications page an can start using your wrapper right away.

In the case of toastr we need the sources for toastr itself toastr.min.js, the stylesheet toastr.min.css and of course JQuery jquery-1.11.2.min.js. GWT provides the ClientBundle interface which apart from providing an aggressive caching strategy comes with compile time sanity checks. The first sentence of the documentation sums it up nicely:

The resources in a deployed GWT application can be roughly categorized into resources to never cache (.nocache.js), to cache forever (.cache.html), and everything else (myapp.css). The ClientBundle interface moves entries from the everything-else category into the cache-forever category.

So to actually uses the resource in a ClientBundle extend the ClientBundle interface and point it to the needed files:

now instantiate this interface using the GWT.create(...) method:

now you can read the actual file contents via:

Inject the resources

The next step is to inject the resources into the page. GWT provides injectors for JavaScript and CSS that take care of injecting the script/styles into the right parts of the DOM tree:

Call the “native” JavaScript functions

Now that our JavaScript library is available, we can start using it. Interaction with native code from Java is done using the Java native interface (JNI) or in this case the JavaScript Native Interface (JSNI) as it is called in GWT. The contract is, that in the native method declaration everything written between /*-{ and }-*/ is treated as JavaScript by the GWT compiler. When writing JavaScript you have to keep in mind that the script runs in a nested frame and hence window and document are not directly accessible, but GWT guarantees that they are available in $wnd and $doc. To call the warning function toastr offers the Java method looks like this:

You always have to keep in mind, that the JavaScript code you write in native methods is not checked by the compiler, so you will not notice an errors until it is actually used during runtime. There are also some (smaller limitations) on the argument types (especially concerning varargs and long types) that are summed up on the documentation page for JSNI.

By |January 27th, 2015|development, gwt, Uncategorized|