Zip dependencies not included in pom dependencies


(Anders Brolien) #1

We are using ZIP artifacts to package third party dependencies. The zip artifact may contain a large number of jar files.

dependencies are declared like:

compile zipTree(configurations.detachedConfiguration(dependencies.create(‘gson:gson:2.2.2’)).singleFile).matching {include ‘**/*.jar’}

This compile time dependency is not included in the resulting POM. Is there any way of configuring thins so that dependencies declared like this are seen when retrieving the jar and pom file from a maven repository?


(Tye Howard) #2

Is there a reason you are not just using :

dependencies {
       compile 'com.google.code.gson:gson:2.2.2'
}

?


(Anders Brolien) #3

For the simple example of gson there is no reason. However our corporate policy does not allow us to directly connect to maven central or any repo like that. We have to host all artefacts our self. Also many of our dependencies are not packaged in a maven like way, we get them as zip releases, where one zip bundle contains many jar files.

One advantage with gradle is that one module declare compile dependencies to a jar in a zip file originating from a repository. However if this dependency is not propagated, via the pom file, to the users of this module then this advantage becomes more of a problem. May question is if it is possible to configure things so that such dependencies are propagated via the pom or if I have to bit the bullet and install each jar file in the zip bundle as a separate artefact.


#4

How would you expect this to look in the POM file? How would it be consumed?


(Anders Brolien) #5

I am no expert in maven and pom syntax. Would adding an extra field to the declaration be possible? This would be something not understandable by other users of that pom file but my other modules would be able to make sense of this.

Example:

<project>
 <groupId>x.y.z</groupId>
 <artifactId>Module2</artifactId>
 <packaging>jar</packaging>
 <version>1.0</version>
<dependencies>
  <dependendy>
      <groupId>x.y.z</groupId>
       <artifactId>Module1</artifactId>
        <version>1.0</version>
        <type>zip</type>
        <zip>**/*.jar</zip>
  </dependency>
<dependencies>
</project>

Would nexus allow me to store an artefact declared like this?

It’s true that the consumption side could be tricky. Is there a way to access the underlying pom file from a dependency? If there is I could parse this and add my own dependencies.

An alternative would be to build this into gradle, not sure what you think about that.


#6

As far as I know, the POM syntax is not flexible like this. You could possibly implement something using ivy meta-data format, but it’s not going to be trivial.

A much better solution would be to change your builds to use regular jar dependencies, and use a repository manager like Artifactory or Nexus to serve up your artifacts. These servers can both handle proxying Maven Central so that your Gradle builds will not need to access the internet.

An alternative would be to build this into gradle, not sure what you think about that.

We’re currently doing a lot of work on publishing and dependency resolution, but I don’t think that handling zips-containing-jars is on the cards at this time.


(Anders Brolien) #7

Thanks for your answer! I basically want to know what is possible and what is not. I will use as suggested, sound like there is more work involved in implementing this then changing to jar dependencies.