Using bots to keep our dependencies up to date

Any real world Java project will likely use external dependencies. As we’ve seen over the last few years, it’s important to keep these dependencies up to date. We used to have to manually check for updates, but fortunately these days there are tools available that can help us with this. Because, let’s be honest, most developers don’t enjoy maintaining applications. We’d much rather be using cool new tools and/or language features, and solving interesting problems. Sorry, I mean: delivering business value! But we are responsible for keeping our dependencies up to date, so let’s make that as easy as possible. In this blog post we will look at one category of tools that can help us: bots that can automatically create pull requests (PRs) to keep dependencies secure and up to date.

For Java, we currently have three options: Dependabot, Renovate and Snyk Open Source. They each support other programming languages too, but as I mostly use Java and other JVM languages I have limited myself to these. Let’s take a look at which features they provide and their similarities and differences.

Sidenote: In order to try out and compare these bots, I’ve added them one by one to my personal GitHub profile and will describe here how to add them to your GitHub profile, as well as link to information about other integration options.

Dependabot

The first bot we will look at is Dependabot. Since Dependabot is GitHub native, we can enable most of its features from the Settings > Security > Code security and analysis. Here we can enable (or disable) the available features, and select which ones we would like to automatically enable for new repositories.

Features

Dependabot offers the following features: Alerts, security updates and vulnerability updates.

When Dependabot is enabled, it provides a Dependency Graph under the Insights tab of your project. The Dependencies tab shows any alerts to the owner of the repository. The Dependents tab shows any projects that depend on your project. In the Dependabot tab version updates can be configured.

When we enable Dependabot alerts, we will receive alerts for vulnerabilities in our repositories and we can manually generate pull requests (PRs) to resolve them. We can configure how we would like to receive these alerts. We can also view them in the Dependency Graph in the Dependencies tab.

GitHub project Insights tab with the Dependabot Dependencies graph Dependencies tab open and yellow alert stating We found potential security vulnerabilities in your dependencies. — Dependabot Dependencies graph

We can click the button to View Dependabot alerts to see more information about the alerts.

Details of Dependabot alerts on GitHub, listing several Critical updates — Dependabot alerts

Pull requests

When we enable Dependabot security updates, Dependabot will open pull requests (PRs) automatically to resolve vulnerabilities. These PRs provide information about the severity of the vulnerability, CVSS base metrics, and CVEs. We can hover over the CVSS base metrics and CVEs to get more information. We can review the changes, or dismiss the alert.

Dependabot pull request for a security update on jackson-databind with information about the vulnerabilities found. — Dependabot security update

To enable version updates, you need to add a dependabot.yml file to your repository.

Configuration

In this configuration file, you need to provide the package manager, the directory that contains your manifest file and a scheduling interval (daily, weekly, or monthly). You can configure more options, like when it should be scheduled (date, time, timezone), the maximum number of PRs (the default is 5), rebase strategy, settings that can help you manage the PRs like target branch, assignees, reviewers, commit messages and labels, and more. For more information on configuration options, see the Dependabot documentation on configuration.

Integration

While Dependabot is GitHub native, it is possible to run it locally or on GitLab too.

Renovate

Like Dependabot, Renovate offers security updates and version updates. In addition, Renovate will also create a project dashboard listing all updates needed on a particular project.

Renovate is available on GitHub via a GitHub app. To configure Renovate for your GitHub account, go to https://github.com/apps/renovate. Renovate allows you to set Repository access to either All repositories or Only select repositories. Renovate is the only one of these three options that allows you to try it out on only one repository first, so if you’ve never used one of these bots, I’d recommend starting with Renovate on one repository.

Install Renovate on your personal account with the option to select All repositories or Only select repositories. — Install Renovate

Renovate will create an onboarding pull request to the selected repositories. The onboarding PR contains basic configuration for Renovate to run. It describes the configuration in a Configuration Summary, and provides some information about What to Expect when the PR is merged (in this example, a list of PRs that will be opened).

Renovate onboarding PR with Configuration Summary — Renovate Onboarding PR

What to Expect section of Renovate's onboarding PR listing which PRs will be opened. — Renovate What to Expect

Note: These screenshots were taken from the PR created in September 2022. It may have changed since then.

Configuration

Renovate offers additional configuration options. In addition to setting a maximum number of PRs, Renovate allows you to to set a maximum number of concurrent branches or even an hourly limit, which can help to keep the number of open PRs and branches manageable. Renovate also lets you configure when to rebase (or not), and settings to help you manage the PRs assignees, reviewers, commit messages, labels, and more. Overall, Renovate offers more configuration options, and these options are more fine-grained than Dependabot’s options.

For more information, see the Renovate documentation on configuration options.

Once the onboarding PR is merged and the configuration file is added to your repository, Renovate will start opening pull requests with updates on the selected repositories.

Renovate pull request for jackson-databind security update — Renovate pull request

Pull requests

These PRs contain information about the reason a PR was created including which package was updated, the current and new version, as well as the following information to help you decide whether or not to merge the PR and apply the update (apart from your build being green).

Age: The age of the package
Adoption: The percentage of this package’s users (within Renovate) which are using this release
Passing: The percentage of updates which have passing tests for this package
Confidence: The confidence level for this update

For more information, see the Renovate documentation on merge confidence.

Auto merging PRs

In addition, Renovate offers the option for rule based auto merging of PRs; a feature that lets you automate upgrading dependencies. When auto merging is enabled, Renovate tries to merge the proposed update once the tests pass. Renovate recommends that you enable auto merge only for any type of dependency updates which you would just merge anyway, and keeping auto merge disabled for updates where you want to review the release notes and/or code before merging. Of course, great test coverage is also very helpful here! Renovate is currently the only of these three options that offers this feature.

Dashboards

Finally, Renovate will add a Dependency Dashboard to your project, listing all Renovate updates and detected dependencies. This dashboard can be enabled or disabled as desired.

GitHub project Issues tab with a Renovate Dependency Dashboard link — Renovate Dependency Dashboard

Renovate project Dashboard with a list of all outdated dependencies that can be updated. — Renovate project Dashboard

In addition, Renovate provides a general dashboard with all projects & jobs run, which you can find under https://app.renovatebot.com/dashboard if you have Renovate enabled.

Integration

Note: If you are not using GitHub, Renovate currently also supports other platforms. For more information, see the Renovate documentation on supported platforms.

Snyk Open Source

Snyk Open Source is available from Snyk. There are more steps to enable it for your GitHub Profile, but it also offers more features. To enable Snyk Open Source, go to https://snyk.io/product/open-source-security-management/ and select Start free. You will need to Authorize snyk on your GitHub profile, select repository access (either Public and private repos or Public repos only), select other available features you want to use, and provide a Personal access token on GitHub.

Features

In addition to security updates, version updates, and dashboards, Snyk Open Source offers to test for new vulnerabilities and/or test for vulnerabilities in source code. These options are currently not offered by Dependabot or Renovate. As this blog post focussed on tools to help you detect possible vulnerabilities in your dependencies and automatically create PRs to upgrade them, we will not look at scanning the source code for vulnerabilities here.

Pull requests

When enabled, Snyk Open Source will open PRs on the selected repositories. These PRs also include information about the reason for the PR, severity of a vulnerability, priority score and why it has this score, details of the version upgrade (current and new version), and more.

Snyk Open Source pull request for jackson-databind with information about the vulnerability found. — Snyk Open Source pull request

By default, Snyk Open Source will combine related updates into one single PR to help reduce the noise. Dependabot does not currently offer this option, while Renovate can be configured to do something similar.

Snyk Open Source pull request that bundles several updates. — Snyk Open Source combined PR

Snyk Open Source also has the option to test for new vulnerabilities. When enabled, incoming PRs will be checked for known vulnerabilities to make sure that no known vulnerabilities are added to the code base. Dependabot and Renovate do not currently offer this feature.

GitHub screen saying All checks have passed including a Snyk Open Source security test has passed — Snyk Open Source security test on PRs

Configuration

We can configure the frequency with which Snyk Open Source should run (daily, weekly, never). We can enable or disable scanning for new and/or known vulnerabilities, so we can clear our backlog of known vulnerabilities separately from making sure we don’t get any new vulnerabilities. This might help getting started with updating outdated dependencies without getting overwhelmed with too many updates. Dependabot and Renovate do not currently offer this option. Finally, we can also enable or disable PRs for a single project, so we can start using Snyk Open Source on a single project like we can with Renovate, but this is not a default option.

Dashboards

The dashboards offered by Snyk Open Source are the most extensive of these three options. The dashboards provide an overview of known vulnerabilities found in your repositories with the number of vulnerabilities and their severity visible per project and overall.

Snyk Open Source Dashboard listing pending tasks and vulnerable projects and an issues summary, listing number and severity of vulnerabilities found. — Snyk Open Source Dashboard

Integration

You can use Snyk Open Source in the Snyk Web UI, with the Snyk CLI, in your IDE, or with an API. For more information, see the Snyk Open Source documentation.

Conclusion

As we have seen, the different bots offer different features. All of the options discussed here can automatically open pull requests for vulnerable dependencies and version upgrades. The information they provide with these PRs differs, as do the number and type of configuration options. Which bot is right for you will depend on needs and preferences.

Links / sources:

Package Checker: Find and fix vulnerabilities inside IntelliJ IDEA Ultimate

In this blogpost, we’re going to take a look at the Package Checker plugin, that’s bundled with IntelliJ IDEA Ultimate. We’ll have a look at how to view known vulnerabilities in your Maven or Gradle projects, how to get more information about the known vulnerabilities in a specific dependency and how to remediate these vulnerabilities inside IntelliJ IDEA Ultimate if a new version with a fix is available.

There are several ways to view known vulnerabilities for the dependencies to your project.

View vulnerable dependencies in Maven projects

In a Maven project, all of your project’s dependencies are declared in the pom.xml. When we open the pom.xml file for a project which contains vulnerable dependencies, we see that several dependencies are highlighted.

Maven pom.xml with vulnerable dependencies highlighted

The Package Checker plugin highlights vulnerable dependencies and when we hover over the highlighted dependency, IntelliJ IDEA Ultimate shows all the vulnerabilities that were identified in this particular dependency. When we click on link for the CVE for a particular vulnerability, we’re redirected to the Checkmarx Advisory to learn more about this specific vulnerability.

Another way to see all the vulnerable packages is by right-clicking on the pom.xml file and selecting Analyze > Show Vulnerable Dependencies. This will open the Vulnerable Dependencies tool window.

Open Vulnerable Dependencies tool window from pom.xml

View vulnerable dependencies in Gradle projects

In a Gradle project, all of your project’s dependencies are declared in the build.gradle. When we open the build.gradle file for a project which contains vulnerable dependencies, we see that several dependencies are highlighted.

We can open the Vulnerable Dependencies tool window from the build.gradle file. For example, let’s have a look at the Spring PetClinic, which uses Gradle. We can right-click the build.gradle file and go to Analyze > Show Vulnerable Dependencies. This will open the Vulnerable Dependencies tool window.

Open Vulnerable Dependencies tool window from build.gradle

View vulnerable dependencies in the Vulnerable Dependencies tool window

We can also open the Vulnerable Dependencies tool window without having to open the files where our dependencies are declared. To open the Vulnerable Dependencies tool window straight from the main menu, go to Code > Analyze Code > Show Vulnerable Dependencies.

Open Vulnerable Dependencies tool window from menu

The Vulnerable Dependencies tool window shows all the vulnerable dependencies for the project. For each vulnerability, we can see an indication of the severity. There are two different views; the flat view shows all the vulnerable dependencies in this project and the dependency hierarchy view shows the dependency tree and the hierarchy between dependencies.

Vulnerable Dependencies tool window flat view

Vulnerable Dependencies tool window dependency hierarchy view

When we click a specific dependency, we can see more information about the vulnerabilities that were found in that dependency. In the Vulnerable Dependencies tool window details pane on the right, we can click the link to Read more under the information about a particular dependency, which will take us to the information about this specific vulnerability in the Checkmarx Advisory.

Vulnerable Dependencies tool window details

To see all the dependencies of the project regardless of whether they’re vulnerable or not, we can click the Show safe button on the top left of the Vulnerable Dependencies tool window.

The dependencies without known vulnerabilities are shown with a green checkmark next to it. We still have the same two views; the flat view and the dependency hierarchy view. We can use the Show safe button to toggle between showing all dependencies or vulnerable dependencies only. We can use the Collapse all or Expand all buttons to collapse or expand the views.

Remediate dependencies using IntelliJ IDEA Ultimate

Finally, we can remediate these vulnerabilities. We can click Copy safe version to clipboard in the Vulnerable Dependencies tool window details pane to copy the safe version and paste it into our build file.

We can also fix it directly in our build file. When we hover over a specific vulnerable dependency, the hover menu includes an action that we can click to upgrade the version (if a new version is available).

Alternatively, we can use the intention action shortcut, ⌥ ⏎ on MacOs, or Alt+Enter on Windows/Linux and select the action to upgrade the version (if a new version is available).

After we update the versions, we can Load Maven Changes, using ⌘⇧I on MacOs or Ctrl+Shift+O on Windows/Linux. We see that the overview in the Vulnerable Checker tool window is updated, and we see that dependencies that we have upgraded and are no longer vulnerable are removed, or shown with a green checkmark if we have enabled Show safe dependencies.

Summary and Shortcuts

As we have seen, the Package Checker plugin bundled with IntelliJ IDEA Ultimate offers several different ways in which we can view vulnerable dependencies in our project inside IntelliJ IDEA Ultimate, get more information about these vulnerabilities, and remediate them. This plugin can help keep your projects safe and secure right inside your IDE!

IntelliJ IDEA Shortcuts Used

Here are the IntelliJ IDEA shortcuts that we used.

Name	macOS Shortcut	Windows / Linux Shortcut
Open / Close Project Tool Window	⌘1	Alt+1
Context Actions	⌥⏎	Alt+Enter
Load Maven Changes	⌘⇧I	Ctrl+Shift+O

IntelliJ IDEA shortcuts used

IntelliJ IDEA Ultimate: Package Checker

In this screencast we’re going to take a look at the Package Checker plugin, that’s bundled with IntelliJ IDEA Ultimate.

We’ll have a look at how to view known vulnerabilities in your Maven or Gradle projects, how to get more information about the known vulnerabilities in a specific dependency and how to remediate these vulnerabilities inside IntelliJ IDEA Ultimate if a new version with a fix is available.

Managing dependencies in IntelliJ IDEA

In this tutorial, we’re going to take a look at managing dependencies in IntelliJ IDEA. We’ll look at different ways to add dependencies to your project, and how to add, upgrade and remove dependencies using Package Search.

Add dependencies

There are several ways to add new dependencies to your project.

From the build file using copy-paste

You have probably copied a dependency from Maven Repository (or another website) and pasted into your build file.

For example, we can copy the Gradle format for this dependency and paste it into our build.gradle file.

Or, if we are using Maven, we can copy the Maven xml format into our pom.xml.

Did you know that if you copy-paste a Maven XML dependency into your build.gradle file, IntelliJ IDEA automatically turns it into the correct format for Gradle?

From the build file using code completion

We can also add dependencies to our build file using code completion. For example, let’s add a new dependency to our pom.xml.

We see that IntelliJ IDEA autocompletes the dependency xml, and we can search for the dependency we want, in this example AssertJ. If needed, the version number will also be added. Since this is a test dependency, we need to add the test scope, still using code completion.

Code completion works in Gradle too, as you can see below.

From the build file using code generation

We can also use code generation from the build file to add dependencies. In the build file, the pom.xml in a Maven project, invoke Package Search using ⌘N (on macOS) or Alt+Insert (on Windows & Linux) and in the menu that opens, select Add dependency. This will open the Dependencies tool window.

Note that if we are using Gradle, we can do the same in our build.gradle file.

From the Dependencies tool window

Alternatively, we can open the Dependencies tool window directly. There is no shortcut to open the Dependencies tool window, so we can either use Recent Files, ⌘E (on Mac) or Ctrl+E (on Windows/Linux), and type in “dependencies” to open the Dependencies tool window.

Alternatively, we can open it by clicking Quick Launch in the bottom-left and selecting Dependencies.

In the Dependencies tool window, we can search for a dependency. For example, let’s search for AssertJ.

Note that we can select a scope for this dependency. The names of the scopes are based on the build tool with which you are working. Since this is a test dependency, and we are using Gradle in this project, we can set the scope to testImplementation.

We can also select the version we want to use.

We can do the same in Maven.

Note that the names of scopes for Maven are different from Gradle. In Maven, we can set the scope for a test dependency to test.

When we click Add, we see that the dependency is added to the build file.

If the version number is shown in red, that means IntelliJ IDEA hasn’t downloaded this library before. Click Load Maven Changes so IntelliJ IDEA will update its dependencies based on the changes to the pom.xml or build.gradle file.

Go back to the Dependencies tool window and clear the search box by clicking the x on the right-hand side. You’ll see the project’s dependencies are updated with your new dependency.

Next, let’s look for jackson-databind. We see that there are several versions available. Since we have selected Only stable, only stable versions are shown in the list.

If we uncheck this option, we see that the list of versions also includes the release candidates.

For production code, we probably want to use stable versions, so let’s select the Only stable checkbox again. With this option enabled, IntelliJ IDEA will exclude any dependencies that have no stable versions, and hide them from the list. Now we can select the latest stable version and add this to our project. Let’s also Load Maven Changes again.

Finally, let’s also add a new dependency to the Kotlin module. Let’s switch to the Kotlin module and open the pom.xml for this module. Open the Dependencies Tool Window and search for Ktor.

Notice that some dependencies are marked as Multiplatform.

If we want to see only Kotlin multiplatform dependencies, we can select the Kotlin multiplatform checkbox, as shown below.

When we click Add to the right of the Ktor dependency, we see that Ktor is added to the list of dependencies and to the pom.xml for the Kotlin module.

Upgrade dependencies

We will also need to keep our dependencies up to date. To show you how IntelliJ IDEA can help, we are using this extremely outdated project as an example. In the pom.xml below, we see that several dependencies are marked with squiggly lines underneath them.

IntelliJ IDEA will show the suggestion to upgrade when we hover over the dependency, and we can click the suggestion to upgrade the dependencies.

Alternatively, we can use Context Actions ⌥⏎ (on macOS) or Alt+Enter (on Windows & Linux) to upgrade these dependencies.

We can also upgrade our dependencies using the Dependencies tool window. The Dependencies tool window will tell us if there’s a newer version of a dependency, as we can see here.

We can choose the version to upgrade to by clicking on the version number in the list. Note that we don’t have to use the latest version.

We can also automatically upgrade a dependency to the latest version by clicking Upgrade for that particular dependency.

Or, we can even upgrade all our dependencies at once, by clicking the Upgrade all link.

Remove dependencies

Finally, we can remove dependencies we no longer need. In the Dependencies tool window, let’s remove jackson-databind from the Java module. We select the dependency we want to remove (jackson-databind) and in the Dependency details pane on the right, click the More button (three dots) and select Remove.

We will see that the dependency is removed from the pom.xml and the dependency list. To remove a dependency from the whole project, select All Modules on the left.

Summary and Shortcuts

Now we know the different ways in which we can view our project’s dependencies in IntelliJ IDEA, and the different focus for each view.

IntelliJ IDEA Shortcuts Used

Here are the IntelliJ IDEA shortcuts that we used.

Name	macOS Shortcut	Windows / Linux Shortcut
Open / Close Project Tool Window	⌘1	Alt+1
Recent Files	⌘E	Control+E
Invoke Package Search	⌘N	Alt+Insert
Context Actions	⌥⏎	Alt+Enter

Shortcuts used

IntelliJ IDEA: Managing Dependencies

In this screencast, we’re going to take a look at managing dependencies in IntelliJ IDEA. We’ll look at different ways to add dependencies to your project, and how to add, update and remove dependencies using Package Search.

Viewing dependencies in IntelliJ IDEA

In this blogpost we’re going to take a look at different ways to view your external dependencies in IntelliJ IDEA.

Introduction

There are several ways to view dependencies in IntelliJ IDEA. Each view has a different focus.

Dependency management config file

You can find direct dependencies in the dependency management config file. Direct dependencies are the dependencies that your project depends on directly. They are declared in the dependency management config file.

One example is this pom.xml in a Maven project.

A pom.xml file opened in IntelliJ IDEA — Maven pom.xml file

Another example is the build.gradle in a Gradle project.

Note that the dependency management config file includes only declared dependencies and not their transitive dependencies (or the dependencies that these declared dependencies depend on).

Project tool window

In the Project tool window, ⌘1 (on Mac) or Alt+1 (on Windows/Linux), under External Libraries we can see all the JAR files needed by our application, including the transitive dependencies. However, we cannot tell the difference between direct dependencies and transitive dependencies. One declared dependency might bring in multiple JAR files.

Build tool window

To see direct dependencies and their transitive dependencies, we can look in the Build tool window. There is no shortcut to open the Build tool window. We can open it by clicking Quick Launch in the bottom-left and selecting Gradle, or Maven depending on what we’re using.

Open the Gradle Build Tool Window in the Quick Launch menu

Alternatively, we can open it by using Recent Files, ⌘E (on Mac) or Ctrl+E (on Windows/Linux), and typing “gradle” or “maven”, or the name of your build system.

Open the Gradle Build Tool Window using the Recent Files popup

Open the Maven Build Tool Window using the Recent Files popup

The Build tool window shows you each IntelliJ IDEA module separately, and each module’s “Dependencies” folder shows you all your dependencies in a hierarchical structure. We can expand our dependencies to see their transitive dependencies.

Gradle Build Tool Window showing dependencies

Maven Build Tool Window showing dependencies

Dependency tool window

Finally, we can view and manage dependencies in the Dependencies tool window. The Dependencies tool window becomes available when the current project has at least one supported module. All types of dependencies are supported for Maven. For Gradle only a top level dependencies { } block is supported in the build script.

Since there is no shortcut to open the Dependencies tool window directly either, we can again use Recent Files, ⌘E (on Mac) or Ctrl+E (on Windows/Linux), and type in “dependencies” to open the Dependencies tool window.

Open the Dependencies Tool Window using the Recent Files popup

Alternatively, we can open it by clicking Quick Launch in the bottom-left and selecting Dependencies.

Open the Dependencies Tool Window in the Quick Launch menu

Here we can see our project’s direct dependencies. Select “All Modules” to see the dependencies for all modules, or select an indivual module to see the dependencies for that specific module. The Dependencies tool window shows direct dependencies, and not their transitive dependencies.

We can see details about a selected dependency in the dependency details pane.

The dependency details pane displays the information about the selected dependency, such as:

Repository or repositories where it’s available, for example Maven Central
A description if it is available
GitHub information if the dependency sources are hosted on GitHub
The licence under which an open source library is available
A link to the project website, documentation and readme
List of usages in the current module.
Authors if available
Supported Kotlin or Multiplatform platforms if it is a Kotlin Multiplatform dependency

Summary and Shortcuts

Now we know the different ways in which we can view our project’s dependencies in IntelliJ IDEA, and the different focus for each view.

IntelliJ IDEA Shortcuts Used

Here are the IntelliJ IDEA shortcuts that we used.

Name	macOS Shortcut	Windows / Linux Shortcut
Open / Close Project Tool Window	⌘1	Alt+1
Recent Files	⌘E	Control+E

Shortcuts

IntelliJ IDEA: Viewing Dependencies

If you’re working on a real-world application, your project will probably use external libraries and frameworks. Occasionally, you might want to see which dependencies your project uses, for various reasons. There are several ways to view dependencies in IntelliJ IDEA. Each view has a different focus.

Viewing Dependencies

Selecting dependencies

This blogpost was also published on Medium.

Open source software is everywhere. Most likely you are using some open source projects either at work and/or in your side projects.

Pros and cons of using dependencies

One of the upsides of using Java as a programming language, is that there are libraries and frameworks available to do many of the things we want to do in our projects, but don’t necessarily want to write ourselves. Using existing libraries and frameworks helps us deliver business value faster.

Unfortunately, there are also downsides to using external dependencies. The most dangerous being when security vulnerabilities are found in libraries many of us use, like the Log4Shell vulnerability in the log4j logging library that was disclosed in December 2021 and the Spring4Shell vulnerability in Spring in March 2022. These vulnerabilities were so severe that we had to patch all our services ASAP. Even if the version of a dependency you use does not have any known vulnerabilities, you might need to update them for other reasons.

In addition, adding dependencies to your project also has an impact on the size of your binary. For example, Brian Vermeer has created a demo to show the number of lines of code written versus number of lines pulled in by Spring. Granted, he admits that “this was the most useless Rest endpoint you could ever write”, but this demo clearly shows how the code pulled in by dependencies can overshadow to amount of code you write yourself.

A balancing act

This means we have to think carefully about which dependencies we want to use. Some developers try to add little or no external dependencies to their projects. This is one way to avoid the downsides mentioned above. Another argument may be that it gives you more control over the code in your project. Of course, the downside here is that you have to write everything yourself, which might not always be the best idea. For example, I’d rather use JUnit and Mockito than write my own testing and mocking frameworks.
On the other hand, we shouldn’t just add any library or framework, as we’ll have to not only implement them now, but also maintain them over time. Or even remove them in the future, which is not always easy. Some projects, like Lombok or Reactor, will be present throughout your code base and hard to remove should you ever want to (for example, when moving to Kotlin & coroutines).

Most of us will be somewhere in the middle; we don’t want to write everything ourselves, and we will use certain frameworks and libraries that offer us some useful functionality, but we also want to make sure we can continue to maintain our project without having to (urgently) update dependencies or rewrite our code because something is vulnerable or otherwise outdated.

What to consider when selecting dependencies for your project

The best time to check your dependencies is before you add them. The second-best time is now. So take a critical look at any dependencies you’re adding or already using and consider the following:

Do we really need this dependency?

To make it worth it to use a dependency, it has to solve our problem and do so without adding new problems. We need to consider if the project fits our needs. We can do so by reading the documentation, and by seeing what experience other users already have with a particular tool. Keep in mind that, just because other users are enthusiastic about a particular library, that doesn’t necessarily mean it’s right for you. Their context or use case might be different from your own. There might be other libraries out there offering similar functionality that are a better fit for your project.

Also consider how much of the library you’ll actually use. If it is only a small part, consider other solutions. For example, do we really need to import StringUtils to use it for one or several String functions, or can we write them ourselves? (And, if we moved to Kotlin since then, we might be able to replace them with standard Kotlin functionality.) Or are we already using another library for this particular problem? For example, we won’t need gson if we are already using jackson (or vice versa)?

Is the project well maintained?

If a project is no longer maintained, we run the risk of having to urgently replace it if security vulnerabilities are found. To see if a project is actively maintained, you can check when the last release was, and how frequently new versions come out; you can find this information for example on Maven repository. You can also check when the last commit was, and whether the project is maintained by one person, or a group of active maintainers. A project that depends on one particular person runs the risk of becoming unmaintained if that person no longer has the time and energy to maintain that project. Maintaining a successful open source project can be a thankless task and maintainer burnout is real. With multiple maintainers the load and risk can be shared. You might want to look into how many open Issues and Pull Requests (PR) there are, and the interaction on those Issues & PR’s. You can find this information on GitHub or wherever the code for the project is kept.

How popular is the project?

A popular project might have more stars, watches and forks on GitHub. Although these metrics don’t necessarily mean that people are using it; they might have starred it to try it out later. These metrics might be useful when comparing similar tools, but not necessarily when comparing different tools.

A widely used project will likely have more people talking and writing about it. Having a large number of users means more people who are able to help out others. It also means there are more potential contributors, but unfortunately a high number of users doesn’t always translate to a high(er) number of contributors. And just because a project is popular doesn’t mean it’s right for you.

What is the community like?

Consider whether the community is friendly and welcoming. How do they interact with their users and (potential) committers? How do they respond when issues are reported? Do they review PR’s quickly and offer constructive feedback? Friendly maintainers often make for a more friendly community.
They might be active in official support channels like Slack, Gitter or mailing lists, or help answer questions on StackOverflow, write talks and blog posts or find other ways to share their knowledge.

Is it easy to use?

Finally, consider whether the project easy to implement & use, and whether you like using it. Developers have personal preferences with regard to almost everything in software development, including which tools they like to use. If a popular framework doesn’t work for you, and you have options, choose something else!
Part of whether a project is easy to use might include how well documented a project is. Good documentation can help make it easier to use. Consider looking at the official documentation, as well as blogs and content created by users. The official documentation will (hopefully!) explain how a project is meant to be used.

What is the latest stable version? Are there any open vulnerabilities?

Once you’ve decided to import a dependency, make sure to add the latest stable version. We don’t want to add an older or unstable versions that we then have to update. And we definitely don’t want to import a dependency that has known vulnerabilities that have not (yet) been fixed! We want to keep our software secure and maintainable.

Where to find this information

As mentioned, there are several places where we can look for information about a dependency we are considering. One is Maven repository where we can find open source packages, their versions, whether there are any known vulnerabilities and more.

For example, when we look at Jackson Databind on Maven repository we see a list of versions and their release dates, we see the number of usages by other artifacts for each version, and we see a warning in red for versions with known vulnerabilities.

When we look at the details of a version with known vulnerabilities (Jackson Databind v2.13.2 in this example), we see the CVE number for this vulnerability which links to the details for this CVE). There is also a warning in yellow that there is a new version for this artifact with the link to that version.

Details for a vulnerable version of Jackson Databind

Another is to find the project’s code on GitHub, to look at the code itself, see when the latest commit was, look at open Issues and PR’s, and check Insights for more details on contributors, frequency of commits and other activity.

We can look for official documentation and read (or at least scan) it to see whether the project is a good fit for us, and whether it is well documented.
Other information might take a bit more effort to find: Go into the support channels and ask questions. Search for blog posts (or YouTube videos, if you prefer) and other places where you can find information. We might even check StackOverflow to see whether there is a tag for this dependency, how many (open) questions there are, etc.

JetBrains has created a Package Search website that can be used to search for Java and Kotlin libraries and get a lot of this relevant information, including the latest (stable) version, links to relevant tags on StackOverflow, links to the official docs and the code, and if the project is on GitHub the number of stars, watchers and forks on the Information tab. A list of versions (similar to the one on Maven repository) can be found on the Versions tab.

Jackson Databind on JetBrains' Package Search — Jackson Databind on JetBrains’ Package Search

The Package Search plugin is even bundled in IntelliJ IDEA 2021.2+. So, if you are using IntelliJ IDEA, you can search straight from your IDE!

Conclusion

Carefully consider which dependencies to use, taking into account at least some of the things we have discussed here. The best time to do so is before you start using them. But don’t forget to periodically check the dependencies in your existing codebase to see if you still use them, and still want to use them based on the considerations above. Don’t be afraid to remove them if they no longer bring you value.

Keeping dependencies up to date with Maven

This article was also published on Medium.

In this blog post, we will look at some standard Maven commands that can help us manage our dependencies and keep them up to date. These are useful to see both direct and transitive dependencies used in the project, look for version updates of dependencies and plugins, and look for unused dependencies that may be removed. All of these can be useful to keep our dependencies up to date.

Pre-requisites

For the examples in this post, we are using the following tools and versions:

IntelliJ IDEA Community Edition 2022.2.1 – which you can get here
Example project from GitHub (Note: this is an outdated & unmaintained project, which makes it useful to show how to find outdated dependencies)
Maven 3.8.6 (optional, see note below) – Install Maven

Note: Maven wrapper

The project we are using in this example includes a Maven wrapper. If the project you are working on does not have a Maven wrapper, you will need to have Maven installed on your local machine. To add Maven wrapper to your project, run the following command in your terminal: mvn wrapper:wrapper and commit the result. Now anyone who uses the project can use the Maven wrapper without having to install Maven locally, and using the same Maven version.

Using Maven to display dependency updates

We can use Maven to check if there are updates available for the dependencies we are using in our project. Run the following command in your terminal: ./mvnw versions:display-dependency-updates.

This will display a list of dependencies for which newer versions have been found.

Command line terminal showing the `mvn versions:display-dependencies-updates` command and it's result. — Display dependency updates

As you can see, there are quite a few dependencies that need to be updated in this project. The reason is that this is an old project that was created from a tutorial years ago and not maintained since. The upside is that it is a great project to use as an example for finding outdated dependencies.

Using Maven to display plugin updates

The same is possible for plugins. Check which plugins can be updated by running the following command in your terminal: ./mvnw versions:display-version-updates.

On the example project, this provides the following result:

Command line showing the command ./mvnw versions:display-plugin-updates and the results — Display plugin updates

This project doesn’t really use a lot of plugins. Your actual projects might, so I wanted to include this command here.

Overview of dependencies: dependency-tree

To see all the dependencies you are using in your project, run the following command in your terminal: ./mvnw dependency:tree. This will return a list of the dependencies declared in this project, and their transitive dependencies:

Command line showing the command `./mvnw dependency:tree`and the resulting dependency tree for a project — Dependency tree

Of course, you can also find the declared dependencies in your pom.xml, but it’s good to have an idea of which transitive dependencies they bring in.

Filtering the dependency tree

The dependency tree for this example project is rather small, like the project itself. Your actual projects at work might be much bigger. If needed, you can filter the dependency tree.

To check where a specific dependency is coming from, use the following command: ./mvnw dependency:tree -Dincludes=<groupId>:<artifactId> containing the groupId and artifactId of the dependency you are looking for.

For example, if we would like to see where this project is getting the slf4j dependency, we would run ./mvnw dependency:tree -Dincludes=org.slf4j:slf4j-api. We see that we get this transitive dependency through Hibernate:

Command line showing the command `./mvnw dependency:tree -Dincludes=org.slf4j:slf4j-api` and it's result. — Filtering the dependency tree

For more information on filtering the dependency tree, see the Maven documentation.

Effective pom

The effective pom is the POM that results from the application of interpolation, inheritance and active profiles. To generate the effective POM, run the following command in your terminal: ./mvnw help:effective-pom.

When running this command on the the example project, the result will be fairly small, because it is a relatively small project. For a large project, the effective pom will be much bigger. If needed, you can write the effective POM into a log file using the following command: ./mvnw help:effective-pom --log-file log.txt.

Use Maven to find unused dependencies

We can also use Maven to find unused dependencies. Run ./mvnw dependency:analyze on the example project gives us the following results:

Command line showing the result of the Maven command dependency:analyse — Analysing dependencies

We see that we have “Used undeclared” dependencies, like org.springframework:spring-beans.
If we search for that dependency, by filtering the dependency tree for that particular dependency using ./mvnw dependency:tree -Dincludes=org.springframework:spring-beans we see that it is a transitive dependency from Spring-webmvc:

Command line showing a command to filter the Maven dependency tree and it's output — Filtering the dependency tree

We also see some “Unused declared” dependencies. If these are dependencies you truly don’t need, it might be a good idea to remove them from your pom.xml. (Note: In this example, JUnit is unused because the tutorial this project is based on didn’t include any tests. If that is the case for your project, consider adding tests instead of removing this dependency!)

Conclusion

Maven offers several ways to help us keep our dependencies up to date. Using the commands above can help us to keep the dependencies we need up to date, and to remove the dependencies we no longer need.

Dependabot

Features

Pull requests

Configuration

Integration

Renovate

Configuration

Pull requests

Auto merging PRs

Dashboards

Integration

Snyk Open Source

Features

Pull requests

Configuration

Dashboards

Integration

Conclusion

Links / sources:

View vulnerable dependencies in Maven projects

View vulnerable dependencies in Gradle projects

View vulnerable dependencies in the Vulnerable Dependencies tool window

Remediate dependencies using IntelliJ IDEA Ultimate

Summary and Shortcuts

Further reading and viewing

IntelliJ IDEA Shortcuts Used

Related Links

Add dependencies

From the build file using copy-paste

From the build file using code completion

From the build file using code generation

From the Dependencies tool window

Upgrade dependencies

Remove dependencies

Summary and Shortcuts

IntelliJ IDEA Shortcuts Used

Related Links

Related Links

Introduction

Dependency management config file

Project tool window

Build tool window

Dependency tool window

Summary and Shortcuts

IntelliJ IDEA Shortcuts Used

Related Links

Related Links

Pros and cons of using dependencies

A balancing act

What to consider when selecting dependencies for your project

Do we really need this dependency?

Is the project well maintained?

How popular is the project?

What is the community like?

Is it easy to use?

What is the latest stable version? Are there any open vulnerabilities?

Where to find this information

Conclusion

Pre-requisites

Note: Maven wrapper

Using Maven to display dependency updates

Using Maven to display plugin updates

Overview of dependencies: dependency-tree

Filtering the dependency tree

Effective pom

Use Maven to find unused dependencies

Conclusion