On 01/09/2012, at 5:47 AM, Sébastien Cogneau wrote: > Hi, > > > I have worked on > http://forums.gradle.org/gradle/topics/build_a_distribution_for_a_java_or_jvm_based_library > > The last extra point is quite tricky and may need some extra changes on the > way to generate pom.xml and ivy.xml. > > What kind of change should be made to achieve the publication of the > distribution in a maven or ivy repositories ?
It might be worth looking at where we want to end up, and then work back from there. We want to handle 3 main use cases here: 1. I want to publish the library distribution(s) instead of the jar + source + javadoc. 2. I want to publish the library distributions plus the jar + source + javadoc. 3. I want to publish the library distributions, but I want to use the jar locally in the same multi-project build. Or, more abstractly: We have 2 ways of packaging the library: * As a distribution that includes everything. * As separate artefacts, such as the jar, source zip and javadoc zip. We would want to add additional packagings later (as an OSGi bundle, or a fat jar, or an Android library, or even a native dll would be some examples). And I have 2 ways of consuming, or using, the library: * In the same build using a project dependency. * From a different build using an external dependency. For each of the above usage types, the producing project must be able to make one or more packagings available. And for each usage, the consuming project must be able to request a particular packaging (usually implicitly based on what it's trying to do). There are a few things to figure out here: 1. How do we map each of the above use cases to a pom.xml or ivy.xml? 2. What does the DSL look like for the producer to specify the packagings that it wants to make available? 3. What does the DSL look like for the consumer to specify the packaging that it wants to use? I'm certainly not suggesting you need to implement any of this. But if we have a plan here, we can come up with a couple of small steps we can take now to solve the problem (i.e. how do I publish my library as a distribution?). As far as mapping goes, we need to do something like this: To map to Maven: 1. When publishing the distributions only: * Generate a pom.xml with type 'java-library-dist' * The generated pom.xml includes no dependencies. * Publish the distributions as $artifactId-$version.zip and $artifactid-$version.tgz 2. When publishing the distributions + jar: * Generate a pom.xml with type 'jar' * The generated pom.xml includes compile and runtime scoped dependencies. * Publish the jar as $artifactId-$version.jar * Publish the distributions as above. To map to Ivy: 1. When publishing the distribution only: * Ivy.xml defines configuration 'dists' with no dependencies. * Publish the zip distribution with name $moduleName, type 'java-library-dist', extension 'zip', config 'dists' * Publish the tgz distribution with name $moduleName, type 'java-library-dist', extension 'tgz', config 'dists' 2. When publishing the distributions + jar: * Ivy.xml defines configuration 'dists' with no dependencies. * Ivy.xml defines configuration 'runtime' with the runtime dependencies. * Ivy.xml defines configuration 'api' with the API dependencies. * Publish the jar with name $moduleName, type 'jar', extension 'jar, configs 'runtime' and 'api'. * Publish the zip distribution with name $moduleName, type 'java-library-dist', extension 'zip', config 'dists' * Publish the tgz distribution with name $moduleName, type 'java-library-dist', extension 'tgz', config 'dists' To implement something like this, the main thing missing at the moment is that there is no good way to influence the ivy.xml generation. We'd need to detangle this first. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
