Ivy.xml contains artifact entries of not uploaded artifacts

Old Forum Archive
1

With the following code the archives “myProject-B.jar” and “myProject.jar” will be transferred to an artifactory repository (after executing upload task).

apply plugin: 'java'
  group = 'testcase_ivy_xml_bug'
  uploadArchives {
 uploadDescriptor = true
 repositories {
  ivy {
   name = 'libsSnapshotLocal'
   artifactPattern 'http://artifactory:8081/artifactory/libs-snapshot-local/[organisation]/[module]/[revision]/[module]-[revision](-[classifier]).[ext]'
   host = 'http://artifactory:8081/artifactory'
   port = 8081
   credentials {
    username 'abc'
    password 'hgsdhhsdgh'
   }
  }
 }
}
  task jarA(type:Jar) {
 classifier = 'A'
 from(gradle.gradleHomeDir) {
  include '*.txt'
 }
}
  task jarB(type:Jar) {
 classifier = 'B'
 from(gradle.gradleHomeDir) {
  include '*.html'
 }
}
  artifacts {
 archives jarA,jarB
}
    jarA.enabled = false

The problem is, that the resulting ivx.xml contains an artifact entry for “myProject-A.jar”, although the file has not been created and uploaded (jarA.enabled = false). This conflict causes problems during dependency resolving.

<publications>
        <artifact name="myProject" type="jar" ext="jar" conf="archives,runtime"/>
        <artifact name="myProject" type="jar" ext="jar" conf="archives" m:classifier="A"/>
        <artifact name="myProject" type="jar" ext="jar" conf="archives" m:classifier="B"/>
</publications>

An additional unexpected behavior is, that if “myProject-A.jar” already exists in the gradle lib dir (relic of older build), the same script will upload “myProject-A.jar” (ignoring jarA.enabled = false).

I used Gradle 1.0-rc-2.

Regards

Frank

2

“gradle lib dir” is confusing. I meant “build/libs”.

3

If ‘jarA’ is not to be uploaded, you will need to make sure that it is not added to the ‘archives’ configuration. Disabling the ‘Jar’ task is the wrong approach here.

4

Hello Peter,

thanks for your answer.

What is the right approach to “disable” the fat jar? The fat jar is already in the configurations “archives” and “runtime”. I have to substitute “jar.enabled = false” with the following code to get the right ivy.xml:

configurations.archives.artifacts.remove(configurations.archives.artifacts.findAll{it.classifier == ''}.toArray()[0])
configurations.runtime.artifacts.remove(configurations.runtime.artifacts.findAll{it.classifier == ''}.toArray()[0])

That should not be the right approach. Furthermore jar tasks skipped with onlyIf cause a wrong ivy.xml too. Is the use of onlyIf also the wrong approach?

Regards Frank

5

Disabling the Jar task doesn’t change the fact that you are telling Gradle to upload the artifact. That’s why your ‘enabled’ and ‘onlyIf’ attempts don’t work.

If you don’t want to upload jarA, then don’t say ‘artifacts { archives jarA }’. If you only sometimes need to upload it, put the code in an if-statement. Or, better, create a separate configuration (say ‘fat’) for jarA so that it will only get uploaded when doing ‘gradle uploadFat’. The Gradle user guide has more information on artifact publication.

6

Hello Peter,

thanks for your second answer and please excuse my delayed response.

In the appended code only configurations are used to control which artifacts are uploaded.

But calling uploadConfA results in the following artifact publications section in ivy.xml:

<publications>
        <artifact name="myProject" type="jar" ext="jar" conf="archives,runtime"/>
        <artifact name="myProject" type="jar" ext="jar" conf="confA" m:classifier="A"/>
        <artifact name="myProject" type="jar" ext="jar" conf="confB" m:classifier="B"/>
    </publications>

I would expect, that only the second entry is listed, because the fat jar and B jar are not uploaded.

Regards

Frank

example code:

apply plugin: 'java'
  group = 'testcase_ivy_xml_bug'
  repositories {
 ivy {
  name = 'libsSnapshotLocal'
  artifactPattern 'http://artifactory:8081/artifactory/libs-snapshot-local/[organisation]/[module]/[revision]/[module]-[revision](-[classifier]).[ext]'
  credentials {
   username 'xxxx'
   password 'yyyy'
  }
 }
}
  configurations {
 confA
 confB
}
  uploadConfA {
 repositories {
  add project.repositories.libsSnapshotLocal
 }
 uploadDescriptor = true
}
  uploadConfB {
 repositories {
  add project.repositories.libsSnapshotLocal
 }
 uploadDescriptor = true
}
  task jarA(type:Jar) {
 classifier = 'A'
 from(gradle.gradleHomeDir) {
  include '*.txt'
 }
}
  task jarB(type:Jar) {
 classifier = 'B'
 from(gradle.gradleHomeDir) {
  include '*.html'
 }
}
  artifacts {
 confA jarA
 confB jarB
}
7

At the moment, the generated ivy.xml always contains all artifacts regardless if you execute an upload for a single configuration. The ivy.xml is a descriptor for an entire module so it needs to list all artifacts/configurations for given module.

Hope that helps!

8

Hello Szczepan,

thanks for your information. At the moment we patch the ivy.xml to avoid conflicts during dependency resolving. Maybe we should reconsider our approach. But nevertheless it would be nice to have more control over the ivy.xml generation of the upload task.

Regards Frank

9

Another solution is to refer to a particular configuration of the module, not to the whole module.