[GAP-138] Support new Ivy publishing mechanism Created: 18/Nov/12  Updated: 04/Apr/13  Resolved: 04/Apr/13

Status: Resolved
Project: Gradle Artifactory Plug-in
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.0

Type: Task Priority: Normal
Reporter: Yossi Shaul Assignee: Fred Simon
Resolution: Fixed Votes: 3
Labels: None


 Description   

Read here: http://www.gradle.org/docs/release-candidate/release-notes#new-ivy-publishing-mechanism



 Comments   
Comment by Thomas Glaeser [ 28/Nov/12 ]

The link changed ... http://www.gradle.org/docs/current/release-notes#new-ivy-publishing-mechanism

Comment by Thomas Glaeser [ 19/Dec/12 ]

Hi Frederic - When do you think version 2.0.18 becomes available? Thanks.../Thomas

Comment by Fred Simon [ 23/Feb/13 ]

Hi,

After adding this functionality, I found that adding (like described here http://www.gradle.org/docs/current/userguide/publishing_ivy.html ) the following line to artifactoryPublish task should make it work:

artifactoryPublish.ivyDescriptor = generateIvyModuleDescriptor.destination
// Or if tehre are multiple publication names
artifactoryPublish.ivyDescriptor = generate«NAME OF PUBLICATION»IvyModuleDescriptor.destination

Anyway, I just pushed a version (compiled and deployed as snapshot http://wiki.jfrog.org/confluence/display/RTF/Gradle+Artifactory+Plugin+using+the+snapshot+version), that works only with Gradle 1.4 and above, and read and depends automatically on the generateIvyModuleDescriptor if it is unique.
The download link (for build 232) of the uber jar of the Gradle Artifactory plugin (if you wish to manually deploy to gradle libs) is: http://repo.jfrog.org/artifactory/gradle-plugins-snapshots/org/jfrog/buildinfo/build-info-extractor-gradle/2.0.x-SNAPSHOT/build-info-extractor-gradle-2.0.x-20130223.011148-232-uber.jar

Please tell us if it answers your needs?

Comment by Detelin Yordanov [ 25/Feb/13 ]

Hi,
I did some testing but noticed that the artifactoryPublish task does not trigger building of all archives to be published. With the previous approach, the artifactoryPublish task depended on the Upload task and so triggered building of all artifacts. How would we trigger the build of the publication artifacts now so that they get picked up by the artifactoryPublish tasks?
Also, if the artifacts are not available, I'm getting "Skipping non-existent file ..." - could we have a switch to fail the build if some file is not found instead of producing a warning - for example a failOnMissingFile property or similar?

Regards,
Detelin

Comment by Detelin Yordanov [ 26/Feb/13 ]

It probably makes sense to request from Gradle that it exposes the list of configurations being published for an IvyPublication and then configure the Artifactory publish plugin with these configurations per default (if ivy publishing is enabled). Also, the artifactoryPublish task could be configured to depend on the corresponding build dependencies so that the artifacts part of those configurations are build automatically.
At the moment Gradle hardcodes the list of configurations being published to all public configurations - I tried configuring the same for the Artifactory publish using:

buildInfo = (BuildInfoTask) project.getTasks().getByName(BuildInfoTask.BUILD_INFO_TASK_NAME)
buildInfo.publishConfigs(project.getConfigurations().matching(new Spec<Configuration>() {
    public boolean isSatisfiedBy(Configuration configuration) {
        return configuration.isVisible();
    }
})

but this does NOT work, since the BuildInfoTask would read all configurations right away and the set might not contain all of them before the project is evaluated (configuring the same after the project is evaluated does not work as well - because the BuildInfoTask.projectsEvaluated() might be called before that and it will see the set of configs as empty).

One more think in this direction (let me know if this deserves a separate jira issue) is the configuration resolution - currently the Artifactory publish does not consider any module dependencies if the corresponding configuration is not resolved. But there are cases when a module declares certain dependencies but does not resolve them as part of the build - would not be appropriate to have a switch to force a resolve of the dependencies of the configurations being published?

Thanks,
Detelin

Comment by Thomas Glaeser [ 26/Feb/13 ]

Hi Simon - You are probably aware of the changes introduced with soon-to-released Gradle version 1.5 and might also want to verify if this works against the latest nightly build ... http://www.gradle.org/docs/nightly/release-notes#changes-to-incubating-ivy-publishing-support

Thanks,
Thomas

Comment by Fred Simon [ 12/Mar/13 ]

Should work as expected now

Comment by Fred Simon [ 17/Mar/13 ]

About the 'failOnMissingFile' flag, it is actually irrelevant with the latest snapshot.
Now the plugin force a dependency on all artifacts declared in the configurations that needs publishing.
So, the state of "missing artifacts" is not possible anymore (the build will fail before).
We are starting QA on our side on this version, please keep us updated if you find any issue.

Comment by Fred Simon [ 30/Mar/13 ]

Good testing done... Ready to use.
Example at: https://github.com/JFrogDev/build-info/tree/master/build-info-extractor-gradle/src/examples/publishTestProject
Version is 2.1.x-SNAPSHOT (not 2.0.x anymore), and to activate the new publish mechanism the plugin ID changed to 'artifactory-publish'.
So, the build.gradle should have something like:

buildscript {
    repositories {
        maven { url 'http://repo.jfrog.org/artifactory/gradle-plugins-snapshots' }
    }
    dependencies {
        classpath(group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '2.1.x-SNAPSHOT')
    }
    configurations.classpath {
        resolutionStrategy {
            failOnVersionConflict()
            cacheDynamicVersionsFor 0, 'seconds'
            cacheChangingModulesFor 0, 'seconds'
        }
    }
}

apply plugin: 'java'
apply plugin: 'ivy-publish'
apply plugin: 'maven-publish'
apply plugin: 'artifactory-publish'
Comment by Thomas Glaeser [ 04/Apr/13 ]

Hi Simon - We verified the new 2.1.x-SNAPSHOT and it is working for us. We would need however the released version. Please release ASAP. Thanks.../Thomas

Generated at Sat Aug 24 22:28:00 UTC 2019 using JIRA 7.6.3#76005-sha1:8a4e38d34af948780dbf52044e7aafb13a7cae58.