Gradle Plugin not looking in all dependency repositories

Answered

Hi,

We're trying to use the TeamCity Gradle plugin, but we're getting this error: 

[Step 2/4] org.gradle.api.plugins.UnknownPluginException: Plugin [id: 'net.ltgt.apt-idea', version: '0.21'] was not found in any of the following sources: - Gradle Core Plugins (plugin is not in 'org.gradle' namespace) - Plugin Repositories (could not resolve plugin artifact 'net.ltgt.apt-idea:net.ltgt.apt-idea.gradle.plugin:0.21') Searched in the following repositories: Gradle Central Plugin Repository

We're expecting other repositories besides the Gradle Central Plugin Repository to be searched since in our build.gradle file, we have included a few of our own private dependency repositories in the format below. Is there anything else we need to do to tell the Gradle plugin to search in our private dependency repos? 

repositories {

        maven {

            url "our-private-repo-url"

            credentials {

                username = "${artifactory_user}"

                password = "${artifactory_password}"

            }

}

 

 

 

 

0
1 comment

Hi Spencer,

 

if you check the build log, you will notice that teamcity pretty much delegates the task to gradle itself. There would be some adjustments to ensure that teamcity can plug in some elements but it should not interfere with dependency resolution, particularly it should not substract from the repositories defined in your gradle files. I'm also not familiar with teamcity unable to hit specific repositories that are properly defined in the gradle files, so I'd recommend double checking that it works otherwise and in your environment it's not being pulled from a local cache rather than the remote repo.

 

There is a few checks you can perform to try to narrow down exactly where the problem resides. We have a detailed step by step guide of how to troubleshoot this issues in our docs: https://www.jetbrains.com/help/teamcity/common-problems.html#CommonProblems-BuildworkslocallybutfailsormisbehavesinTeamCity

 

In particular, we'd suggest changing your gradle step to a command line step where you just call the gradle tasks that you require (using the wrapper and/or not using it) and see if the behavior replicates there or not. If it does replicate, it seems like the issue is with gradle trying to run the gradle files, maybe due to missing configuration on the files themselves or because the environment is missing something else entirely. If it does not replicate, then there might be an issue with how teamcity handles your specific gradle files. In this situation, we usually recommend collecting a full set of data and forwarding it to us. Basically a set of build logs, server logs and preferably some of the project files that we can use to replicate the issue on our own end. Details about what and how are specified in the article I linked above.

 

Hope this helps. Please feel free to follow up at any point if you have further questions or issues with this.

0

Please sign in to leave a comment.