Failing to publish all artifacts to Artifactory using the JFrog plugin

(Merlyn Albery-Speyer) #1

I have the Artifactory plugin configured for my multiproject build. It works just fine for publishing the artifacts for any individual subproject. When I run the artifactoryPublish task, only the last subproject is published to Artifactory all the rest output debug information like so (i.e. they do nothing):

10:39:25.840 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :common:mySubProject:artifactoryPublish 10:39:25.840 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Starting to execute task ‘:common:magellan-httpclient:artifactoryPublish’ 10:39:25.841 [DEBUG] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Determining if task ‘:common:magellan-httpclient:artifactoryPublish’ is up-to-date 10:39:25.841 [INFO] [org.gradle.api.internal.changedetection.ShortCircuitTaskArtifactStateRepository] Task ‘:common:magellan-httpclient:artifactoryPublish’ has not declared any outputs, assuming that it is out-of-date. 10:39:25.841 [DEBUG] [org.gradle.api.internal.changedetection.DefaultFileCacheListener] Can cache files for configuration ‘:common:mySubProject:archives’ 10:39:25.841 [DEBUG] [org.gradle.api.internal.changedetection.DefaultFileCacheListener] Can cache files for file ‘/Users/merlyna/workspace/project/common/mySubProject/gradle-build/poms/pom-default.xml’ 10:39:25.841 [DEBUG] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] task ‘:common:mySubProject:artifactoryPublish’ is not up-to-date 10:39:25.841 [DEBUG] [org.gradle.api.internal.changedetection.DefaultFileCacheListener] Invalidate all cached files 10:39:25.841 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ‘:common:mySubProject:artifactoryPublish’. 10:39:25.842 [DEBUG] [org.jfrog.gradle.plugin.artifactory.extractor.BuildInfoTask] Task ‘:common:mySubProject:artifactoryPublish’ activated 10:39:25.842 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ‘:common:mySubProject:artifactoryPublish’

Is anyone using the Artifactory plugin for a multiproject build?

(Merlyn Albery-Speyer) #2

This is the work-around I’m trying:

artifactoryPublish.doFirst {
  lastInGraph = true

This is based on BuildInfoTask#collectProjectBuildInfo:

    public void collectProjectBuildInfo() throws IOException {
        log.debug("Task '{}' activated", getPath());
        // Only the last buildInfo execution activate the deployment
        if (lastInGraph) {
            log.debug("Starting build info extraction for project '{}' using last task in graph '{}'",
                    new Object[]{getProject().getPath(), getPath()});

I think the intention was to ensure that all subproject builds completed before performing any uploads. If you have a different solution, please let me know.

BTW I’m using gradle 1.0-m7, and build-info-extractor-gradle version 2.0.7.

(Peter Niederwieser) #3

I think the intention is to have all artifacts published in one go by one task (whichever comes last). Are you saying that this doesn’t work? I don’t think the debug output by itself indicates a problem.

(Merlyn Albery-Speyer) #4

Right. With my work-around it publishes each artifact in turn. Without the work-around none of the subproject publish artifacts except for the last subproject. It’s artifactoryPublish task publishes artifacts for that subproject only.

(Peter Niederwieser) #5

The JFrog folks may be better able to help here.

(Matias Bjarland) #6

Merlyn, try giving jfrog a call. They have provided brilliant technical support to me via phone and mail over the last number of months regarding issues with the gradle artifactory plugin. Number is on their site.

(noam) #7

Have you made sure to apply the Artifactory plugin to all sub-projects? Can be applied with:

allprojects {
    apply plugin: 'artifactory'

For another good example, you may want to check out our build-info project on github. it’s got multiple modules, is built by Gradle and is published using the plugin (himself).

(Frederic Simon) #8

From the output it looks like no configurations with artifacts are associated with the artifactoryPublish task. You could try:

artifactoryPublish {
    publishConfigs('topublish', 'archives', configurations.other)

Be aware that configuration inheritance is not used since you can specify a list of configurations and so control the artifacts actually deployed. Also, there are 2 flags ‘“publishIvy”’ and ‘“publishPom”’ that will force the publication of pom or ivy files (if they can be found from other tasks in your project). And finally one flag ‘“publishArtifacts”’ may disable all artifacts publishing, so make sure it is set.

Hope it helps, Fred.

(Frederic Simon) #9

Looking deeper into this there is a known issue that I’m targeting rigth now:

I will need to remove the lastInGraph flag to replace with a dynamic eval. Hope it won’t break too many users :slight_smile:

(Frederic Simon) #10

Fixed with latest 2.0.10 release


(Merlyn Albery-Speyer) #11

Thanks Fred,

I’m using milestone 7, and so every Gradle build now outputs these warnings:

The MavenPluginConvention.getPomDirName() method is deprecated and will be removed in the next version of Gradle. You should use the getMavenPomDir() method instead.
The MavenPluginConvention.getPomDir() method is deprecated and will be removed in the next version of Gradle. You should use the getMavenPomDir() method instead.

I don’t see the plugin on github, otherwise I’d offer a pull request that fixes this.

Cheers, Merlyn

(Matias Bjarland) #12

A couple of months back I had a very lengthy email conversation with the jfrog guys about this issue. It started with them saying it was not caused by their plugin, but in the end it turns out it was…albeit in a somewhat roundabout way.

Resulting jira:


Quoting part of my email conversation with jfrog (I set a break point in the deprecated methods):

… > So it turns out that your plugin class GradleArtifactoryClientConfigUpdater, in the

method fillProperties, on line 121 of the java file, calls project.getProperties().

This in turn iterates through all available properties, including the ones injected

via plugin conventions, thus also including the deprecated ones on the

MavenPluginConvention, thus causing the warnings produced on every single

gradle build.

AFAIK jfrog does not host their plugin at github, but they have been very responsive so if you have a good idea of how to fix this I’m sure they would be very quick to put it in place.