Hi Luke, We have C++ components that currently build through Visual Studio by developers and are invoked using a CI system through Ant and an in house dependency management system. The VS solutions look for dependencies in a set folder for resolving and publishing using a dumb share. To leverage an actual dependency management system, a repository manager and Gradle's cool features, we are migrating our Ant scripts to Gradle and publishing to Artifactory. In fact, we came up with a simple Gradle C++/publishing plugin to fit our current needs. Cool stuff.
The artifacts generated by these components include headers, library files, docs, etc.. Previously, these artifacts were uploaded to Artifactory as a single zip file. When dependencies are fetched, they are copied from the Gradle cache (i.e. GRADLE_USER_HOME\componentA-1.0.zip) and unzipped into the folder where they are expected for the build. The zip file retained the folder structure and timestamps of all the files and worked very well. However, if we zip up all the artifacts, some of them are in excess of 2GB combined. It is possible zip up smaller portions and assign them configurations, but it is not desirable to unzip such large chunks and copy them places. So using the internal Gradle DefaultPublishArtifact class, we can loop through all our artifacts and add them to a configuration individually. To retain the folder structure in order to prevent overwriting, the type attribute of the DefaultPublishArtifact class is used to hold the relative folder path. Since the type attribute is not being used elsewhere for us and Gradle does not support Ivy's extra attribute feature (not that I know of anyways) this was an OK solution. So we publish using the following artifact pattern: ...[module]/[revision]/*[type]*/[artifact].[ext]. ...Component/1.0/*folder/structure*/Header.h Works perfectly! When copying our headers, and other library files from the Gradle cache, I don't want the -[revision] added to the artifact pattern of the Gradle cache. That's the first problem. Also, since we have the same components on different branches, it is a requirement for now to have different sets of folders to hold our dependencies per branch. To avoid copying of files, and the need to easily integrate with the current system it is required for the creation of multiple gradle caches. I'm wondering if you had any suggestions for this. Thanks in advance. Vinod -- View this message in context: http://gradle.1045684.n5.nabble.com/changing-the-gradle-cache-artifact-pattern-tp4580976p4581187.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
