Should disabling a task automatically remove any artifact it might publish?

(detelinyordanov) #1

Is there a way to disable a task thereby also removing any artifact it might publish? For example, if anyone applies the ‘java’ plugin but does not want sources being published, he/she should disable the ‘jarSource’ task, but also search for its published artifact and remove it as well. In a more general case, I guess this might be handled with the following piece of code:

tasks.withType(Jar) { if (...) it.enabled = false }
      afterEvaluate {
    configurations.all {
        artifacts.removeAll artifacts.findAll { it instanceof ArchivePublishArtifact && !it.archiveTask.enabled }

Are there better ways to accomplish this? If not, are there any chances for Gradle providing similar fuctionality, so that users would just need to disable/remove a task and its artifacts would be removed automatically?



(Luke Daley) #2

It doesn’t, and doesn’t even attempt to. This issue is related.

I’ve turned this into a problem and raised it as something to be solved.

(t.enderling) #3

I’ve attached a patch to GRADLE-1982. (I tried to avoid creating a github account, so no pull requests unless you insist.)

It allows to specify an “onlyIf” closure/spec on an IvyArtifact, just like the “onlyIf” on Task. The closure/spec will be evaluated just before the module descriptor is generated and the files to publish are determined. If the closure/spec return false, the artifact is omitted from both the descriptor and the upload. (Yes this would not solve the issue for the old publish plugin, but if I understand correctly, this will be replaced by ivy-publish/maven-publish anyway.) I suspect this to fit well into Gradle’s design, what do you think?

Please consider adding this patch to your next release, as our usage of Gradle depends on it.

This of course only solves GRADLE-1982 only halfways (and only for using the ivy-publish plugin), but it provides the part, that is very hard (or impossible) to create using custom build logic/configuration. Also it is generic enough to allow for other, more custom use cases.

Best Regards, Tim

(Luke Daley) #4

Hi Tim,

Why do you need to defer the decision until build time. What is the decision to publish or not based on?

(t.enderling) #5

Hi Luke,

we have a large number of similar projects and a few conventions that we want to take over from our old Ant-based build system:

We create different jars based on Java package names. If there is no such package/class with this package in the project, the jar should be automatically omitted. (We publish multiple jars per Ivy-module, so we don’t want to create empty jars either, since the Ivy meta-data is sufficient to tell whether we have such code or not.)

This alone would be simple to handle in the configuration phase (simply look-up if a certain source folder is available). What adds complexity is that we often generate code during build using JAXB. Predicting what classes/packages result from JAXB step is harder (package names can be specified in xjb, i.e. Java-XML-based, binding files) and doing this would tie our Gradle plugin too close to JAXB (which we run using the Ant tasks).

Configuring this manually for every project would be tedious and error prone, and the build process already has all information available. By generically adding all artifacts and steps to our common plugin (they are still just a few), we save this manual effort.

Best regards Tim

(t.enderling) #6

Hi Luke,

I’ve just noticed that Gradle 1.7-rc-2 is out. Congratulations!

I don’t want to be nagging, so this is really just a question for us to plan : 1. How large are the chances to get this patch (or something similar) into Gradle at all? (I fully understand if you want to guard against unnecessary features/wrong approaches.) 2. How large are the chances for this to be in 1.7 release?

Also I know that some of my proposed changes are problematic (and the included test does not cover these issues). If you could finger point me to what you think is most disturbing, I could go and fix it.

Thank you,


(Luke Daley) #7

Hi Tim,

For #1, it’s as yet unknown. I’ve raised this on the developer list to get some clarification.

There’s no chance of #2 unfortunately. 1.7 is now code complete and will be released next week.

(t.enderling) #8

Thank you! Is the developer list open or Gradleware internal?

(Luke Daley) #9

It’s open.

Details here:

(t.enderling) #10

Now that there is ModelRule in Gradle 2.0, could you point me to how to create artifacts in an IvyPublication only if the zip task creating it actually created a file? (I.e. if the zip-task had no input the artifact should simply be omitted.)

Thank you!