From time to time we receive questions from our users about a setting called “Build System” under Upsource Properties on Project Setting page:
The most common ones are: “Why do I even need to specify build system?” and “What does it do?”. Sometimes there’s also confusion about what exactly one needs to specify there. While we do plan to address this ambiguity through UI modifications, we feel it’s a good idea to explain why a code review tool even needs it in the first place and what to do with it.
In short, this setting unlocks all the code insight and intelligence Upsource offers for Java teams. So if you’re using Upsource to perform code reviews on a project written in another language, feel free to ignore it. But if your team uses Java, and you want to make use of IDE-level server side code inspections and navigation, then keep reading:)
Currently 3 types of build systems are supported: IDEA, Maven and Gradle. Let’s take a look at each of them.
Upsource has IntelliJ IDEA engine built in to provide the same level of code intelligence as IntelliJ IDEA does. Needless to say, Upsource natively understands IDEA project model, so you only need to let it know where the
.idea folder is located.
In some teams each developer configures their IDE to their liking and everybody has different
.idea, which they
.gitignore, so in the end there’s no
.idea folder in the repository. However, the recommended way is to store most of the
.idea folder contents in version control, only omitting the user-specific settings, such as
.idea/shelf – this way Upsource will be able to provide Java code insight for your project.
Things are a bit different for Maven/Gradle project models, as IntelliJ IDEA engine does not understand them natively. To be able to offer code insight for Java projects with these models Upsource first converts specified project model to IDEA format and uses it later on. If your
pom.xml doesn’t have unresolved dependencies and builds fine without Upsource, it should convert properly into IDEA format as well: you can always check if all went well in the
maven.out/gradle.out file. To find it, open your Upsource project, click Browse code at the top of the revisions list and navigate to
Not sure which
pom.xml to specify in Upsource properties? You need the one that knows about all the modules you have and you want to have code insight for, i.e. it should be the parent pom. If your project modules are hosted in multiple repositories (e.g. each module in their own repository), you can configure them all in one Upsource project, and keep the parent
pom.xml in the first repo.
When it comes to Gradle, the number one troublemakers are Android Studio projects. Unfortunately, Upsource does not support them at the moment. We are looking into it, and by all means feel free to follow/upvote the issue.
There also have been known cases when gradle plugin converted project model, and configured wrong SDK. It’s a known Gradle bug. For the moment, if this is happening, you can find the workaround here. If you plan to work on Gradle projects without a wrapper, please check Upsource documentation for the instructions.
Naturally, we are always happy to answer your questions if you have any.