Is it possible to avoid uploading SNAPSHOT artifacts which are identical to the existing artifact? Or with non snapshot artifacts can I avoid uploading an artifact that is identical to the most recent version of that artifact (i.e. only the version number has changed).
I don’t want to pollute my repository with large numbers of bogus changes. Usually I derive the version number from git, but the most recent change may affect only one of many projects contained with a git repository.
It’s not a built-in feature, but you could certainly implement your own logic to somehow check if the artifact already exists in the repo. This could be done as part of a custom upload task, or perhaps in ‘uploadArchives.outputs.upToDateWhen { … }’ or ‘uploadArchives.doFirst { … }’.
I was sort of hoping that someone might have already done it. For Maven there is this plug in: https://github.com/dscho/maven-lazydeploy-plugin
I do something rather painful in my existing ANT+Ivy builds.
The uploadArchives section seems to be missing from the documentation. It is mentioned in the user guide, but I can’t find it in the dsl reference or the Java/GroovyDocs. Where should I be looking?
‘uploadArchives’ is a task of type ‘Upload’. The ‘base’ plugin provides one ‘Upload’ task per configuration.
A pity that the published (online) JavaDocs don’t include the methods inherited from AbstractTask.
‘AbstractTask’ is an internal class, and it shouldn’t matter which methods it adds on top of implementing the ‘Task’ interface.
Right, but on the Upload javadoc there is no link to documentation of the getOutputs method. All you know is that it is defined in AbstractTask. This makes the documentation rather harder to navigate.
I see. I think the best you can currently do is to navigate to ‘Task’ under “Implemented Interfaces”.
uploadArchives.outputs.upToDateWhen { … } doesn’t work because after a ‘clean’ the result is ignored and uploading proceeds regardless of the result of this predicate (in gradle 2.0).
uploadArchives.doFirst { … }. and throwing a StopExecutionException does successfully prevent publication.