opening multiple intellij modules in the same project and remembering them on reopen

This is the number one problem that has prevented me from using IntelliJ more and I finally know how to do it. (I’ve known how to open multiple modules for over a year. What I learned yesterday at the IntelliJ 20th anniversary conference was how to reopen that same set)

Note about terminology to Eclipse users

If your primary IDE is Eclipse, keep this difference in terminology in mind as you read this.

EclipseIntelliJ
WorkspaceProject
ProjectModule

Step 1: Create a dummy/grouping project

Create a new project. This project’s purpose is to contain the modules you want together and give it a distinct name. I’ve been keeping them in an IntelliJ folder in my home directory to avoid confusion. (Most of my stuff is under the git folder in my home directory). The idea of keeping them separate is so I know there’s not code in there.

Step 2: Add your modules

There are several ways of adding modules. Any of them are fine. I find the fastest for repeated adds is:

  • File > Project Structure > Modules
  • Click “+”
  • Choose “Import module”
  • Navigate to the build file (ex pom.xml) or .iml file for generic projects

Step 3: Rename the project (if needed)

On rare occasions, I noticed the project name got my first module name. I couldn’t reproduce this, but started double checking. This name is what will show up in your recents list.

  • File > Project Structure > Project
  • Enter a new name if needed

Testing

File > Open Recents and open another project. Then File > Open Recents and open this project. Admire how all your modules are back!

Seeing the modules on disk for the curious

In the dummy project, the .idea directory has a misc.xml file. I was told it contains all the modules. And it did when I tested on Windows

<list>
  <option value="$USER_HOME$/git/myProj/pom.xml" />
  <option value="$USER_HOME$/git/myProj2/pom.xml" />
</list>

When I tested on Mac, modules.xml had this info

<modules>
   <module fileurl="file://$USER_HOME$/git/myProj.xml" filepath="$USER_HOME$/git/myProj.xml" /> 
   <module fileurl="file://$USER_HOME$/git/myProj2.xml" filepath="$USER_HOME$/git/myProj2.xml" /> 

</modules>

And a note about “you are doing it wrong”

I am an Eclipse power user and an IntelliJ competent user. What holds me back is not using IntelliJ more at work because of not knowing how to do this. While I don’t want to replace my usage, I do want to be an IntelliJ power user and use Eclipse enough to not lose my skills! I think this is the thing that will do it!

When I’ve tried to find out how to add multiple modules and have them remembered multiple times in the past, I was told that I was “using IntelliJ wrong” and should have one project that I focus on. (I work on many sets of small related projects; that model doesn’t work for me.)

Yesterday, someone attempted to tell me that I should have one big project that I focus on at a time. (aka my problem doesn’t exist.) After explaining what I do, another user said he does that I do. The first user said something about religion. That seems like just it. There’s multiple religions. It’s fine to be passionate and a true believer in yours. But as part of society, accepting that other people believe differently is part of life.

Happy Book Birthday! OCP Java 11 Practice Tests Now Shipping!

Jeanne and I are ecstatic to announce our new book, OCP Java 11 Practice Tests, is now shipping! It’s the first book in print custom written for the new 1Z0-819 Java 11 Certification Exam as well as the 1Z0-817 Java 11 Upgrade Exam.

Want to become Java 11 Certified but not sure where to start? Purchase our new Java 11 Practice Tests book along with our Java 11 Complete Study Guide, now available as The Java 11 Complete Certification Kit. While Oracle restructured the 1Z0-815 and 1Z0-816 Exams into the 1Z0-819 Exam, the material is almost identical (see this post for more details), making the Java 11 Complete Study Guide along with our new Java 11 Practice Tests Book the best source of material for learning everything you need to become a Java 11 Certified Professional!

Like our previous books, we will post any updates or notes on this blog’s Java 11 Practice Tests Book page.

A special thanks to all of our friends and family that helped write this book in the midst of the global pandemic. It’s been a challenging year and we couldn’t have done it without your support!

Switching your Gradle builds from JCenter to Maven Central

JCenter is being decommissioned on May 1st, 2021. Since many Gradle builds use JCenter by default, this means your Gradle build file is likely to have jcenter() in it. This means you have a few months to switch to Maven Central. Don’t worry, it’s easy.

Note: If you work for a company, you are hopefully using an internal binary repository proxy. (ex: Nexus, Artifactory, etc)

What’s the difference between JCenter and Maven Central?

The main benefits of JCenter are:

  • Some artifacts are in JCenter and not Maven Central – their authors are working on moving them to Maven Central. This is unlikely to affect FRC teams, but might affect people using an artifact that is more specialized.
  • It’s easier to publish to JCenter – Sonatype has been working on making it easier for Maven Central. Some of that is intrinsic though because Sonatype does a lot of verification.
  • JCenter is faster – Remember that artifacts are cached on your machine. So once you’ve downloaded the artifacts, your build performance is the same.

How do I find the affected files in GitHub?

Searching on github for either of these does not do what you might expect

  • jcenter user:boyarsky filename:build.gradle- the code tab returns 0 results
  • jcenter org:stuypulse filename:build.gradle – the code tab returns 2 results

That’s because github search only looks in files that have been updated or returned in search results in the past year. Unfortunately, the last year has not been particularly representative of a normal year. And people edit/search the contents of build.gradle files way less frequently than other file types.

I recommend just searching for the filename. That returns all your build.gradle files so you can edit them. (And since you are probably consistent in your choice of binary repository, you can sample a few matches to see if you have to change.

  • user:boyarsky filename:build.gradle – the code tab returns 5 results
  • org:stuypulse filename:build.gradle – the code tab returns 24 results

Tip: You may also have a reference to jcenter in your settings.gradle so I recommend searching that as well.

How do I edit the file?

GitHub has good Rest APIs so you can script this if you have a lot. If you don’t have a ton, either of the following is viable. (I had 5 build.gradle files in my personal repo and 3 of them were already using Maven)

Option 1 – Use the browser

  1. Open each link from the code tab of the search
  2. Choose the default branch (ex: main/master) from the pull down – search often returns a specific commit
  3. Drill down to the build.gradle file if not already there.
  4. Click the edit/pencil icon in the top right (just above the code)
  5. Change jcenter() to mavenCentral()
  6. Enter a commit comment and save
  7. If you want to make sure your build still works, run it (ex: Travis)

Option 2 – Clone the repos

(Tested on Mac; I don’t have Git Bash on my home computer so don’t know if it works exactly the same. I have used find on Git Bash though so I think it does)

  1. Clone the affected repos (if you don’t already have them)
  2. Go to a parent directory of the github repos (ex: <userHome>/git
  3. Run a UNIX command to update the list files find . -name build.gradle
  4. Run a UNIX command to update the affected files: find . -name build.gradle -exec sed -i ” -e ‘s/jcenter/mavenCentral/g’ {} \;
  5. Commit/push the affected repos (listed in step 3)
  6. If you want to make sure your build still works, run it (ex: ./gradlew build)