Java dependancy management on GitHub private repos?

Viewed 61

My team uses a GitHub.com organization to keep all of our source code in private repos. (Prior, our old workflow was emailing Dropbox links). Most of the time each repo is one separate project with no dependancy of any other (the only dependancies are on third-party open source libraries). Or if there is some dependancy, then the .java files have just been copy pasted into the other project.

I've recently been splitting up some of my code into reusable modules, but I don't know any way to do the dependancy management when I use the libraries I'm creating in another project.

I know with Gradle you can add a git repo like this:

gitRepository('https://github.com/user/project.git') {
    producesModule('user:project')
}

but I don't know if there's a way to make it work with private repos, and I don't know if there's a way to specify versions.

My currently solution is to just build the library JAR, and keep track of the binary version with GitHub release tagging, and when I need to use the library in another project, I download the desired version of the JAR (typically the most recent) and add it to a local /lib/ folder in the other project and import the JAR into the module path as a local JAR. Of course I need to go through the whole process again manually if I want to make a change to the library.

I also heard you can set up private Gradle or Maven servers and some companies do that, but I guess that would mean migrating away from GitHub.com?

Is there any way to make this work (either Gradle or Maven, it doesn't matter) to manage dependancies between GitHub private repos?

Can someone tell me, what is the most sensible way (or ways) to solve this?

Thanks.

1 Answers

What you need is a very typical maven/gradle based setup where

  • each of your projects will be producing an artifact with a coordinate of the form group:name:version

  • your projects do not have to be explicitly aware of each other. They depend on the artifacts produced by other projects. This is called binary dependency

  • for a project to locate a binary dependency, you will need a central registry where you can publish all your artifacts to. GitHub has a product called GitHub Package for precisely this purpose.

  • If you don't want to use GitHub Package yet, or your setup (number of projects, size of each projects, size your team) is small enough, you can locally checkout all the projects and include them into a gradle composite build so that binary dependencies will be substituted with local project dependencies. The good thing about the composite build is that when you decide to invest in a package registry, your build.gradle requires no change at all.

BTW, where you run your private package registry does not really matter. You can use the GitHub Package, or some other hosted services, or even run e.g. jfrog artifactory on your own server. It is completely unrelated to where you host your source code, so you dont need to migrate away from GitHub in any case.

Related