Paul Hammant's Blog:
Checking in binaries
When Maven came out some twelve years ago, the Java community became comfortable with not checking in third-party binaries. In the Ant era, before that, you did. Maybe we were being kind to source control systems, but we opened a new can of worms.
While I spent a lot of time being an advocate of that design, I’m not any more. It’s time we checked in binaries again, and yes that means even into Git (where small repos historically rule).
Gradle
Gradle is a very elegant and terse build grammar for the Java eco-system. Inside their main SDK download, there is a “samples/webApplication/quickstart” folder that has a neat minimalist “hello world” web app. Putting that under source control with “git init” is easy :)
cd samples/webApplication/quickstart
git init
wget --no-check-certificate https://www.gitignore.io/api/java,maven,gradle --output-document=.gitignore
mkdir gradle_home
gradle --gradle-user-home gradle_home war
git add gradle_home
git commit -am "check in downloaded jars n all"
But if you run the gradle line again, it does things that would result in another checkin, when it should not In my opinion:
modified: gradle_home/caches/2.1/scripts/build_jmcktaacs2o3f7glfb3tb17ev/ProjectScript/buildscript/cache.properties
modified: gradle_home/caches/2.1/scripts/build_jmcktaacs2o3f7glfb3tb17ev/ProjectScript/buildscript/cache.properties.lock
modified: gradle_home/caches/2.1/scripts/build_jmcktaacs2o3f7glfb3tb17ev/ProjectScript/no_buildscript/cache.properties
modified: gradle_home/caches/2.1/scripts/build_jmcktaacs2o3f7glfb3tb17ev/ProjectScript/no_buildscript/cache.properties.lock
deleted: gradle_home/caches/2.1/scripts/build_jmcktaacs2o3f7glfb3tb17ev/ProjectScript/no_buildscript/classes/build_jmcktaacs2o3f7glfb3tb17ev$_run_closure3.class
deleted: gradle_home/caches/2.1/scripts/build_jmcktaacs2o3f7glfb3tb17ev/ProjectScript/no_buildscript/classes/build_jmcktaacs2o3f7glfb3tb17ev$_run_closure3_closure4.class
modified: gradle_home/caches/2.1/scripts/build_jmcktaacs2o3f7glfb3tb17ev/ProjectScript/no_buildscript/classes/build_jmcktaacs2o3f7glfb3tb17ev.class
modified: gradle_home/caches/modules-2/modules-2.lock
Too bad. Maybe Gradle 3 will rework the caches folder to more clearly separate sections that can be checked in, from those that should not be.
Maven
I didn’t try Maven as I could not work out how to redirect the local repository without changing settings.xml for all projects.
Comments formerly in Disqus, but exported and mounted statically ...
| Mon, 20 Oct 2014 | Brett Porter |
Hi Paul, The setting you're looking for in Maven is -Dmaven.repo.local=path. The hard part there is multi-module projects where you'll need use an absolute path since the base directory changes. This will contain everything - including Maven's plugins and their dependencies, which may not be what you intended. The other alternative is an approach like this, using a filesystem based remote repository in the checkout: http://brettporter.wordpres.... I'd be interested in hearing your rationale for changing your mind. I understand there are some benefits like first build experience, reproducibility, security and better visibility of your dependencies - but still believe these are best handled through a proper artifact management strategy. The downsides of checking them in is not only repository size (which is not insignificant over time!), but also lacking centralised capability for reporting, discovery, consistency, etc. | |
| Tue, 28 Oct 2014 | Guest |
Not clear on what the can of worms is, and why you want to start checking in binaries again. If you're trying to maintain absolute control over your dependencies maybe you should consider a repository manager like Nexus. | |