Thanks Adam, The approach is actually to reproduce a current method (which uses ant/ivy to do similar things) but using gradle. I see the ant->gradle shift as a stepping stone to 'greener' pasture, mainly more modularization with our codebase.
In light of your comments I'll probably opt for setting up the assembly as a 'real' (flat file) repository. BTW, when using local file repository does it copy all the artifacts to the cache, if so is there any way to prevent that and just reference the artifacts in place? I would want to avoid the duplication of jars. Also where can I find information on the Gradle daemon, sounds like an interesting thing :) Thanks again for elaborating on this. gretar On Thu, Oct 28, 2010 at 8:53 AM, Adam Murdoch <[email protected]> wrote: > > On 28/10/2010, at 6:46 AM, Gretar Arnason wrote: > > Hi, does anyone know if it is possible to set the gradle-user-home in other > ways than through the -g option of gradle launcher? > > What I'm aiming for is to have an assembly project that is using gradle to > resolve all of my artifacts (with dependencies) into a seperate cache > (<project>/assemblyCache/) instead of <user home>/.gradle/cache. > > > There isn't any reliable way to change the cache other than with the -g > option. > > There's potentially a few problems with using the cache to do what you want > to achieve: > > * Lots of other stuff can end up in the cache. For example, we plan to bust > the Gradle distribution up into a bunch of downloadable chunks. These would > end up in the cache. > > * The cache format is not a public interface. We may change the format at > any time. > > * Once the Gradle daemon is in use, the daemon will 'own' the cache, in > that it may do downloads and garbage-collection in the background. You may > get consistency or (on windows) locking problems if you zip it up in your > build. > > An alternative to this might be if we had a way to publish (aka 'upload') > your artifacts and their (transitive) dependencies to a repository. You > would simply publish to a local repository in your build. > > We want to add this to Gradle for a few reasons. Firstly, we want to do > something similar to you. When we split up the Gradle distribution, we want > to have a distribution zip which includes the various pieces p > > re-downloaded in a repository included in the distribution zip. > > Another reason is that this will help us implement repeatable builds as > part of release management in Gradle. Part of the solution might be to > publish the artifacts and some or all of their dependencies (including > build-time dependencies) and meta-data to a repository on release. > > > Then I'm planning on using the resulting cache as a repository for an > assembler (a zip artifact) which uses configurations to package features > into delivery artifacts (zips,ear files etc...) > This assembler with the resolved cache is then shipped to the 'Services And > Delivery' department which uses it to control the packaging. > I'm also aiming to ship gradle wrapper in this assembler for convenience. > > I can achieve this by using the -g option (providing some shell scripts to > simplify execution) - however it would be much smoother if I could set this > in either the build.gradle script (this is probably a bootstrap issue > though) or a property file. > Just want to know if it is an option. > > regards > gretar > > > > -- > Adam Murdoch > Gradle Developer > http://www.gradle.org > CTO, Gradle Inc. - Gradle Training, Support, Consulting > http://www.gradle.biz > >
