Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Update worker api test coverage to use typed parameter api

  1. … 4 more files in changeset.
Update worker api test coverage to use typed parameter api

  1. … 4 more files in changeset.
Update worker api test coverage to use typed parameter api

  1. … 4 more files in changeset.
Update worker api test coverage to use typed parameter api

  1. … 4 more files in changeset.
Update worker api test coverage to use typed parameter api

  1. … 4 more files in changeset.
Rebaseline `configure largeJavaMultiProject` performance test

As a 2-3% regression has been going on for some time now.

Signed-off-by: Rodrigo B. de Oliveira <rodrigo@gradle.com>

Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

Merge pull request #9922 from gradle/wolfs/ci/buildTypesInSubprojects

Merge build types running only unit tests

Let Kotlin DSL use first kotlin public type for accessors

on all containers (tasks, extensions, etc..)

Signed-off-by: Paul Merlin <paul@gradle.com>

Let Kotlin DSL use first kotlin public type for accessors

on all containers (tasks, extensions, etc..)

Signed-off-by: Paul Merlin <paul@gradle.com>

Let Kotlin DSL use first kotlin public type for task accessors

Signed-off-by: Paul Merlin <paul@gradle.com>

Remove SkipWhenEmpty leftovers

Remove SkipWhenEmpty leftovers

Document deprecations of usage values

Document deprecations of usage values

ClasspathFingerprintingStrategy should fail for broken non-root inputs

ClasspathFingerprintingStrategy should fail for broken non-root inputs

Add test proving that we can know have a Scala+Java Library component

Closes #8788

Add test proving that we can know have a Scala+Java Library component

Closes #8788

Add test proving that we can know have a Scala+Java Library component

Closes #8788

Add test proving that we can know have a Scala+Java Library component

Closes #8788

Add test proving that we can know have a Scala+Java Library component

Closes #8788

Add test proving that we can know have a Scala+Java Library component

Closes #8788