Configuring a multi-project

All configuration is done in the root project. You need to apply the plugin to the root as well as each subproject that will provide artifacts to the publishing process.

Setting Sonatype tokens at root level

nempi {
  sonatypeUserToken = '123' (1)
  sonatypeUserPassword = System.getenv('ABC') (2)
}

1	Sets the user token. This can be anything that evaluates to a string, including providers. This expression is evaluated in the configuration-phase, the result is encrypted and kept in a byte array.
2	Sets the user password. As for the user token, this can be anything that evaluates to a string and then is encrypted and stored in memory.

Specify subprojects

Subprojects that will deliver artifacts must be provided via a filter

nempi {
  include { pName -> pName.endsWith('-library') } (1)
}

1 Tell the root project, which subprojects will be making artifacts available. This DSL statement is configured with a predicate which is passed the path of each subproject and should return true if the subproject is making an artifact available. If all subprojects are to be included something like { true } or () → true, will suffice. Not providing an include statement will result in no publication being performed.

The include statement should only be set once during configuration.

Include root in artifact provision

Normally in a multi-project setup, the root project will not create a publication of its own. However, in an unconventional context, the publication of the root project can also be added via thhe rootAlsoPublishes DSL block.

rootAlsoPublishes can only be called once.

nempi {
  rootAlsoPublishes { (1)
    // Configure as per metadata in a subproject.
  }
}

1	Configure as per metadata in a subproject. Any metadata DSL keyword that is used for a subproject can also be used inside this block. See below.

Configure subprojects

Required metadata for subproject

nempi {
  description = 'Description of project' (1)
  licenseName = 'Apache 2.0' (2)
  scmUrl = 'https://gitlab.com/org/repo' (3)
  websiteUrl = 'https://website.example' (4)

  developer { (5)

  }

  withInMemorySigning ( (6)
      provider { -> '123' }, (7)
      provider { -> file('key.txt').text } (8)
  )
}

1	A description for the project. Anything lazy-evaluated to a string will suffice. As an alternative to setting a value here, the project’s description property can be set.
2	Name of the license. Anything lazy-evaluated to a string will suffice.
3	Project code repository URL. Anything lazy-evaluated to a URI will suffice.
4	Website URL. Anything lazy-evaluated to a URI will suffice.
5	Add a developer. This can be called multiple times to add more developers. See below for valid fields. If you need more than these fields, use the `configurePom` DSL method to directly add developers rather than using this method.
6	Add in-memory keys for signing. The first parameter is the password for the GPG/PGP key and the second is the actual key. Any items that can be lazy-evaluated to strings can be used however, the evaluation will be in the configuration phase. If keeping the keys in memory is not to your liking, then you’ll need to wire the signing of the publication yourself.

Developer

nempi {
  developer {
    email = 'jane.doe@test.example' (1)
    name = 'Jane Doe' (2)
    url = 'https://gitlab.example/people/janedoe' (3)
    org = 'Acme Ltd' (4)
    orgUrl = 'https://acme.example' (5)
  }
}

1	Email of person. Anything lazy-evaluated to a string will suffice.
2	Name of person. This is the only required field. Anything lazy-evaluated to a string will suffice.
3	URL for this person. Anything lazy-evaluated to a URI will suffice.
4	Organization for this person. Anything lazy-evaluated to a string will suffice.
5	Organization URL for this person. Anything lazy-evaluated to a URI will suffice.

Optional metadata for subproject

In additional, the following can also be set

nempi {
  artifactId = 'my-artifact' (1)
  groupId = 'my.group' (2)
  licenseFile = 'path/to/LICENSE' (3)
  licenseUrl = 'http://www.apache.org/licenses/LICENSE-2.0.txt' (4)
  projectName = 'my-project' (5)
  scmConnection = 'scm:git:https://gitlab.com/org/repo.git' (6)
  scmDeveloperConnection = 'scm:git:https://gitlab.com/org/repo.git' (7)
  version = '1.2.3'  (8)

  contributor { (9)
  }

  configurePom { pom -> (10)

  }
}

1	Override the artifact id. By default, this is the name of the artifact generated by the `jar` task. Anything lazy-evaluated to a string will suffice.
2	Override the group. By default, this is read from the project group property. Anything lazy-evaluated to a string will suffice.
3	A license URL is required, but by default, the plugin will look for one of `LICENSE`, `LICENSE.txt`, `LICENSE.md`, and `LICENSE.adoc` in the root of the project. If this does not work for you, override the location of the license file. This relative path will be combined with the value set for the `scmUrl` property to derive a final URL. If the `scmUrl` is `gitlab.com` or `github.com` it will also add the appropriate subpath. Anything lazy-evaluated to a file will suffice.
4	Sets an explicit URL to where the license for this project can be found. Anything lazy-evaluated to a URI will suffice.
5	Override the project name. By default, this is the group identifier and the artifact identifier separated by a colon. Anything lazy-evaluated to a string will suffice.
6	By convention, this value is `scm:git:` + the SCM URL + `.git`. If this does not work for you, or you use a repository server other than Git, you can configure the correct URI here. Anything lazy-evaluated to a URI will suffice.
7	Similar to `scmConnection`, but allows override of the developer connection. Anything lazy-evaluated to a URI will suffice.
8	Override the version. By default, this is the project version. Anything lazy-evaluated to a string will suffice.
9	Add additional contributor. This can be called multiple times to add multiple contributors. See below for valid fields. If you need more than these fields, use the `configurePom` DSL method to directly add contributors.

Contributor

nempi {
  contributor {
    email = 'jane.doe@test.example' (1)
    name = 'Jane Doe' (2)
    url = 'https://gitlab.example/people/janedoe' (3)
    org = 'Acme Ltd' (4)
    orgUrl = 'https://acme.example' (5)
  }
}

1	Email of person. Anything lazy-evaluated to a string will suffice.
2	Name of person. This is the only required field. Anything lazy-evaluated to a string will suffice.
3	URL for this person. Anything lazy-evaluated to a URI will suffice.
4	Organization for this person. Anything lazy-evaluated to a string will suffice.
5	Organization URL for this person. Anything lazy-evaluated to a URI will suffice.