How can you edit the ivy descriptor when using the cpp-lib and artifactory plugins?

Old Forum
1

I have a simple cpp-lib project that deploys the resulting .zip and .so files to artifactory using:

artifactory {
 contextUrl = artifactoryContextUrl
 publish {
  repository {
   repoKey = repoKey
   username = user
   password = password
   publishIvy = true
   publishPom = false
  }
 }
}

I want to modify the generated ivy.xml to include aol type information, which examples show you can do using the ivypublish plugin and publishing closure:

publishing {
 publications {
  ivy(IvyPublication) {
   descriptor.withXml {
    asNode().attributes().put('xmlns:e', 'http://ant.apache.org/ivy/extra')
    asNode().info[0].attributes().put('e:aol', aol)
   }
  }
 }
}

That creates a new ivy.xml in addition to the one already created. For java and web projects adding:

from components.java

or the web equivalent solves it but it doesn’t currently support cpp, how do I get around this? And modify the already generated ivy descriptor as opposed to creating a new one?

2

You’ll need to configure the artifacts that you want to include in the publication, as described in the User Guide. Then you’ll need to be sure you’re using the artifactory-publish plugin, which understands the new publishing model.

3

Thanks for the quick answer. I’m happy using the new publishing model and how to use that with the artifactory-publish plugin but I’m still struggling to configure the artifacts to include. With the snippet below the ivy.xml is correct and deployed but the cpp-lib isn’t built at all or published, leading to the error: File ‘xxx\org.gradle.nativebinaries.internal.DefaultLibraryResolver@18526aa’ does not exists, and need to be published from publication ivyCpp

publishing {
 publications {
  ivyCpp(IvyPublication) {
      artifact(libraries.main.shared) {
    extension "zip"
    type "zip"
    classifier "headers"
   }
      artifact(libraries.main.static) {
    extension "so"
    type "so"
    classifier "so"
   }
       descriptor.withXml {
    asNode().attributes().put('xmlns:e', 'http://ant.apache.org/ivy/extra')
    asNode().info[0].attributes().put('e:aol', aol)
   }
  }
 }
}

I don’t see how else to configure the artifacts despite wading through the user guide and api; what am I missing?

4

Thanks for the quick answer. I’m happy using the new publishing model and how to use that with the artifactory-publish plugin but I’m still struggling to configure the artifacts to include. With the snippet below the ivy.xml is correct and deployed but the cpp-lib isn’t built at all or published, leading to the error: File ‘xxx\org.gradle.nativebinaries.internal.DefaultLibraryResolver@18526aa’ does not exists, and need to be published from publication ivyCpp

publishing {
 publications {
  ivyCpp(IvyPublication) {
      artifact(libraries.main.shared) {
    extension "zip"
    type "zip"
    classifier "headers"
   }
      artifact(libraries.main.static) {
    extension "so"
    type "so"
    classifier "so"
   }
       descriptor.withXml {
    asNode().attributes().put('xmlns:e', 'http://ant.apache.org/ivy/extra')
    asNode().info[0].attributes().put('e:aol', aol)
   }
  }
 }
}

I don’t see how else to configure the artifacts despite wading through the user guide and api; what am I missing?

5

There’s not yet any built-in support for publishing native binaries. You can’t simply add ‘libraries.main.static’ to a publication because it doesn’t uniquely define a binary variant, instead you’ll need to provide each binary output file you want to publish.

Unfortunately, the binaries aren’t configured early enough in the build to reference them, so you’ll need to do something like this:

publishing {

repositories {


ivy { url “${buildDir}/repo”}


}


publications {


ivy(IvyPublication) {


}


} } binaries.all { binary ->


publishing {


publications.ivy.artifact(binary.outputFile) {


extension “so”


builtBy binary


}


} }

6

Thanks, with a little tweak to change the extension and classifier based on the library name (ie shared or static) this works well. Still, it would be nice if something like: from components.cpp-lib was available :slight_smile:

7

Absolutely: we’ll be addressing publishing and resolving of cpp components in the future.