Filesystem repository with nested directories?

(Marco Cicolini) #1

I am in the middle of the migration of a quite old ant build to a gradle build.

Currently i am facing a problem with the dependency management. We keep/kept our dependencies in a flat directory base repository in a similar structure like maven, but not identical and without the corresponding metadata.

I know that the the flatDir repository does not look into nested directories, so it is not usable for this use case.

As an example i have the following two dependencies:

'/repo_path/jakarta/commons-lang/2.3/commons-lang-2.3.jar'
'/repo_path/jakarta/log4j/1.2.16/dist-bin/log4j-1.2.16.jar'

Where the repo_path is the file system directory under which the dependencies are located.

I would like to use those in a common way:

dependencies {
  compile "jakarta:commons-lang:2.3"
  compile "jakarta:log4j:1.2.16"
}

Unfortunately the directory structure is not always the same :S, but this is something i may handle otherwise.

So my question, is there a way to define a repository in gradle which is able to file system dependencies with nested directories?

Ivy might help with this, but i do not know how to set it up properly because there are not ivy metadata files. We might migrate to common maven dependencies, but this is currently out of scope. I started using simple file dependencies, but with those gradle has no idea what i am doing and all the dependency management benefits are lost :S

(Jon Austen) #2

If I were to guess ( and I may be wrong), do something like this:

repositories {
    mavenCentral()
    maven {
        url "file:////mySharedRepoServer/repo_path/jakarta/"
    }
}
(Marco Cicolini) #3

Thanks for the response unfortunately it didi not work :S

But i came up with a different solution with an ivy repository, which looks like this:

repositories {
    ivy {
        artifactPattern "repo_path/[organisation]/[module]/[revision]/[module]-[revision].[ext]"
    }
}

This seems to work like a breeze even though there is no metadata present :slight_smile:

(Marco Cicolini) #4

My solution worked out for single jar dependencies without any transitive dependencies. For those metadata would be necessary.

As an example i have an axis 1.6.1. verison which requires a whole lot of transitive dependencies, which are all within a lib directory, and this is how i currently add this dependency:

dependencies {
 axis2 fileTree(dir: 'path_to_repo/apache/axis2/1.6.1/lib', include: '*.jar')
 }

I still ask, whether it would be possible to tell gradle that this is a dependency in a way, even though i am pretty sure there is no way to solve that issue.

I seems i have get used to the task of migrating the dependencies to a maven repository.

#5

There’s no way at present to get Gradle to implicitly understand your custom repository structure. Without a meta-data file, Gradle will check for the existence of a jar file matching the module name, but the module is assumed to have no declared dependencies.

I can see 2 options:

  • It may be possible (but not trivial) to implement an Ivy DependencyResolver that understands your repository structure. You can then use this DependencyResolver in Ivy. - You could use Gradle (or another tool) to generate ivy.xml files for each of your top-level dependencies, and add these meta-data files to your repository. You could then resolve your dependencies using MavenCentral to access the transitive dependencies instead of the nested “lib” directories. This solution may not exactly replicate your current repository, but it could vastly simplify your build!
(Marco Cicolini) #6

The second option might be an approach i could work with, not sure though if it is possible to add that metadata to the repository.

I just saw that it is possible to define transitive dependencies within a dependency declaration

Even though this is nice, i get back to the problem that our repository has no metadata. So i think migrating all the dependencies to proper maven dependencies is the least work, since this task might come anyway.

Thanks for all the answers :slight_smile: