Excluding a configuration from uploadArchives

Old Forum Archive
1

I have written a plugin that creates custom tasks for both XJC and WS Import to generate Java code from schema (XSD) and web service (WSDL) files.

In the plugin portion, I define a few configurations to make dependencies between projects easy to manage, but I ran into an issue when I had a web service that defined more than one schema (’*.xsd’) file. In particular, I create two configurations that are related:

  1. ‘schemaFiles’ configuration is created on the project without applying anything to it. 2. ‘schemaFilesZip’ configuration is created on the project and it is extended by ‘archives’.

The ‘schemaFilesZip’ configuration is meant for incoming dependencies and it is automatically formed as a single zip file containing everything in the ‘schemaFiles’ configuration. This works well when deploying to repositories like Nexus that rename artifacts, which is difficult to undo without a lot of extra information.

My problem is that I am defining my ‘schemaFiles’ configuration like so:

artifacts {
  schemaFiles new File(wsImport.wsdlsDir, "ws.v1.wsdl"),
              new File(wsImport.wsdlsDir, "schema1.v1.xsd"),
              new File(wsImport.wsdlsDir, "schema2.v1.xsd")
}

This works for compilation and dependencies quite well. However, when ‘uploadArchives’ is used, it automatically attempts to upload each file, which fails because it cannot submit two ‘*.xsd’ files with the same classifier.

My goal is to avoid uploading the ‘schemaFiles’ configuration at all, but I don’t know how to disable ‘uploadArchives’ for it or otherwise specify the inputs without it automatically happening (e.g., some block that works like ‘artifacts’ for defining configuration inputs that I am unaware of).

2

I’m not sure I fully understand how your build works based on this description, but one thing that jumps out at me is that “artifacts” are typically outputs of your build, but the files you are specifying seem like they’re actually inputs, right?

Should schemaFiles actually be a configuration? Or should it just be a FileCollection? Seems like it should be an extension to the project (of type FileCollection) that your plugin introduces and then sets as the input to the schemaFilesZip zip task (and possibly also the wsImport task).

3

I like that idea. You are correct about the schemas being inputs, although they are also used as outputs of this project for incoming dependencies of other subprojects, but I already support unzipping from the ZIP files for this purpose, so that should be an easy transition.

I am not in the office today, but I’ll probably have time to give that a shot on Monday or Tuesday. Thanks for the quick response.

4

I have not had a chance to look into this, but it is still on my radar.