Tracking dependency updates

Many software projects use 3rd party libraries aka “dependencies”. You often want to use the most recent version of these dependencies but how do you know when a new release of a dependency is published? The more dependencies your project have the more tiresome a manual approach to “tracking dependency updates” is.

In this post I explore some solutions that tracks dependency updates for you. I cover broad solutions ( and dependabot) and Java-only solutions (“artifact listener” and a Gradle/Maven plugin).

Why update?

But why do we want to update dependencies at all?

A new version of a dependency

  • may fix bugs that affects your project
  • may introduce new features that you could use
  • may fix a security issue that affects your project
  • may have other optimizations to the code

Of course there is a risk as well: a new version may introduce a bug that affects your project. Plus, there might be API changes that require changes in your code.

Tracking solutions

From their own words can automatically keep track of all of the packages that your repositories depend upon across many different package managers.

Once synced, will email you about new versions of your dependencies, if you add or remove a new dependency it will change the notifications settings for that package as soon as you push to your repositories.

Repositories on Github, Gitlab and Bitbucket are supported. Plus, you can subscribe to dependencies manually, ie without a repository on any of these platforms.

Beside email notifications you can also subscribe to an RSS feed of your dependency updates. is an open source project.

artifact listener

Artifact Listener is a small service and only available for Java / Maven Central. You can search for libraries and “follow” them. Alternatively you can upload a POM and then choose which dendencies to follow. Updates of libraries you follow are emailed to you.

You can provide additional email adresses to notify, e.g, email addresses of other team members. This is a small but lovely feature for me.

The service is an open source project.


Dependabot checks the “dependency files” (where your dependencies are definied) in your Github repos for updates. If there is an update it creates a PR for it. The PR may contain links, release notes, a list of commits etc.

So this service not only notifies you about an update but even creates a PR that applies it. You just have to merge it (at least if your project is on Github).

Dependabout has been aquired by and is free of charge.

Gradle plugin

If you are using Gradle (a Java build system) to declare dependencies and build your project you can use the Gradle versions plugin to detect dependency updates and report them. It is easy to use. You just need to execute it on a regular basis.

Maven plugin

Of course, there is a similar plugin for Maven (another Java build system).

Working Software

Ron Jeffries published a wonderful post titled “working software“. He quotes the agile manifesto “working software is the primary measure of progress”.

Now, he explains that what exactly “working software” means depends (as always). But in general,

Working software is real. It works. It can be tested. It can be verified. Questions about whether it does X are readily answered with “Yes” or “No”. The less ambiguity there is in our answers—our true answers—the closer to “working software” we are.

And he shares his opinion on “best development style”:

The best development style we know today, whether working solo, in pairs, or in a mob, is to pick a very small thing that the system doesn’t as yet do, verify that it doesn’t do it, then make it do that thing, verifying again, and keeping the code at or above our standard of internal quality.

How small should that thing be? Tiny. Smaller than that. No, smaller still.

I repeat that:

  1. pick a very small thing that the system doesn’t do yet
  2. verify it doesn’t do it (the “red” step in the TDD cycle)
  3. make it do that thing
  4. verify it does it (the “green” step in TDD)
  5. keeping the code at or above our quality standard (the “refactor” step in TDD).

I really like that. It’s not always that easy. But more often than not.

I know of TDD but I need to get better at remembering this (I’ll put that in my Anki deck) – including the very small part – and then practice it.

git push with force

Recently on our team chat: “I removed the remote git branch and pushed again”. “Remove” was not necessary, he could have used “git push –force” or better “git push –force-with-lease” instead.


The normal “git pushed” only works when the remote branch is contained in your local branch or in other words if your local branch is the same or ahead of the remote branch. When you still want to “overwrite” the remote branch with your local branch, use the “–force” option or the “–force-with-lease”.


When you collaborate with other team members on a remote branch, git push with force option may overwrite their work. “–force-with-lease” makes git check that the remote branch is in the state we expect it to be in before pushing the local branch, so you wouldn’t destroy work that you don’t know of.


We need to force push when

  • we changed our local branch history by rebasing or amanding
  • we need to “reset” the remote branch to our local branch


If you need to “overwrite” a remote branch with your local branch, use the “–force-with-lease” option.

How a 2 GB CLOB crashed our app

Our latest production issue: one morning our app kept crashing. Restart. Crash after some minutes. Out of memory.

It turned out to be a CLOB that was almost 2 GB big and got read when a user triggered a certain action. The 2 GB CLOB ended up in an almost 4 GB big char[] (because char is 16 bit in Java) and this was too much even for 8 GB heap space.

Of course that CLOB was not supposed to be that big!

It took some time to identify the root cause.

WLS “Context propagation” forced to restart our app server

Our app runs on a Weblogic server (WLS) and talks to another WLS-hosted app via SOAP-Webservice.

When the other app was patched to a new version, some WS-requests failed indicating that the webservice in the other wanted to JNDI-lookup the previous version of something.

After we restarted our app everything worked fine. But still you don’t want to restart a client when the server was upgraded. Moreover, a spring-boot client did not have these problems.

It turned out that WLS uses a feature called “Context Propagation” that inserts an additional SOAP-Header into the request as well as the response. This header contains a serialized object. It indicated that our app transmits the version of the other app and apperantly the other app somehow uses that information in the JNDI lookup.

How does our app knows about the version number of the other app? Probably because the other apps sends that info in the response. This explains why it worked after we restarted our app: at first it hadn’t that information at all and when it got it, it was about the new version.

What I still can’t explain is that some request were successful before the restart.

The solution is to disable “context propagation” by using a system parameter:

How to split a git repository

Say your git repo consists of a subdirectory “app” and a subdirectory “database” (or “frontend” and “backend” or “team-a” and “team-b”) and you realize each directories content should be in its own repository. Here is how to split the repo.

To create a repo that consists of the content of the “database” dir and its history, execute

and then push it to a new remote:

This is what Gitlab states on a newly created project page. However in git push -u origin --all “-all” should be replaced with “–mirror” because “-all” pushes all local branches only so you would need to checkout all branches you want to keep. “–mirror” pushes remote branches, too.

In the same fashion apply “filter-branches” to the “app” directory.

Java method references recap

In the last post I reviewed Java lambda expressions. They represent a concise syntax to implement functional interfaces.

Enter Java method references. They represent a concise syntax to implement functional interface using existing methods. Like with lambda expressions, referenced methods are not allowed to throw checked exceptions.


It’s simply “class-or-instance name” “::” “method name”, like

Types of method references

Reference to a static method

Static methods are referenced using the class name like in the example above.

Reference to an instance method of a particular object

Methods of a particular object are referenced using the variable name of that object:

Reference to an instance method of an arbitary object of a particular type

Instead of using an already existing object you can just state the class and a non-static method. Then the instance is an additional parameter. In the following example toURI is a method with no arguments that returns a String. The function of this method reference takes a File (the object) and returns a String:

Reference to a constructor

Constructors are references using its type and “new”:

Here the constructor of StringBuffer with String parameter is referenced. Return type is the type of the constructor, parameters of the function are the parameters of the constructors.



Sprint Goal in Scrum

Myth: Having A Sprint Goal Is Optional In Scrum (

Sprint Goals are one of the more elusive parts of the Scrum Framework. Most teams know they are important, but few use them – for a variety of reasons. In this post, Barry Overeem and I bust the myth that Sprint Goals are optional in Scrum. And we make an effort to show what makes them so vital in the face of complex work. And more importantly, what you can do to start working with Sprint Goals from now on.

I really like this article because I am in a Scrum team where everyone works in his/her niche area. So far we haven’t used Sprint goals. I agree with the observation in the “What happens without Sprint Goals” – section, especially:

Without Sprint Goals, each Sprint implicitly has the same purpose: complete all the work. This makes all Sprints the same, and can make people (rightfully) complain that they are artificial;

So if you’re in a Scrum team that doesn’t use sprint goals, this is definitely a must read.

Agile back to basics with Robert C. Martin

Episode 125 – Agile back to basics (The Cynical Developer Podcast)

In this episode we talk to Robert C. Martin, many of you might know him as Uncle Bob, and we’re here to talk Agile and taking it back to basics.

A great podcast episode with Robert C. Martin on “Agile – back to the basics”. So what are, in the time of Scrum, LeSS, SaFE etc., the basics of Agile?

Apparently, “Uncle Bob” has a new book in the works, “Clean Agile” (duh!), covering this subject.

On point he makes is that often engineering practices like Pair Programming, Test Driven Design and Refactoring are overlooked. Especially Scrum does not comment on these. But without these practices, technical debt is likely to accumulate (see FlaccidScrum).

Java lambda expression recap

Lambda expressions in Java represent “functions”, something that take a number of parameters and produce at most one return value.

This could be expressed with anonymous classes but lambda expressions offer a more concise syntax.


Lambda expression consist of a parameter list, an “arrow” and a body.

The parameter list is enclosed in round brackets. Types are optional. When the expression has exactly one parameter, the brackets can be omitted.

The body can either be an expression (that returns a value) or a block. A block is a sequence of statements, enclosed in curly braces.

Lambda expressions and types

In the Java type system, lambda expressions are instances of “functional interfaces”. A functional interface is an interface with exactly one abstract method.

Functional interfaces in java.util.function

The package java.util.function in the JDK contains a number of functional interfaces:

  • Function<T,U>  represents a function with one parameter of type T and return type U
  • Consumer<T>  represents a function with one parameter of type T and return type void
  • Supplier<T>  represents a function with no parameter and return type T
  • Predicate<T>  represents a function with one parameter of type T and return type boolean

Plus, variants with “Bi” prefix exists that have two parameters, like BiPredicate . More variants exists for using primitive types like DoubleToIntFunction .

User defined function interfaces

Any interface with exactly one abstract method can be used as type of a lambda expression. You mark this interface with @FunctionInterface .


For me, the benefits of lambda expression are

  • concise syntax for anonymous classes that represent functional code
  • improved readability
  • encouragement of a more functional programming style