Gradle is not able to use dependencies from Artifactory


(Vinay Verma) #1

I am dealing with project and subproject architecture in gradle script. When running build from Gradle, It is not searching the dependencies (Third party dependencies) at the correct path while dependencies are present in Artifactory.

I am getting error msg like this:

 Searched in the following locations:
  http://ServerIP:Port/artifactory/jcifs/jcifs/1.1.11/jcifs-1.1.11.jar

I deleted dependencies from Artifactory and uploaded again still gradle is not able to use them.

Note: For those projects under which I am not using project/subproject architecture, I am able to use dependencies there, but not in one particular project.

Please suggest any resolution for the problem.


(Dimitar Dimitrov) #2

Your build is wrong. Post more details if you need more precise answer. In particular the repository definitions, as well as what is a proper URL to an artifact.


(Vinay Verma) #3

Hi,

Please find code which I have written to publish the generated artifacts.
my code is:

 buildscript {
    repositories {
	     jcenter()
      }
     dependencies {
	     classpath "org.jfrog.buildinfo:build-info-extractor-gradle:4+"
      }
  } 

  subprojects {
     apply plugin: 'java'
     apply plugin: 'distribution'
     buildDir = new File("$buildPath", project.name)
     ext.distributionDir = new File(project.buildDir, 'distribution')
     sourceSets {
	    //SourceSets
     }

     ext.sharedManifest = manifest {
	      //Manifests
     }

     tasks.withType(Jar) {
	      //Code to generate Jar Artifacts
     }

     //FYI : If I enable this commented flatDir part of sript, everything is working fine and Publishing artifacts on Remote Artifactory repository.
     //But when I comment the same, gradle should pick the dependency mentioned in project part from Remote Artifactory URL which I already published there.	

    //	repositories {
    //		flatDir {
    //			dirs file("$dependencyPath"),
    //		}
    //	}

     allprojects {
        artifactory {
	    contextUrl = "${artifactory_contextUrl}"
		publish {
			repository {
				repoKey = 'gradle-dev-local'
				username = "${artifactory_user}"
				password = "${artifactory_password}"
				maven = true
			}
		}
		resolve {
			repository {
				repoKey = 'gradle-dev'
				username = "${artifactory_user}"
				password = "${artifactory_password}"
				maven = true
			   }
		     }
	        }
         }
      }
      project(':projectName:ProjectComponent') {
      sourceSets {
	      main {
		      java { include '/pathToCode/*' }
	        }
          }

          dependencies { compile (group: 'jcifs', name: 'jcifs', version: '1.1.11')}

          //******* Publishing Component Jar (Build artifacts on Remote Repository) ********//

          publishing.publications {
	       mavenJava(MavenPublication) {
		   groupId 'GroupID'
		   artifactId project.name
		   version = projVersion
		   from components.java
	   }
    }
    artifactoryPublish {
	  publications(publishing.publications.mavenJava)
     }
    }

Dont understand why gradle is searching at the wrong path:

Searched in the following locations:
  http://ServerIP:Port/artifactory/jcifs/jcifs/1.1.11/jcifs-1.1.11.jar

Please be informed that code is working fine if I am using flatDir (Commented section in the script). But when I dont use flatDir, Gradle is not picking dependencies from remote server and throwing error msg which mentioned above.


(Dimitar Dimitrov) #4

Is this the complete build? Looking at you artifactory config, the URL should contain “gradle-dev-local”, while the one you pasted doesn’t - could you confirm that?

If no, then Gradle is not using the artifactory to resolve this dependency - run again with -s and paste the stack trace here.

In general, when you use the artifactory plugin you shouldn’t need any “repository” sections, except for the buildscript section.


(Vinay Verma) #5

Hey, Thanks for the suggestion. It worked :slight_smile:
I added repository name in the URL and it can now get dependencies from Artifactory
:thumbsup:

Regards,
Vinay


(Dimitar Dimitrov) #6

God you got it working, but in general you shouldn’t put the repo id in the context URL.

The context URL is the Artifactory webapp root. The artifactory plugin installs a custom resolver using the resolve/repository/repoKey you provided.

This allows you to easily externalize the repo ID as a build property and (for example) switch it to different repos depending on whether you are building snapshot or a release artifact.


(Vinay Verma) #7

I didnot pass the repository name in contextURL part but separately defined a maven repository block. Something like below and I got it working then.:

repositories {
	maven{
 		url "${artifactory_contextUrl}/gradle-dev/"
	}
}

(Dimitar Dimitrov) #8

That’s not how it works. As I mentioned, if you use the Artifactory plugin, you are not supposed to define extra ‘repositories’ sections.

Right now your settings are conflicting and even if your build works now, it may break in mysterious ways when you upgrade Gradle or Artifactory plugin.


(Vinay Verma) #9

Yes, You are correct. This particular is the special case. My rest of the projects are working fine without using any extra repository section.

My rest of the projects are not having :project and :subproject architecture. So, thought to let it go if running fine :slight_smile:


(Dimitar Dimitrov) #10

Not sure without checking, but it may be that you have to apply and configure the Artifactory plugin in an allprojects { ... } block. Or individually in each project if any projects have special configurations.


(Vinay Verma) #11

Ohk, Perfect.
I will try with individual projects then :slight_smile:

Thanks! :slight_smile:


(Basil Peace) #12

There is a reported bug that Artifactory resolve configuration doesn’t work: https://www.jfrog.com/jira/browse/GAP-261
Could you comment on that?

For me using standard repositories was the only workaround I could find.


(Dimitar Dimitrov) #13

I don’t know - works for me… you could debug the build if you are curious, but if you have a reliable workaround you may as well go with it.