On 6 December 2012 15:42, Adam Murdoch <[email protected]> wrote:
>
> On 07/12/2012, at 8:36 AM, Daz DeBoer wrote:
>
> Just to recap where we've gotten to so far, I think we have the following
> options.
>
> Note: for all these options, there will be a DSL to allow you do
> explicitly declare the components to be published.
>
> 1. Publish nothing by default:
> * Either the 'java' plugin or a new 'jvm-library' plugin (or both)
> registers a jvm-library component.
> * Need to declare exactly what to publish via the DSL.
>
I guess publishing everything would be as simple as something like:
publications {
publish components.all // Not sure if 'publish' is the right keyword
here?
}
This option also removes the question of what to publish when no
component/publication is available (it's no longer implicit).
Would we want to provide a way to publish certain components to particular
repositories?
> 2. Publish a single thing, inferred from the set of components declared
> for the project.
> * Either the 'java' plugin or a new 'jvm-library' plugin (or both)
> registers a jvm-library component.
> * Can replace or add to the inferred component via the DSL.
> * Two variations for the rule:
> * if there is exactly one component, then use it.
> * if there is exactly one component, then use it. When there are multiple
> components, then 2jee app wins over web app wins over jvm library wins over
> jvm component.
> * Fail if we can't infer the component to publish.
>
> 3. Publish everything, by default don't publish the jar:
> * The 'java' plugin does not register any component.
> * A new 'jvm-library' plugin registers jvm-library component.
> * This implies that the 'war' and 'application' plugins will not
> implicitly add a jvm-library component.
>
I think the 'publish every component' could work pretty well, *if* we
assume that the existing plugins will not register any components:
* For starters, we have 'jvm-library' and 'j2ee-web-application'
components, with new plugins that add them to the model.
* 'java' & 'war' plugins do not register any components
* Publishing will attempt to publish *all* registered components.
* Publishing multiple components will fail gracefully, until we
implement and test properly.
* Publishing with no components will fail.
I'm not sure that this option removes the need for a DSL for specifying
exactly what to publish. Or perhaps this level of control is done on the
Publications collection instead of at the Component level?
> 4. Publish everything, by default don't publish jar when used with war
> plugin
> * The 'java' plugin registers a jvm-library component.
> * A new 'java-lang' plugin adds java language support.
> * The 'war' plugin or a new 'web-application' plugin adds java language
> support but does not implicitly add a jvm-library component.
> * Do the same for the 'application' plugin.
>
> I'd like to add a new option:
>
> 5. Introduce the concept of bundling, and publish those components that do
> not bundle (or imply) one of the other components:
> * If I produce a jvm component and a web application that bundles that
> library, then I almost always want to publish just the web application.
> * If I produce a web application and a jvm component and a j2ee
> application that bundles the web app and library, then I almost always want
> to publish the j2ee application
> * If I produce a java command-line application and a jvm component that is
> bundled, then I want to publish the application.
> * If I produce a jvm component and a native shared library, then I want to
> publish both.
> * If I produce a jvm library and a web application that does not include
> that library, then I want to publish both.
>
> Just a reminder: for all these options, there will be an underlying DSL
> where you can change whatever it is that Gradle publishes by default. So, I
> think the goal here is to choose an option that most often does the right
> thing (and preferring an approach where you add missing stuff rather than
> remove unwanted stuff). We don't need a solution that always does the right
> thing.
>
> At this stage, I think option #1 or option #5 is the way to go. We can get
> started without requiring any restructuring of the existing plugins (which
> we still want to do at some point).
>
I'd vote for #1 or #3, with a slight preference for #3. My reasoning is
that it 'just works' in more cases: a user declares what the project
produces (jvm-library, etc) and that thing gets published.
--
Darrell (Daz) DeBoer
Principal Engineer, Gradleware
http://www.gradleware.com
