3
votes

I've been reading up on Gradle and its repository support features. The docs indicate it supports Ivy or Maven repos. The implications of this are not entirely clear to me.

In the case of a Maven repo, I think my understanding is more complete. When building, the local repository like Nexus or Artifactory will cache the required public dependencies form MavenCentral. For publishing, Gradle will generate a POM.xml for the project, and you can publish private artifacts back to the local repository. Is my understanding correct? I want to have control over the public dependencies being used, along with correcting mistakes in the public MavenCentral POMs.

For Ivy, I'm a little more confused. For one, what does a shared Ivy repo look like? Is it just a remote directory tree hosted over SSH, SFTP, HTTP, etc? Does this work in mixed Windows/Unix environment? How does Gradle move the public dependencies and built artifacts into the shared Ivy repo? Can Jenkins also perform this step, how? Are additional build steps necessary when the new public dependencies are defined and they need to be moved into the shared Ivy repo, or is this done seamlessly?

Finally, assuming the features of the two models are basically the same. What is the is solution to maintain along side a Jenkins build machine?

1

1 Answers

6
votes

Your understanding of Maven support in Gradle is correct. You have full control on the dependencies and where they come from (Gradle doesn't have any repositories hard-coded, so you might use Bintray instead of Maven Central, for example, less mistakes to correct).

Ivy's dependency management is alike. Ivy has it's own layout (supported in Artifactory, but not in Nexus see 'Repository Support') and there is small number of public Ivy repositories out there in the web (e.g. Ivy RoundUp). Since Ivy is good with Maven repositories, most Ivy users just use Maven Central and/or Bintray.

The main difference between Ivy and Maven is not in the repository format, but in the metadata format. Ivy uses ivy.xml (although the name is not a must) instead of pom.xml and the xml schema is different. Gradle supports both formats and can read transitive dependencies both from pom.xml and from ivy.xml and can generate metadata for your project and deploy it to the repositories in both formats.