**I'm agree with you, we should look at where we want to end up before going further.Szczepan told me to write a design specs for this feature , so I'll have a look at the template documents and I'll write it. I hope it will be a good starting point to discuss on what should be done.
* * 2012/9/3 Adam Murdoch <[email protected]> > > 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 > >
