On Nov 29, 2012, at 5:44 PM, Adam Murdoch <[email protected]> wrote:
> Hi, > > We have a pull request queued up that adds a 'java-library' plugin: > https://github.com/gradle/gradle/pull/101 > > The idea behind this plugin that it will build a distribution zip or tgz for > a jvm based library, which you can use for distributing the library, > generally as an alternative or complement to publishing the library to a > repository somewhere. > > We've held off applying this pull request while we sorted out some of the new > publication stuff. I think we're now ready to add this plugin. > > One issue is that the plugin id 'java-library' is a bit too general for what > this plugin does, and we want to use 'java-library' for other purposes (see > below), so I would propose renaming it to something like > 'jvm-library-distribution' to reflect what it does. > > Then, once added, we can (incrementally, of course): > > 1. Add a 'java-library' plugin that declares that the project produces a Java > library. This would be an opinionated plugin that defines a main Java library > component. It would publish the component. There will be a base plugin that > adds the capability for building Jvm library components. > 2. Extract a 'distribution' plugin out of the 'jvm-library-distribution' and > 'application' plugins. This would be an opinionated plugin that defines a > single distribution which contains all library and application components > that the project produces. It would also publish the distribution. There will > be a base plugin that adds the capability for building distributions from > components. > 3. Deprecate and remove the 'jvm-library-distribution' plugin. You'd use the > 'java-library' and 'distribution' plugins together instead. > 4. Extract a 'java-application' plugin out of the 'application' plugin. This > would be an opinionated plugin that defines a main Java application > component. It would publish the component. There will be a base plugin that > adds the capability for building Jvm application components. > 5. Deprecate and remove the 'application' plugin. You'd use the > 'java-application' and 'distribution' plugins together instead. > 6. Change the c++ plugins to define library and application components for > the libraries and executables it creates. You could then use the > 'distribution' plugin to bundle these things into a distribution. > > Then we can do all kinds of interesting things: > 7. Add plugins to offer additional ways to package Java application > components: executable fat jar, native executable, .app bundle, etc. > 8. Add an 'rpm' plugin that uses the meta-data for the library and > application components to generate rpms for those components. > 9. Add a 'java-daemon' plugin that can take a jvm application component and > package it as a daemon/service. > > So, net result is: > > apply plugin: 'java-library' > apply plugin: 'distribution' > > Running 'gradle assemble' will build a .zip and .tgz containing the library > Jar, the API documentation, the jars for the runtime dependencies, etc. > > apply plugin: 'cpp-lib' > apply plugin: 'distribution' > > Running 'gradle assemble' will build a .zip and .tgz containing all variants > of the native library, plus the API docs, etc (or perhaps it builds a zip/tgz > per variant). > > apply plugin: 'scala-library' > apply plugin: 'distribution' > > Running 'gradle assemble' will build a .zip and .tgz containing all variants > of the library Jar, the API docs, the jars for runtime dependencies for each > variant, etc. I love this. This would also provide a blue print for organizations using Gradle on how to structure and work with Gradle plugins. Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleware CEO, Gradleware - Gradle Training, Support, Consulting http://www.gradleware.com > > Step #1 we need to do soon, to make progress on the publishing DSL. The other > steps can happen whenever. I think we should apply the pull request as is, > rename the plugin, and then do the remaining steps in the master branch. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com >
