On 10/01/2013, at 7:12 AM, Daz DeBoer wrote:
> G'day
>
> In order to publish to a maven repository, you now need to explicitly add a
> MavenPublication. The rationale for this change is described at
> https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#publish-web-application-to-maven-repository
>
> The DSL for doing so looks like:
>
> publishing.publications {
> myPublicationName(MavenPublication) {
> from components.java // Publish the java-library component
> }
> }
>
> publishing.publications {
> myPublicationName {
> // More config for the existing publication
> }
> }
>
> So the method name gives the publication name, and the type is determined by
> the class argument. This is different from RepositoryHandler, for example,
> which uses the method name to define the type, and has a separate way of
> setting the 'name'. Using the name for type does lead to a bit of ambiguity
> in the DSL, because when creating you use repository.type and when accessing
> repository.name.
>
> repositories {
> flatDir {
> name "myFlatDir"
> }
> }
> repositories {
> myFlatDir {
> // some extra config
> }
> }
>
> I'm not sure the new syntax is better or worse, but it is a different
> paradigm. One thing to note is that the name of a publication is not
> particularly important: there will often be a single publication of a type,
> and the name is only used for referencing elsewhere in the build.
>
> So one option is to go with:
>
> publishing.publications {
> maven { // Creates a new MavenPublication
> name "myMavenPublication"
> from components.java
> }
> }
>
> publishing.publications {
> myMavenPublication {
> // More config for the existing publication
> }
> }
>
> This would be more consistent with other parts of the DSL
Not really. We use both approaches. Tasks are defined using name(type) syntax,
for example.
We want to aim for a consistent DSL for defining domain objects that works for
all types of domain objects that have identity, including tasks. These domain
objects all have a name and a type. Sometimes the name is important to the
user, sometimes it's not. Sometimes the type is important to the user,
sometimes it's not. This does make it somewhat tricky.
We could go with something like this:
- Provide the `name(type)` and `name(type) { config )` syntax for all
containers as the basic syntax for adding things to container.
- Provide `add(type, name)` methods for all containers, for usage from Java.
- For those containers where it makes sense, offer a default type, so that you
use `name { config }` and (deprecated) `name` conveniences.
- For those containers where name isn't important, offer a convenience syntax,
perhaps map based: `type param: value`
We don't necessarily need to go with an existing pattern, either, so there are
no doubt other options.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
