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.

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)

streamyard, virtual backgrounds, and room dividers

I live in a studio apartment. That means quite a bit of stuff is visible from my computer camera. As you might imagine, I’m a bit fan of virtual backgrounds. For work, it is easier. It’s not a problem if my co-workers see my work stuff, I don’t care if they see my mess and seeing a place that isn’t ideal for work just shares the message that I’m not enjoying my working from home full time here.

For non-work, it’s even harder. I have a nice spot for my personal machine/desk. I didn’t have a good spot for my work machine/documents. I wound up using the “empty” path that is right behind my personal computer. (Empty is in quotes because I used to do physical projects, store things there, dump them as I walked in, etc)

This means that the camera on my personal machine has a great view of all my work stuff. For JChampions Conf, I’m moderating a few sessions. Streamyard doesn’t have virtual backgrounds (unless you have an actual green or blue screen.) I don’t know how much I’ll be on camera if at all. But I won’t know until the day of. This leaves me with some inconvenient choices.

  1. Put away my work stuff. That’s problematic as some of the sessions I’m moderating are adjacent too or in between work hours.
  2. Move my personal laptop elsewhere. That’s awkward because I have two monitors, a proper keyboard, etc at my personal desk. Moving to the couch or my bed is not going to be comfortable.
  3. Turn off my video and be audio only. The default image is a blank circle. That looks terrible. (I don’t know how to upload a photo instead. And it’s a shared account so I wouldn’t even if i could.)
  4. Use a physical barrier. I own a room divider so I dragged it behind me. It’s annoying to set it up and leaves a crack of orange (the wall). But it does hide the stuff. I actually thought about using it to block off my work area so I wouldn’t see it constantly. But it comes with a limitation. I have a width of 14 inches to get to my personal computer and a width of 13 inches to get to my work machine when it is setup. Which means I’m not leaving it up and will need to set it up each of the four days. (The width of a human shoulder to shoulder is typically larger than 13-14 inches so I have to turn sideways to move around my apartment when this is setup.