Yeah, we created a rule on our CI box to fail if the project's gradle file references mavenLocal()
On Wed, Mar 14, 2012 at 2:35 PM, Luke Daley <[email protected]> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
