Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Some renames and moves

Declared -> Registered

Move ValidatingValue to properties package

  1. … 31 more files in changeset.
Move validation out of ValidatingValue

Change class generation to accept interface types. The interface may define mutable properties and an implementation is mixed in for each mutable property. The interface may also define `default` methods, `@Inject` properties and may extend `ExtensionAware`. Immutable properties with lazy types (eg `Property`) are not supported yet.

This commit does not include any validation or documentation. These will be added in later commits.

Add `@TransformAction` annotation to allow the transform action associated with a transform configuration type to be declared, so that it does not have to be specified when the transform is registered.

Publish 5.1.1-20190114000039+0000

TeamCity settings change: convert settings from version 856 to version 875

TeamCity settings change: convert settings from version 856 to version 875

Add tests for check/build when current machine is not targeted

Fail specifically when target machines do not target current machine

Fix broken sample out

Signed-off-by: woojin.joe <>

Run perf and cputemp

Issue 7398: groovy + java-library plugin compatibility.

Signed-off-by: James X. Nelson <>

Issue 7398: groovy + java-library plugin compatibility.

Signed-off-by: James X. Nelson <>

Publish 5.1.1-20190113000038+0000

Publish 5.1.1-20190112000052+0000

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.