IntelliJ IDEA is designed to help developers like us stay in the flow while we’re working. Like all IDEs, it has a lot of functionality available, but it’s designed to get out of your way to let you focus on the code.
Take a look at this overview of IntelliJ IDEA.
Introduction
Find Action: ⌘ ⇧ A (on macOS) / Ctrl+Shift+A (on Windows/Linux)
If you’re working on a real world project, you’re probably using external dependencies. You might need to analyze which dependencies your application uses. For example, you may want to find out how a particular version of a dependency ended up in your application. Let’s take a look at how IntelliJ IDEA can help you to analyze dependencies.
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.
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.
In this blogpost we’re going to take a look at different ways to view your external dependencies in IntelliJ IDEA.
Introduction
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.
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.
Maven pom.xml file
Another example is the build.gradle in a Gradle project.
Gradle build.gradle file
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.
Project tool window
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 Maven Build Tool Window in the Quick Launch menuOpen 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.
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.
Dependencies Tool Window
We can see details about a selected dependency in the dependency details pane.
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.
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.
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.
Jackson Databind on MvnRepository
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.
Jackson Databind repository on GitHub
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.
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.
My team is creating an application in Kotlin. To make development of Cucumber tests easier, we decided to also use Cucumber-jvm with Kotlin instead of Java. Fortunately, it is possible to use cucumber-java8 in Kotlin (kotlin-java8)
Prerequisites
If you’d like to follow along, make sure you have the following installed:
We use Maven, so we added the following dependencies to our pom.xml:
Maven dependencies for Cucumber-jvm
Note: The cucumber-junit dependency is added so we can add a JUnit Runner to run our tests, which we will do later.
If you don’t have Kotlin already configured in your project, you’ll need to add those dependencies also (or have IntelliJ IDEA do it for you).
Add a feature file
In our src/test/resources folder we create a new directory and add a .feature file. For this example, we’ll reuse the belly.feature from the cucumber-java-skeleton
Feature file `belly.feature`
Unfortunately the IntelliJ IDEA Cucumber plugin does not (yet) support a link between the steps in our feature file and our step definitions, like it does for Java. Also, we cannot generate snippets in Kotlin directly. Fortunately there is a work around: we can run the tests to generate snippets in Java 8 lambda style.
You can run the test from IntelliJ IDEA by right-clicking the feature file and selecting “Run ‘Feature:belly’” from the context menu.
When you run the tests, you should get something like the following result:
Generated snippets
Add Step Definitions
In the src/test/kotlin folder, we add a new Kotlin File/Class, called `StepDefs`.
We only have to write a little Kotlin code in the file:
Create StepDefs.kt
Note that our StepDefs implement the `cucumber.api.java8.En` interface, so we need to import it.
Now, when we copy-paste the generated snippets inside the `init{}` block, IntelliJ IDEA offers to convert it to Kotlin for us. Once we do, we will also need to import the `cucumber.api.PendingException` mentioned in the snippets.
Now we have the following StepDefs.kt file and we can start implementing the steps, as well as the code to make them pass!
Add snippets to StepDefs.kt
To run our features from a JUnit runner, we’ll need to add one. In the src/test/kotlin folder, we add a new Kotlin File/Class, called RunKukesTest.
