Just beware that you're inheriting portability problems as one developers maven local is going to be different from another's.
At the very least, make sure that the CI build is not using mavenLocal(), then you can catch problems there at least. On 14/03/2012, at 7:18 PM, James Carr wrote: > Thanks, the maven plugin + mavenLocal() were good enough for what I wanted. > > > On Tue, Mar 13, 2012 at 5:43 PM, Mike Mills <[email protected]> wrote: >> You can use a flat dir resolver to store inter project dependencies >> without using maven snapshots. >> >> I had the same problem and was answered, it was however for gradle >> 1.0-milestone 3 but I suspect it would still work. >> >> The thread is here with sample code: >> http://gradle.1045684.n5.nabble.com/intra-project-build-dependencies-td4493055.html >> >> -Mike >> >> >> On Wed, Mar 14, 2012 at 8:01 AM, James Carr <[email protected]> wrote: >>> Hi All, >>> >>> A question that has come to me from many developers as we began >>> pushing gradle across the company is how to deploy locally. My >>> original plan for this was to just have devs deploy SNAPSHOT releases >>> to our artifactory servers to share with other teams but apparently >>> there has been a lot of cases where devs want to update a jar their >>> project depends on (but is unrelated) and want to test the changes out >>> locally before committing and pushing snapshots or releases out. >>> >>> The only thing that comes to my mind would be to use the maven plugin >>> to install the jar and set the M2 repo up to be the same location as >>> the cache for GRADLE_USER_HOME but would this be obscene? >>> >>> Thanks, >>> James >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
