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. 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
