On 04/09/2012, at 2:29 AM, Adam Murdoch wrote: > Hi, > > One question we need to answer soon is how variants should be mapped to Ivy > and Maven repositories. Have a look at the dependency model spec for a > definition of variant: > https://github.com/gradle/gradle/blob/master/design-docs/dependency-model.md#variant > > We want to define some conventions (or a standard in the cases where there's > no obvious convention), and build some plugins that can do useful stuff based > on these. As always, the infrastructure needs to be flexible to some degree, > so you can choose to use some other convention (but the further you go from > our convention, the more work you have to do). > > Some concrete examples we're interested in: > * I want to publish Groovy 1.8 and Groovy 2.0 variants of my Groovy library. > * I want to publish x86 and amd64 variants of my native library. > * I want to publish minified and non-minified variants of my Javascript > library. > > There's another dimension that we're not interested in here (it's a separate > discussion), and that is packaging: > * I want to publish my Groovy library as both a jar and as a distribution. > * I want to publish both a jar and a war from my Java project. > > There are a few basic options for mapping component variants to a repository: > > 1. Publish every variant as a single module. So, for my native library, > Gradle would publish module 'my-org:my-lib' that contains both the x86 and > amd64 binaries, the header archive, maybe source and API documentation > archives, plus meta-data for both variants. > > For a maven repository, this might look like: > > my-org/my-lib/1.2 > pom.xml > my-lib-1.2-x86.so > my-lib-1.2-amd64.so > my-lib-1.2-cpp-headers.zip > my-lib-1.2-source.zip > my-lib-1.2-doxygen.zip > > For an ivy repository, it would look more or less the same. The artefacts > might have different names - e.g. my-lib-x86-1.2.so instead of > my-lib-1.2-x86.so. > > 2. Publish every variant as a separate module. So, for my native library, > Gradle would publish module 'my-org:my-lib-x86' that contains the x86 > binaries, and 'my-org:my-lib-amd64' for the amd64 binaries. Variant > independent archives would go in both places. > > For a maven repository, this might look like: > > my-org/my-lib-x86/1.2 > pom.xml > my-lib-1.2.so > my-lib-1.2-cpp-headers.zip > my-lib-1.2-source.zip > my-lib-1.2-doxygen.zip > > 3. Publish each variant as a separate module, plus publish a > variant-independent module. For my native library, Gradle would publish > 'my-org:my-lib-x86' for the x86 binaries and meta-data, 'my-org:my-lib-amd64' > for the amd64 binaries and meta-data, and 'my-org:my-lib' for the headers, > source, documentation and meta-data about the available variants. > > For a maven repository, this might look like: > > my-org/my-lib-x86/1.2 > pom.xml > my-lib-1.2.so > > my-org/my-lib/1.2 > pom.xml > my-lib-1.2-cpp-headers.zip > my-lib-1.2-source.zip > my-lib-1.2-doxygen.zip > > Option 1. has some downsides > * Often, the meta-data for each variant is different. For example, my Groovy > 1.8 variant depends on groovy:1.8, and my Groovy 2.0 variant depends on > groovy:2.0. Or, in native space, my windows variants need library a, and my > linux variants need completely different library b. For this option, there's > a single descriptor that we have to jam everything into. > * The variants are not directly addressable from some other build tool. > * Often, the variants are not all built and published in one build. For > example, my Windows variants are built on a different machine to my Linux > variants. This means that the module is effectively a changing module for > some period of time. > > Option 2 addresses these, but adds some new issues: > * There's no meta-data for the component as a whole. For example, which > variants are available? which variants are available that can be linked into > a 32 bit windows debug multi-threaded executable? > * Variant independent artefacts are published multiple times. For example, if > I have 16 different combinations of operating system, data model, debug and > compiler, I end up with 16 copies of my headers and source. > > Option 3 feels pretty good to me. It adds physical representations for each > of the 3 'things' here: the 2 variants and the component itself. > > We do have some other options for publishing to Ivy repositories. For > example, we might publish a single module and add [variant] as something you > can refer to in an artifact pattern, so you can do something like this: > > my-org/my-lib/1.2 > ivy.xml > my-lib-cpp-headers-1.2.zip > my-lib-source-1.2.zip > x86/ > my-lib-1.2.dll > my-lib-1.2.lib > my-lib-1.2.pdb > amd64/ > ... > > I'd rather use the same mapping for both Maven and Ivy, however.
Only thing I can add is that I agree that #3 is the way forward. Given what we have to work with, it makes the most sense. I think variants to have be able to have their own “extra” artifacts (e.g. source) though. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
