Plugin allows the expression of the contacts involved with a project. This data is then made available to other plugins, to be injected in different outputs, e.g. the developers section of the POM via the nebula-publishing-plugin or the jar manifest via the gradle-info-plugin. Each contact can be marked with a role that the other plugins will use as a discriminator. Having no role indicates that the contact should be part of every role.
The simplest use is to specify a single point of contact:
apply plugin: 'contacts'
contacts '[email protected]'
Muliple people in their simple form:
apply plugin: 'nebula.contacts'
contacts '[email protected]', '[email protected]', '[email protected]'
A little bit richer, only one user:
apply plugin: 'nebula.contacts'
contacts {
'[email protected]' {
moniker 'Mickey Mouse Club'
}
}
Mix of people and teams:
apply plugin: 'nebula.contacts'
contacts {
'[email protected]' {
moniker 'Mickey Mouse Club'
}
'[email protected]' {
moniker 'Mickey Mouse'
}
'[email protected]' {
moniker 'Minnie Mouse'
github 'mmouse'
}
}
Using roles to differentiate:
apply plugin: 'nebula.contacts'
contacts {
'[email protected]'
'[email protected]' {
roles 'notify', 'owner'
}
'[email protected]' {
role 'techwriter'
}
'[email protected]'
role 'notify'
}
}
Using email validation:
apply plugin: 'nebula.contacts'
contacts {
validateEmails = true
'[email protected]' {
moniker 'Mickey Mouse Club'
}
}
Each person
takes a closure and adds a single person. A contact can configure the following fields:
- moniker - Full name of owner
- github - Github username
- twitter - Twitter handle
- role - See below.
Contacts can have role
s specified. It can be done via these calls, which can be called multiple times:
- role(String singleRoleName)
- roles(String... roleNames)
Technically the contacts-base (nebula.plugin.contacts.BaseContactsPlugin) plugin is what provides the ability to specify contacts. The contacts plugin just applies the contacts-base, contacts-manifest, and contacts-pom plugins. The learn about the other plugins read below.
- Merge duplicate calls
- Formalize possible roles via a DSL
Plugin takes the contacts and stuffs them to the gradle-info-plugin, this makes them available as manifest values (for the .jar, .rpm, a properties file). We'll publish to tags, Module-Owner and Module-Email. Module-Owner is a common separated list of all contacts that have the "owner" role (or no role). Module-Email is a common separated list of contacts that want to be notified when changes are made to this module, they have to have the role of "notify" (or no role). We're assuming that multiple owners are allowed, and we can just comma separate them.
buildscript {
repositories { mavenCentral() }
dependencies { classpath 'com.netflix.nebula:gradle-contacts-plugin:1.9.+' }
dependencies { classpath 'com.netflix.nebula:nebula-publishing-plugin:1.9.+' }
}
apply plugin: 'nebula.contacts-base'
apply plugin: 'nebula.contacts-manifest'
apply plugin: 'info'
contacts {
'[email protected]' {
roles 'owner'
}
'[email protected]' { }
'[email protected]' {
role 'notify'
}
}
Would produce the following values in build/manifest/info.properties:
Plugin takes all the contacts and adds them to the developers section of the POM if using the nebula-publishing-plugin.
apply plugin: 'nebula.contacts-base'
apply plugin: 'contacts-pom'
apply plugin: 'nebula-maven-publishing'
contacts {
'[email protected]' {
roles 'owner'
}
'[email protected]' {
moniker 'Billy Bob'
}
'[email protected]' {
role 'notify'
}
}
Would produce a section in the POM like this:
<developers>
<developer>
<id>bob1978</id>
<email>[email protected]</email>
<roles>
<role>owner</role>
</roles>
</developer>
<developer>
<name>Billy Bob</name>
<email>[email protected]</email>
</developer>
<developer>
<email>[email protected]</email>
<roles>
<role>notify</role>
</roles>
</developer>
</developers>
POMs support very rich definitions for developers and contributors (https://maven.apache.org/pom.html#Developers). Though, a quick analysis shows that these are rarely very complete. This plugin isn't targeting to support all the POM fields, but this could be possible in the future. The primary goal of this plugin is to identify one or two primary contact of the project, with the expectation that communication with developers/collaborators would be done via a mailing list and not trolling the POM file.