In Azure DevOps we use Private Build Servers. Due to the licensing requirement passed on by Oracle for Java, we removed Java from our Private Build Servers only to find that all our builds broke. We were surprised to discover that the SonarQube task places a “Demand” capability for the inclusion of “Java”.
The part that surprises me about this is that why is Java required on the Build Server when our SonarQube installation is on a totally separate server? Why do I need Java to be installed on my build server when SonarQube is not even on it? That was my first problem.
I thought I would get around this problem by installing OpenJDK only to find my build still failed. It turns out through a Forum topic I found: Azure DevOps hosted build "java" demanded capability not present that I need to create a Demand capability to fake it out. I noticed that Dave Skender has submitted a fix for this issue back in April, but it has not been taken up by the SonarQube team. I was wondering if they plan on doing this? Also, I was wondering if there is a plan to address the fact that SonarQube is not on the Build Server either and not place a “Demand” on the pipeline in Azure DevOps to include Java when it is not needed. If it is needed for the task, then at least support a different type of demand to include OpenJDK or Azul etc.
To answer your first question, Java is required on the build agent because the Sonar scanner and language plugins are written in Java and they run on the build agent.
The reason installing the OpenJDK didn’t fix your build is because of this bug in the Azure DevOps Windows build agent, which we can’t fix or work round in our extensions. I’ve just pinged Microsoft to ask about the status of the bug.
The discussions about the bug and possible fixes in the PR and community thread to are rather long so I’ll summarise the main points:
“Java” is the correct demand for Azure DevOps extensions that require Java to be installed on the agent. It doesn’t specifically mean the Oracle Java installation.
The Microsoft build agent is responsible for detecting the capabilities of the build agent. It should recognise different Java installations, and indeed it does so on Linux. However, there is a bug in the Microsoft agent detection code on Windows build agents and so it currently only recognises the commercial Oracle Java installation.
The bug only affects self-hosted Windows build agents, and manually adding a “Java” demand is a the workaround recommended by Microsoft.
There isn’t anything we can do in our extensions to work round the bug. The Azure DevOps demands/capabilities system does not provide a mechanism for declaring optional/conditional demands. If we change the demand from “Java” (e.g. to “java_home”) then we’ll break self-hosted Unix build agents. If we remove the demand then we’ll break Azure DevOps Server’s ability to allocate jobs to the correct agents.
I hope this helps explain the current position.Until the build agent bug is fixed I’m afraid the best option for self-hosted Windows agents is to use the workaround suggested by Microsoft.
Hi Duncan, yes sorry, I should have noted that here. I created a case with Microsoft on this a while back and they fixed the issue for the Maven task only, which at the time is where I had the issue. Then the same issue popped up recently in the Gradle Task. So I opened a new case with Microsoft and this time I pointed them to this forum item, which they confirmed was a bug and so they fixed it at the root cause rather than for just the Task exhibiting the issue. So this should be good going forward now.
