Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rename {Validating -> Property}Value

The value doesn't validate any more.

  1. … 23 more files in changeset.
Use Bintray version 1.8.0

Looks like 0.4.1 is using `TaskValidator`.

Make warning message more informative

Only warn if the current operating system isn't targetted by a component

Merge remote-tracking branch 'origin/gh/stable-native/assemble-fails'

* origin/gh/stable-native/assemble-fails:

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

Fail specifically when target machines do not target current machine

Perform validation check when task dependencies are calculated

Test task fails when current operating system is not targeted

Make assemble fail when nothing can be built

Add clarification about which VM the org.gradle.java.home property affects

Move more things to properties package

  1. … 21 more files in changeset.
Some polishing

  1. … 10 more files in changeset.
Use same build invocation ID for the build tree

We actually have a scope for this now.

This change also means that GradleBuild incovations will receive their own build invocation IDs now.

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 <jwj0831@gmail.com>

Run perf and cputemp

Issue 7398: groovy + java-library plugin compatibility.

Signed-off-by: James X. Nelson <James@WeTheInter.net>

Issue 7398: groovy + java-library plugin compatibility.

Signed-off-by: James X. Nelson <James@WeTheInter.net>

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 <szczepiq@gmail.com>

    • -0
    • +1
    /subprojects/docs/src/docs/release/notes.md
Prove plugin spec builders work in multi-project setups

Rename `ConfigurableTargetMachine` to `TargetMachineBuilder`