On 6 December 2012 13:12, Adam Murdoch <[email protected]> wrote:
> > I suspect many projects currently apply both the 'java' and 'war' plugins, > so this change would mean that these projects would start publishing the > jar. > > There's also the case where configuration is injected conditionally based > on which plugins have been applied. > > We could tweak this approach to make it backwards compatible (in a way): > One goal that we have is that the 'war' plugin should not imply a > particular implementation language, or even that there is any source at > all. So, we would do something like: > > - Introduce a 'java-lang' plugin that knows how to compile java source. > Same for Scala and Groovy. > - Introduce a 'jvm-library' plugin that knows how to build a jvm-based > library. Does not apply any language plugins. > - Change the 'java' plugin to apply both these things. > - Introduce a 'web-application' plugin that knows how to build a j2ee web > application. Does not apply any language plugins. > - Change the 'war' plugin to apply both the 'web-application' and 'java' > plugins. > - New publishing DSL publishes all components > - Deprecate and remove the 'war' plugin > - Deprecate and remove the 'java' plugin (or rename it to 'java-library') > If the long-term plan is to deprecate both the 'war' and 'ear' plugins (replacing with language agnostic packaging plugins), then the question becomes more about how to deal with the migration. Maybe having special rules for the 'war' plugin and 'ear' plugin would allow us to move forward simply, while keeping the model pure. Something like: - war plugin removes any jvm-library component, or maybe turns it into a 'secondary' publication. - ear plugin removes any web-application component & jvm-library component, or turns it into a 'secondary' publication. We don't currently handle publication removal, but we probably should. There would be no way to publish both war & jar, until we add the new 'web-application' plugin (and add support for multiple main artifacts). This plan lets us introduce components in a way that will work with the current plugins without change. The benefit is that we can grow these concepts internally. The downside is some extra complexity. Since the 'ear' and 'war' plugins are slated for removal, this complexity has an effective end-of-life. So I guess the options are: 1) Introduce the 'jvm-library' and 'web-application' plugins: new publishing won't work without them 2) Hack the current rules into the way publications are generated from the 'war' and 'ear' plugins: new publishing will work without new plugins I don't feel that strongly either way. 1) will break builds using the new ivy-publish plugin, but only until they apply one of the new plugins. Probably not too much to ask. Daz
