TL;DR: We want/need to package all libraries used by our build into the final distribution.zip as a repo including metadata (poms). Below is why, and the question is “how?”
We are building an application framework for use by our own consultants in various projects. The application framework has many dependencies (currently 311 jar files across all our components), most of which can be found at various public maven repositories. For the ones that don’t have maven coordinates, we have created private pom-files which fulfill the job, so that gradle can use those to track dependencies.
Our requirements specify that we must ship the dependencies along with the framework. This has both practical reasons (several client sites are not connected to the internet) and legal reasons (contracts and escrow regulations stipulate that the deliverable must include “all necessary libraries and tools”). Also, we have been bitten by public repositories going offline and disappearing, which leads to nothing good.
Traditionally (back from ant-times), we have manually downloaded jar files and stored them in a directory structure in subversion, then used manual dependency management to make sure we got all the proper inclusions. We have, of course, messed this up more than once, and the applications built on this have a tendency to always include all the available jar files, no matter how many were needed.
We can solve the legal requirements by using the mechanism used by Spring to build their “dist-with-deps” version, as shown in https://github.com/SpringSource/spring-framework/blob/master/build.gradle#L948. This lets us collect all the jar-files in a directory, but of course we loose all the transient dependencies, and our projects will have to deal with dependency management manually. We don’t want that.
Instead, what we would like to do is to have our build process build a maven repo with all dependencies, including pom files and signatures, and have that included in the distribution, somewhat like below (directory structure is simplified to save vertical space). :
\--- distribution.zip
+--- docs
+--- repo
+--- com -> fasterxml -> jackson -> core -> jackson-core -> 2.2.2
+--- jackson-core-2.2.2.pom
\--- jackson-core-2.2.2.jar
+--- org -> springframework -> jdbc -> spring-jdbc -> 3.2.3.RELEASE
+--- spring-jdbc-3.2.3.RELEASE.pom
\--- spring-jdbc-3.2.3.RELEASE.jar
\--- samples
With this, our projects would be able to use a single file-based repository that contained everything required by the framework. Should they want other (or newer) stuff, and have the required access, they can easily replace this with mavenCentral() or even a private repository manager.
So, these are the questions:
- Is this possible to do with Gradle? * Are there any examples out there? * Or, at least, can anyone give me any pointers or hints to useful mechanisms inside gradle to make this happen?
Eirik