LifecyclePlugin.kt

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Move 'lifecycle' plugin to own subproject and convert to script plugin

  1. … 3 more files in changeset.
Move 'lifecycle' plugin to own subproject and convert to script plugin

  1. … 3 more files in changeset.
Move 'lifecycle' plugin to own subproject and convert to script plugin

  1. … 3 more files in changeset.
WIP

  1. … 220 more files in changeset.
WIP

  1. … 219 more files in changeset.
WIP

  1. … 219 more files in changeset.
WIP

  1. … 215 more files in changeset.
WIP

  1. … 215 more files in changeset.
WIP

  1. … 216 more files in changeset.
WIP

  1. … 189 more files in changeset.
WIP

  1. … 216 more files in changeset.
WIP

  1. … 216 more files in changeset.
Consistently use file system

instead of file-system.

  1. … 9 more files in changeset.
Consistently use file system

instead of file-system.

  1. … 8 more files in changeset.
Fix syntax

Make sure promotion build can still find distributions to publish

  1. … 1 more file in changeset.
Remove more mentions of vfs retention

  1. … 7 more files in changeset.
Remove more mentions of vfs retention

  1. … 7 more files in changeset.
Rename build type to `watchFs`

  1. … 3 more files in changeset.
Rename build type to `watchFs`

  1. … 3 more files in changeset.
Rename build type to `watchFs`

  1. … 3 more files in changeset.
Introduce GradleDistributionsPlugin and multiple distribution projects

We can now have different distributions, containing different sets of

jars/functionality. For this, one subproject per distribution type is

created. Initially we introduce:

- _core_ (absolute minimum needed to run Gradle)

- _basics_ (Basic functionalities on top of core)

- _jvm_ (Everything needed for JVM ecosystem support)

- _native_ (everything for Native support)

- _publishing_ (everything to publish to Maven/Ivy repositories)

This is just an initial structure which we can now easily change. The

main point here is to enable a setup like this at all. New/different

distributions can now simply be added by adding a new subproject that

applies `gradlebuild.distribution.packaging` and defines the content of

the distribution in terms of dependencies.

Projects needing a distribution for testing, then depend on that project

e.g. `integTestDistributionRuntimeOnly(project(":distributionsJvm"))`

While introducing this, a lot of changes/improvements are done.

(See also previous commits and documentation in code.) Some major things:

- The embedded test runner now no longer supports running against a full

distribution as fallback. This has the advantage that we do not need to

assemble the distribution in embedded running, where the huge majority

of tests does not need it. To allow many tests still to run, all tests

were checked and the embedded support with TestKit/KotlinDSL involvement

has been improved. Some tests won't run with the embedded runner at all

now, but compared to the overall amount of tests, these are just a few.

And the "forking" tests always run as part of the PR pipeline.

- Cacheability of tests is highly improved. Because there are so much

changes to test inputs in this PR, I checked this carefully and

discovered that we broke some things recently when adding inputs for

distributed testing. These regressions are addressed. Other things were

improved along the line (local Tooling API repo no longer uses timestamp

version, local bin distribution without timestamp for wrapper tests,

sample tests no longer rely on absolute path and timestamp version, ...)

- The `docs.jar` is no longer part of the distribution. It almost had no

content and what it had was runtime metadata and not documentation.

Instead, a distribution project now encapsulates all the runtime

metadata creation and produces a `runtime-api-info.jar` that is specific

to the distribution.

- In the past we had flakiness issues causes by different distributions

sharing the same user home/daemon registry. With the fixed set of

distributions defined, we now use different user home/daemon registry

for each distribution.

- Cross-project configurations are (mostly) removed. There was some code

central to distribution building and runtime metadata generation that

reached into all subprojects. This is now replaced by using proper

variant aware dependency management to share artifacts between

distribution subprojects and the other subprojects.

  1. … 188 more files in changeset.
Introduce GradleDistributionsPlugin and multiple distribution projects

We can now have different distributions, containing different sets of

jars/functionality. For this, one subproject per distribution type is

created. Initially we introduce:

- _core_ (absolute minimum needed to run Gradle)

- _basics_ (Basic functionalities on top of core)

- _jvm_ (Everything needed for JVM ecosystem support)

- _native_ (everything for Native support)

- _publishing_ (everything to publish to Maven/Ivy repositories)

This is just an initial structure which we can now easily change. The

main point here is to enable a setup like this at all. New/different

distributions can now simply be added by adding a new subproject that

applies `gradlebuild.distribution.packaging` and defines the content of

the distribution in terms of dependencies.

Projects needing a distribution for testing, then depend on that project

e.g. `integTestDistributionRuntimeOnly(project(":distributionsJvm"))`

While introducing this, a lot of changes/improvements are done.

(See also previous commits and documentation in code.) Some major things:

- The embedded test runner now no longer supports running against a full

distribution as fallback. This has the advantage that we do not need to

assemble the distribution in embedded running, where the huge majority

of tests does not need it. To allow more tests still to run embedded,

the embedded support with TestKit/KotlinDSL involvement has been

improved. Some tests won't run with the embedded runner at all

now, but compared to the overall amount of tests, these are just a few.

And the "forking" tests always run as part of the PR pipeline.

- Cacheability of tests is highly improved. We broke some things

recently when adding inputs for distributed testing.

These regressions are addressed. Other things were

improved along the line (local Tooling API repo no longer uses timestamp

version, local bin distribution without timestamp for wrapper tests,

sample tests no longer rely on absolute path and timestamp version, ...)

- The `docs.jar` is no longer part of the distribution. It almost had no

content and what it had was runtime metadata and not documentation.

Instead, a distribution project now encapsulates all the runtime

metadata creation and produces a `runtime-api-info.jar` that is specific

to the distribution.

- In the past we had flakiness issues causes by different distributions

sharing the same user home/daemon registry. With the fixed set of

distributions defined, we now use different user home/daemon registry

for each distribution.

- Cross-project configurations are removed. There was some code

central to distribution building and runtime metadata generation that

reached into all subprojects. This is now replaced by using proper

variant aware dependency management to share artifacts between

distribution subprojects and the other subprojects.

  1. … 189 more files in changeset.
Introduce GradleDistributionsPlugin and multiple distribution projects

We can now have different distributions, containing different sets of

jars/functionality. For this, one subproject per distribution type is

created. Initially we introduce:

- _core_ (absolute minimum needed to run Gradle)

- _basics_ (Basic functionalities on top of core)

- _jvm_ (Everything needed for JVM ecosystem support)

- _native_ (everything for Native support)

- _publishing_ (everything to publish to Maven/Ivy repositories)

This is just an initial structure which we can now easily change. The

main point here is to enable a setup like this at all. New/different

distributions can now simply be added by adding a new subproject that

applies `gradlebuild.distribution.packaging` and defines the content of

the distribution in terms of dependencies.

Projects needing a distribution for testing, then depend on that project

e.g. `integTestDistributionRuntimeOnly(project(":distributionsJvm"))`

While introducing this, a lot of changes/improvements are done.

(See also previous commits and documentation in code.) Some major things:

- The embedded test runner now no longer supports running against a full

distribution as fallback. This has the advantage that we do not need to

assemble the distribution in embedded running, where the huge majority

of tests does not need it. To allow more tests still to run embedded,

the embedded support with TestKit/KotlinDSL involvement has been

improved. Some tests won't run with the embedded runner at all

now, but compared to the overall amount of tests, these are just a few.

And the "forking" tests always run as part of the PR pipeline.

- Cacheability of tests is highly improved. We broke some things

recently when adding inputs for distributed testing.

These regressions are addressed. Other things were

improved along the line (local Tooling API repo no longer uses timestamp

version, local bin distribution without timestamp for wrapper tests,

sample tests no longer rely on absolute path and timestamp version, ...)

- The `docs.jar` is no longer part of the distribution. It almost had no

content and what it had was runtime metadata and not documentation.

Instead, a distribution project now encapsulates all the runtime

metadata creation and produces a `runtime-api-info.jar` that is specific

to the distribution.

- In the past we had flakiness issues causes by different distributions

sharing the same user home/daemon registry. With the fixed set of

distributions defined, we now use different user home/daemon registry

for each distribution.

- Cross-project configurations are removed. There was some code

central to distribution building and runtime metadata generation that

reached into all subprojects. This is now replaced by using proper

variant aware dependency management to share artifacts between

distribution subprojects and the other subprojects.

  1. … 188 more files in changeset.
Introduce GradleDistributionsPlugin and multiple distribution projects

We can now have different distributions, containing different sets of

jars/functionality. For this, one subproject per distribution type is

created. Initially we introduce:

- _core_ (absolute minimum needed to run Gradle)

- _basics_ (Basic functionalities on top of core)

- _jvm_ (Everything needed for JVM ecosystem support)

- _native_ (everything for Native support)

- _publishing_ (everything to publish to Maven/Ivy repositories)

This is just an initial structure which we can now easily change. The

main point here is to enable a setup like this at all. New/different

distributions can now simply be added by adding a new subproject that

applies `gradlebuild.distribution.packaging` and defines the content of

the distribution in terms of dependencies.

Projects needing a distribution for testing, then depend on that project

e.g. `integTestDistributionRuntimeOnly(project(":distributionsJvm"))`

While introducing this, a lot of changes/improvements are done.

(See also previous commits and documentation in code.) Some major things:

- The embedded test runner now no longer supports running against a full

distribution as fallback. This has the advantage that we do not need to

assemble the distribution in embedded running, where the huge majority

of tests does not need it. To allow more tests still to run embedded,

the embedded support with TestKit/KotlinDSL involvement has been

improved. Some tests won't run with the embedded runner at all

now, but compared to the overall amount of tests, these are just a few.

And the "forking" tests always run as part of the PR pipeline.

- Cacheability of tests is highly improved. We broke some things

recently when adding inputs for distributed testing.

These regressions are addressed. Other things were

improved along the line (local Tooling API repo no longer uses timestamp

version, local bin distribution without timestamp for wrapper tests,

sample tests no longer rely on absolute path and timestamp version, ...)

- The `docs.jar` is no longer part of the distribution. It almost had no

content and what it had was runtime metadata and not documentation.

Instead, a distribution project now encapsulates all the runtime

metadata creation and produces a `runtime-api-info.jar` that is specific

to the distribution.

- In the past we had flakiness issues causes by different distributions

sharing the same user home/daemon registry. With the fixed set of

distributions defined, we now use different user home/daemon registry

for each distribution.

- Cross-project configurations are removed. There was some code

central to distribution building and runtime metadata generation that

reached into all subprojects. This is now replaced by using proper

variant aware dependency management to share artifacts between

distribution subprojects and the other subprojects.

  1. … 189 more files in changeset.
Introduce GradleDistributionsPlugin and multiple distribution projects

<TODO add description from PR>

  1. … 188 more files in changeset.
Introduce GradleDistributionsPlugin and multiple distribution projects

<TODO add description from PR>

  1. … 188 more files in changeset.
Move binary compatibility check to :architectureTest

This was part of the ':distributions' project before which will be

replaced by projects that represent different kind of distributions.

  1. … 3 more files in changeset.
Move binary compatibility check to :architectureTest

This was part of the ':distributions' project before which will be

replaced by projects that represent different kind of distributions.

  1. … 3 more files in changeset.
Move binary compatibility check to :architectureTest

This was part of the ':distributions' project before which will be

replaced by projects that represent different kind of distributions.

  1. … 3 more files in changeset.