Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Spelling (#8199)

Fix several spelling issues.

  1. … 22 more files in changeset.
Get rid of TaskPropertySpecs in property package

  1. … 41 more files in changeset.
Only allow more than one variant of a component if it has different capabilities

This commit significantly reworks how capabilities are handled, in particular

with regards to accepting 2 different variants of the same component to appear

in a graph. It is now allowed to have 2 variants of the same component if they

have distinct capabilities.

It shall be reminded that if a variant doesn't explicitly declare any capability,

it is assumed to carry the _implicit capability_, which corresponds to the GAV

of the component. Said differently, by default, all variants of a component

are supposed to be incompatible with each other (they cannot appear in the

same dependency graph).

If 2 variants are indeed compatible, then they _must_ have different capabilities.

This will be used to support optional dependencies, by making it possible to

express that one has to choose a specific set of compatible variants to enable

some feature.

There are however a few issues that needed to be addressed in this commit. First

of all, what we've just described is only true if we use variant-aware selection,

and more specifically attribute-based variant selection. If not, then a legacy

mode is used, and it's possible to have 2 "variants" of a component on the same

graph. This is typically the case when there are dependencies on 2 different

_configurations_ of a project:

dependencies {

api project(path: ':foo', configuration: 'conf1')

api project(path: ':foo', configuration: 'conf2')


For backwards compatibility reason, even if the 2 configurations actually

provide the same capability, this is allowed. Another case is when a cycle is

found between a root component and a transitive dependency corresponding to

the same component in a lower version.

Last but not least, in the engine the implicit capability is treated

specially for performance reasons: capability conflict resolution is very

expensive, and adding an explicit capability to all components would trigger

conflict resolution everywhere (to find out if other components provide the

same capability). This leads to some optimizations in the code which are not

necessarily easy to follow, but properly documented.

Mentioned contribution in the release notes

Signed-off-by: Szczepan Faber <>

    • -0
    • +1
Prove plugin spec builders work in multi-project setups

Rename `ConfigurableTargetMachine` to `TargetMachineBuilder`

Move Swift source compatibility to `SwiftTargetMachine` on `SwiftBinary`

This commit still doesn't consider the source compatibility when

selecting the tool chain.

  1. … 10 more files in changeset.
Replace appendix with classifier in sample

The documentation states, a couple lines before including this sample,

that classifier is to be preferred over appendix for correct


TeamCity change in 'Gradle / Test Build Agents' project: project 'Test Build Agents' was removed

Update contributing instructions with details for the IDEA import

Signed-off-by: Jendrik Johannes <>

Remove `idea` plugin application and related workarounds

Signed-off-by: Jendrik Johannes <>

Remove module classpath hackery only required for `idea` import

We no longer support idea project creation via the `idea` task.

Signed-off-by: Jendrik Johannes <>

Doc updates: deprecations in AbstractArchiveTask

This commit contains the userguide and javadoc updates following the

deprecations in AbstractArchiveTask.

Samples are also updated to no longer use any deprecated API.

Issue #8217

  1. … 10 more files in changeset.
Use simplified visitor for task mutation info

Emit plugin spec builders to module with unique name

Derived from the compile classpath to avoid conflicts across plugins.

KotlinDslPluginGradlePluginCrossVersionSmokeTest @LeaksFileHandles

Signed-off-by: Paul Merlin <>

Merge branch 'master' into eskatos/kotlin-dsl-merge

TeamCity change in 'Gradle / Promotion' project: requirements of 'Master - Start Release Cycle Test' build configuration were updated

Update DSL entry for AbstractArchiveTask

A number of properties have been deprecated, their replacement was

missing from the DSL documentation.

Also the defaults now reference the new properties instead of the

deprecated ones.

Issue #8217

    • -5
    • +21
Let tests using a dedicated gradle user home use isolated daemons

in order not to leak file descriptors

Signed-off-by: Paul Merlin <>

Fail resolution if 2 variants provide the same capability

This commit makes sure that we fail resolution whenever two variants

of a component provide the same capability. However, it doesn't do so

for the implicit variant yet.

  1. … 5 more files in changeset.
Remove PropertySpecFactory

  1. … 19 more files in changeset.
Temporarily tag some tests as @LeaksFileHandles

Signed-off-by: Paul Merlin <>

Adapt visitLocalStateProperty

Publish 5.1.1-20190111020102+0000

Correct grammar in docs (#8209)

Publish 5.1.1-20190111012402+0000

Fix typos

Update to latest nightly

    • -1
    • +1
Publish 5.1.1