On 06/12/2012, at 9:16 AM, Hans Dockter wrote: > > On Dec 5, 2012, at 7:38 PM, Steve Ebersole <[email protected]> wrote: > >> Out of curiosity, why would a build want to not "install" as a prerequisite >> to "deploy"? That actually seems very natural to me. > > We had clients that didn't want to do this because it let their local cache > grew to much. Or you may just want to do it for debugging purposes to see how > an artifact is retained from a remote resource. Or you wan to upload an > experimental artifact based on non-committed code to some experimental > repository but don't want to pollute your cache. I think it is good to be > able to decouple this as needed even if it represents the normal use case for > many people. > > It is interesting to think about whether Gradle should have a notion of local > in the pure Gradle/Ivy world. We have a different situation than in Maven > land, as the artifacts for dependencies between a multi-module are not > resolved via the cache (which I think is good). So why does Gradle want to > publish to something to local than? There is another use case of found in > Maven land. When you have independent builds on your local machine, you use > the local cache as the integration point. That way you can try the > interaction between your two local latest. You pay a price though in that you > are possibly polluting your cache with locally produced artifacts from > non-committed code. In pure Gradle land, there is no out-of-the-box way you > can locally connect independent builds. You would need to manually add local > repositories for that purpose. An organization could easily set this up via > their enterprise plugins and inject this into every project. Should Gradle > provide something like this out of the box? It would be easy to do, but I'm > not sure. I think what might be a better solution is to make it very easy to > connect the two independent builds easily locally that they form one logical > local build.
+1 to all this. > > Hans > >> >> On Wed 05 Dec 2012 11:24:10 AM CST, Luke Daley wrote: >>> >>> >>> >>> >>> On 05/12/2012, at 11:24 AM, Daz DeBoer <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> G'day >>>> I'm adding 'mvn install' type support to the new 'maven-publish' >>>> plugin. Just wanted to confirm some behaviour: >>>> >>>> * Should we _always_ try to install to maven local repo when >>>> publishing to a remote maven repository. >>> We are already doing this, and have no choice. You can't make the >>> maven ant tasks not do this. We have a JIRA for this with some comments. >>> >>>> * So 'publish' with the 'maven-publish' plugin will combine the >>>> current 'deploy' and 'install' of the 'maven' plugin. I think >>>> this makes sense, as it matches the behaviour of 'mvn deploy'. An >>>> alternative would be a separate lifecycle task for 'maven-install'. >>>> >>>> * What should happen if the 'maven-publish' plugin is used without >>>> a local maven installation? I assume that we should just skip the >>>> 'install' step in this case. >>> Because it's out of our control, not sure what we can do. >>> >>>> * What should happen if there is a problem parsing the local maven >>>> settings.xml? I suggest we emit a warning and continue. >>>> >> >> --------------------------------------------------------------------- >> 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 > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
