3

I always like to backup project dependencies myself in case they can't be resolved due to a down website or because certain versions aren't available for download any more.

Should I trust the maven central repository to be up and running when I try to build my project in 2020? Or should I backup dependencies manual?

If I should backup manual, then where does gradle store the downloaded dependencies? Or does gradle come with an build in solution for this?

6
  • Should you trust your application to be of the same build in 2020? Is the question here. ;) Feb 2 '15 at 11:53
  • @CeilingGecko not really true.. I just want my achieve of old projects to be working when I try to build it.
    – Rolf ツ
    Feb 2 '15 at 12:01
  • I would like to believe that libraries will not just get removed from the repositories for no apparent reason, and since there are still files available from 2002, I'm fairly optimistic that today's libraries will still be there in 2020. Feb 2 '15 at 12:20
  • Do you have a neatly packaged archive for installation as opposed to compilation? If so, there are your dependencies. While it may take some extra work, the build environment could be updated in the future to make use of those libraries.
    – user22815
    Feb 3 '15 at 0:45
  • 1
    @Rolfツ You have one option, we used in the company where I had my exam time, we created a company internal maven repository. That was cheap to do and worked fairly nice :)
    – Knerd
    Mar 3 '15 at 13:46
5

For my important projects I try to make sure I have a backup of the following:

  • Dependencies for all releases.
  • Installation packages and instructions for all important tooling, such as IDE and compilers (used to build the application).

Saving them in your version control system is not the right thing to, as it is not created to store large blobs. Instead I use backuped project drive.

Automated solution with Nexus

For maven central (and comparable) dependencies you also have another option. I have done this in the past with Maven, but it can also be done with Gradle. The solution is to run Nexus as a cache. Instead of directly downloading your dependencies from Maven Central, you tell Gradle to download from Nexus, which in turn can be set up to download dependencies from a central repository, caching the artifacts in the process.

As noted by Sleske in the comments: Make sure that the cache is not automatically cleaned by Nexus. Also the following will have the added benefit that other local users will be able to download dependencies locally (so possibly quicker).

2
  • 1
    Yes, this is the right solution. Note that an added benefit is that local users can retrieve dependencies faster, because they are loaded from a local system (Nexus). Just make sure that Nexus does not purge its cache, except in situations where you checked that it's safe.
    – sleske
    Mar 3 '15 at 16:21
  • @sleske Good point, edited my answer to reflect this.
    – Thirler
    Mar 4 '15 at 7:36
2

First, you are not alone with this questions and in our company I tried to answer this questions a dozen times. Here are my answers:

Should I backup gradle dependencies to git?

No, not in the git repository. In my opinion a source repository should be as small as possible, because I don't like to checkout a repository for hours.

Though it might be good to backup anyhow, but how?

I solved this by simply creating a zip of a working sandbox and the downloaded dependencies:

./gradlew -g ./backuped_USER_HOME build
cd ..
<zip Project>

If you want to build your project simply unzip it and use the backuped USER_HOME directory by

./gradlew -g ./backuped_USER_HOME --offline build

where --offline might be superfluous.

CAUTION: If you have any custom targets you should also run this directly or implicitly since otherwise gradle would not download the dependencies it needs for the custom tasks.

Not the answer you're looking for? Browse other questions tagged or ask your own question.