Resolve files added as dependencies

Help/Discuss
1

In my multi-subproject build I have the following in a buildSrc gradle file:

/**
 * Load Java dependencies from .classpath file  
 */
ext.parseClasspath = { ->
  
  def classpathFile = file('.classpath')
  def fileParser = new XmlParser().parse(classpathFile)
  def libPaths= []
  
  fileParser.classpathentry.each {
    if('lib' == it.@kind) {
	  libPaths.add(new File(rootProject.projectDir.absolutePath + it.@path))
    }
  }

  return libPaths
}

Applying the file to a project I can then use the project.parseClasspath() method to load files that are dependencies from my .classpath files in the root of the subproject. Passing this to

dependencies  {
  implementation files(project.parseClasspath())
}

But as of recently this has seemed to have changed and my dependency resolution results in unspecified in the dependency tree but also failing builds as my code can’t find the dependency jars in the classpath.

Again this has worked before. I’m confused as to why it broke.

Any suggestions as to what I should change?
This is a larger migration process from Eclipse and Ant so I can’t show everything of the new configuration.

Thanks in advance!

2

I haven’t used Eclipse in a number of years, but from what I remember, you may want to duplicate the original .classpath file and use that as your source for now. The problem possibly being that you want Gradle to use the .classpath for your dependencies, but Eclipse will potentially start rewriting the .classpath file based on evaluating the Gradle project depending on what project facets get enabled. You’d probably have to look more at the contents to determine if that’s what is happening, but that’s what comes to mind with your description.

3

That’s entirely possible, but as the project will remain in both Ant and Gradle for the forseeable future the Eclipse users will still have .classpath files and those will remain. I know I see the right file paths when debugging the gradle.

What I can think is possible is that the ArrayList being generated by the parseClasspath is not correctly understood by the files() function here. If that’s the case an alternative would be nice.

4

Circular dependences are generally not a good thing in software. Of course the .classpath will remain for the Eclipse side, but you don’t want Gradle (depending on) → .classpath (modified by Eclipse based on) → Gradle. It would be useful to determine if that is happening (or at least provide a minimal .classpath that has the elements that you currently have even if generalized) to make sure something there isn’t causing a problem.

You originally stated that the code there was previously working. If nothing has changed in the code, the .classpath file contents is the only variable here, which definitely gets modified by Eclipse. As you mentioned, you can’t show everything in the migration, but an example .classpath is probably the minimum required to provide any more guidance without stumbling around trying to guess what might have been in the file between when it worked and didn’t.

Then at least it can be determined if this is the problem, or if it’s something else in the project that is impacting things.

5

After a while of digging I found out that the dependencies were working just fine. The bigger issue was that the .classpath and the directory we managed our jars with weren’t aligned anymore. Sadly Gradle simply wasn’t able to tell me the jar I was expecting to add as a file() dependency weren’t there anymore.