Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Pass the module identifier factory down to module forcing resolve rule

    • -1
    • +1
    ./resolve/JvmLibraryResolveContextTest.groovy
  1. … 11 more files in changeset.
Revert De-duplicate commonly used immutable objects in dependency resolution and IDE changes

Commits reverted:

- 807b1e4f8d1585d93c1de3e9ca83d99d0819e2d2

- 9482b0b05374253cafdb776550d7016385912e04

- 4ecead06b53ec6b0f15c517bf0d0c6a74c3b3c05

- db1135a8a5f1c507e0df3c03ad12ddc963799e4d

- 7350bcbae30a777909cec74ebfd5a91d2c89081e

Additionally, minor changes to avoid usage of introduced

classes and methods from subsequent commits.

Issue: gradle/gradle-private#563

    • -1
    • +1
    ./resolve/JvmLibraryResolveContextTest.groovy
    • -1
    • +1
    ./resolve/JvmLocalLibraryDependencyResolverTest.groovy
  1. … 108 more files in changeset.
De-duplicate (= intern) some instances in dependency resolution

- Reduce memory usage of dependency resolution by de-duplicating the

most commonly used immutable instances.

- Objects aren't strictly immutable: displayName is calculated lazily

- solution is thread-safe without synchronization

- lazy calculation is needed for efficient interning since a lookup

will always create a new instance.

- Use strong references in some instance interners

- strong references cause less GC overhead than weak references

- Strong references:

DefaultModuleIdentifier

DefaultModuleVersionIdentifier

DefaultModuleVersionSelector

DefaultModuleComponentIdentifier

DefaultModuleComponentSelector

DefaultProjectComponentSelector

- Weak references:

DefaultLibraryBinaryIdentifier

DefaultLibraryComponentSelector

DefaultIvyArtifactName

- Both reference types:

DefaultBuildIdentifier

DefaultProjectComponentIdentifier

- The reason for special handing is that DefaultBuildIdentifier

has a state field "current" as part of the instance which

isn't part of equals/hashCode.

+review REVIEW-6277

    • -1
    • +1
    ./resolve/JvmLibraryResolveContextTest.groovy
    • -1
    • +1
    ./resolve/JvmLocalLibraryDependencyResolverTest.groovy
  1. … 103 more files in changeset.
Move JVM-component dependency resolution classes

Moved a lot of classes from ':platform-base' to ':platform-jvm',

and restructured into common `org.gradle.jvm.internal.resolve` package.

    • -74
    • +0
    ./DefaultJavaPlatformVariantAxisCompatibilityTest.groovy
    • -0
    • +73
    ./resolve/DefaultJavaPlatformVariantAxisCompatibilityTest.groovy
    • -0
    • +75
    ./resolve/DefaultVariantsMetaDataTest.groovy
    • -0
    • +49
    ./resolve/JvmLibraryResolveContextTest.groovy
    • -0
    • +292
    ./resolve/JvmLocalLibraryDependencyResolverTest.groovy
    • -0
    • +26
    ./resolve/ParametrizedBinaryString.java
    • -0
    • +26
    ./resolve/ParametrizedBinaryVariantDimension1.java
    • -0
    • +24
    ./resolve/ParametrizedVariant.java
    • -0
    • +22
    ./resolve/VariantDimension1.java
    • -0
    • +22
    ./resolve/VariantDimension2.java
    • -0
    • +20
    ./resolve/VariantDimension3.java
    • -0
    • +241
    ./resolve/VariantsMatcherTest.groovy
    • -0
    • +107
    ./resolve/VariantsMetaDataHelperTest.groovy
  1. … 46 more files in changeset.
Moved `ComponentSpecIdentifier` into an internal package.

    • -1
    • +1
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 6 more files in changeset.
Pushed `JvmBinaryTasks` down to `JarBinarySpec` and use same pattern as for the native binaries to statically declare the tasks.

  1. … 9 more files in changeset.
Fixed unit test for changes to descriptors of `BinarySpec` children.

    • -2
    • +2
    ./plugins/CreateJvmBinariesTest.groovy
Rework extensible type fixtures to simplify code

+review REVIEW-5695

    • -3
    • +1
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 13 more files in changeset.
Make extensible type fixtures work with managed types

Things that had to be cleared up:

- not all Base*Fixtures classes were creating nodes with managed

projections

- some tests were using a separate ManagedProxyFactory, and the same

type got generated twice in the same classloader

+review REVIEW-5695

  1. … 16 more files in changeset.
Merged `BinaryNamingSchemeBuilder` into `BinaryNamingScheme`.

    • -10
    • +2
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 13 more files in changeset.
Do not use the legacy decoration on the delegate objects created for `ComponentSpec`, `BinarySpec` and `LanguageSourceSet` elements.

+review REVIEW-5708

    • -3
    • +1
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 26 more files in changeset.
Use a consistent API for exported packages

- Removed calculated getter `JvmLibrarySpec.getExportedPackages()`

- Changed `JvmApiSpec.getExports()` to return `List<String>`

This change makes the API consistent from a read/write point of view.

+review REVIEW-5648

    • -0
    • +79
    ./JvmPackageNameTest.groovy
  1. … 8 more files in changeset.
Move ModelRegistryHelper functionality to Groovy extension module

+review REVIEW-5715

    • -1
    • +2
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 18 more files in changeset.
Use the public type of a `LanguageSourceSet` in its display name.

+review REVIEW-5708

  1. … 20 more files in changeset.
Fixed some unit tests for change to test fixture.

+review REVIEW-5708

    • -1
    • +2
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 7 more files in changeset.
Promote ApiSpec and co. to non-internal status

This change promotes ApiSpec, PackageName and related methods to

non-internal status in order to make them properly available to users,

especially when configuring the software model from within a

RuleSource class. Notice how it is now no longer necessary to

interact with the JvmLibrarySpecInternal interface in

ApiSpecIntegrationTest.

- Move o.g.jvm.{internal => }.ApiSpec and convert it to an interface

- Add o.g.jvm.internal.DefaultApiSpec implementation of ApiSpec

- Move o.g.jvm.{internal => }.PackageName

- Pull up api- and dependency-related mutators from

JvmLibrarySpecInternal to JvmLibrarySpec

- Add and polish Javadoc where appropriate

- Mark newly promoted types as @Incubating

+review REVIEW-5694

  1. … 10 more files in changeset.
Incorporate review feedback for ApiSpec

- Do not expose collections without first creating a defensive copy

- Do not mark types declared in internal packages as @Incubating

- Do not rely on #toString for purposes other than debugging

+review REVIEW-5663

  1. … 3 more files in changeset.
Move o.g.jvm.{internal.apigen=>tasks.api}

This commit moves all of the types directly within the

o.g.jvm.internal.apigen package to their new home in o.g.jvm.tasks.api.

Stay tuned for more exciting developments in subsequent commits.

    • -276
    • +0
    ./apigen/ApiStubGeneratorAnnotationsTest.groovy
    • -145
    • +0
    ./apigen/ApiStubGeneratorInnerClassTest.groovy
    • -453
    • +0
    ./apigen/ApiStubGeneratorTest.groovy
    • -202
    • +0
    ./apigen/ApiStubGeneratorTestSupport.groovy
    • -77
    • +0
    ./apigen/ApiStubGeneratorTestSupportTest.groovy
    • -545
    • +0
    ./apigen/ApiStubGeneratorValidationTest.groovy
  1. … 11 more files in changeset.
Move API stub generator into platform-jvm

+review REVIEW-5649

    • -0
    • +276
    ./apigen/ApiStubGeneratorAnnotationsTest.groovy
    • -0
    • +145
    ./apigen/ApiStubGeneratorInnerClassTest.groovy
    • -0
    • +453
    ./apigen/ApiStubGeneratorTest.groovy
    • -0
    • +202
    ./apigen/ApiStubGeneratorTestSupport.groovy
    • -0
    • +77
    ./apigen/ApiStubGeneratorTestSupportTest.groovy
    • -0
    • +545
    ./apigen/ApiStubGeneratorValidationTest.groovy
  1. … 52 more files in changeset.
BaseBinarySpec.sources is a node-backed ModelMap

  1. … 22 more files in changeset.
Remove the need for `ComponentSpecInternal` to expose a `FunctionalSourceSet`

- Rejigged CUnit plugin so that source sets are created via ModelMap API

- Don't use FunctionalSourceSet.baseDir to configure source directories for ComponentSpec.sources

- Removed `FunctionalSourceSet.baseDir`

Issue: gradle/langos#40 +review REVIEW-5681

    • -1
    • +2
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 7 more files in changeset.
Merge branch 'release'

    • -2
    • +1
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 4 more files in changeset.
Remove unused ProjectSourceSet

+review REVIEW-5669

    • -2
    • +1
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 15 more files in changeset.
Pass a baseDir to the fixture for JvmLibrarySpec's

    • -1
    • +2
    ./plugins/CreateJvmBinariesTest.groovy
Added convenience methods for generating task names to `BinaryTasksCollection`.

This allows a plugin to create tasks for a binary without needing to care about where in the model the binary might happen to live.

  1. … 6 more files in changeset.
Changed the JVM and native component plugins to use names for binaries that reflect the role they play.

Now that more than one component may have a binary with a given name, use:

- `jar` as the name for a Jar binary that belongs to a JVM library

- `executable` as the name for an executable that belongs to a native application

- `sharedLibrary` and `staticLibrary` as the name for the binaries of a native library.

These can later turn into static properties of the appropriate `ComponentSpec` types.

There is a breaking change in this commit: the lifecycle task name and output directory name of the binaries of components with multiple variants now include the component name at the start of the name, rather than somewhere in the middle.

    • -1
    • +1
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 26 more files in changeset.
Replace ambiguous language for referring to variants

- Use 'variant axis' for property on a variant type

- Use 'variant coordinate' for a value of this property

    • -0
    • +74
    ./DefaultJavaPlatformVariantAxisCompatibilityTest.groovy
    • -74
    • +0
    ./DefaultJavaPlatformVariantDimensionSelectorTest.groovy
  1. … 25 more files in changeset.
Moved the concept of the owning component of a binary up from various subtypes up to BaseBinarySpec.

Previously, native and jvm library binary specs exposed their owning component, for use in rules. This is now available in a consistent way for all binary specs (which can all be owned by a component). Later, this should probably be moved to a view that is mixed in to those binaries that are actually owned by a component.

This change also allows certain immutable properties of the component to be used to calculate some properties of the binary.

  1. … 11 more files in changeset.
Refactor JvmComponentPlugin

The following stylistic changes are made here in preparation for

substantive changes to this class in subsequent commits:

- Format Javadoc for readability

- Use public visibility consistently on rule-annotated methods

- Refactor #createBinaries and its related private methods for

readability and elimination of unused parameters

    • -2
    • +1
    ./plugins/CreateJvmBinariesTest.groovy
  1. … 1 more file in changeset.
Introduce JVM library API specification DSL

This change allows JVM library authors to specify and constrain the set

of packages that constitute a library's public API, e.g.:

model {

components {

main(JvmLibrarySpec) {

api {

exports 'com.example.p1'

exports 'com.example.p2'

}

}

}

}

The `api { }` DSL is backed by the newly-introduced `ApiSpec`, and

arguments to its `exports` clause are validated against JLS rules

governing package names. See Javadoc of the newly-introduced

`PackageName` class for details.

Aside from other basic validation, the presence (or absence) of an api

specification does not yet affect the output of the build; this will be

accomplished in subsequent commits. When implemented, it is assumed that

a `#getApiSpec` method will be exposed by the `JvmLibrarySpec`

interface, and that it will be called within

`JvmComponentPlugin#createBinaries` in order to generate 'api' and

'impl' jars that respect the api specification.

Basic user guide documentation for this feature is also introduced,

though it is essentially a placeholder at this point. As the overall

feature progresses toward completion, this section of the user guide

should be updated accordingly.

DSL documentation is *not* included here, as there is currently little

or no coverage of any software model components in the DSL docs. It is

assumed that a dedicated effort will be required to get the DSL docs up

to speed with the software model, and that api specification DSL

documentation will be added at that time.

Implementation notes and questions:

- On visibility:

The newly-introduced `ApiSpec` and `PackageName` types are

package-private and concrete, i.e. do not conform to the

<<InterfaceName>> and Default<<InterfaceName>> convention typical

throughout the Gradle codebase. This has been done intentionally so as

to encourage a discussion on these topics during code review. Likewise

for the newly-introduced and intentionally package-private

`DefaultJvmLibrarySpec#api` method.

- On validation:

This change implements api spec validation in a "fail-fast" manner,

i.e., validation occurrs immediately on processing each `exports`

clause, and any validation error results in the immediate throwing of a

`InvalidUserDataException`. The software model offers first-class

support for validation of model elements in the form of

`@Validate`-annotated methods, but experiments in validating api specs

in this manner proved awkward and verbose. It should be considered

during code review whether `@Validate`-style deferred validation is

indeed important and/or necessary, and if so, how best to do it.

- On the use of Javadoc for internal and/or incubating types:

Newly-introduced internal types have been documented with Javadoc; this

is a departure from the norm, but again done intentionally so as to

spur discussion on the topic.

+review REVIEW-5648

    • -0
    • +71
    ./PackageNameTest.groovy
  1. … 7 more files in changeset.