Not publishing this attribute fixes the consumers that don't set it.
Those may encounter either a conflict of Kotlin <= 1.5.31 rule on
{JVM, Android} -> Android vs Gradle rule
{standard-jvm, android} -> standard-jvm (causing disambiguation
failures). Or they may run Gradle < 7.0 which doesn't have
disambiguation rules for `org.gradle.jvm.environment` and therefore
treats it as an ordinary extra attribute, thus eventually preferring
variants which don't have it if no other disambiguation rule worked
(again causing disambiguation failures since some rules may prefer the
variants where this attribute *is* set).
Also set a "non-jvm" value of this attribute for non-JVM variants for
project-to-project dependencies in order to "align" them so that Gradle
doesn't prefer variants not marked with this attribute.
Extend the set of dependency resolution tests which check
compatibility of different kinds of Android & JVM consumers against
project and published library: add Kotlin 1.5.31 consumers, also check
consumption with different Gradle version than the one which did the
publication.
Issue #KT-49835
It's already was not causing the build failure because of changes related to persisted yarn.lock but this fix is more reliable.
Also hidden `kotlinNpmCachesSetup` task by unsetting task group as it's not supposed to be executed directly and moreover direct execution makes no sense.
#KT-47215 Fixed
Ensure that the attribute com.android.build.api.attributes.AgpVersionAttr
is not published when creating the android usage contexts.
^KT-49798 Verification Pending
This test publishes a Multiplatform/Android library locally with
a given AGP version (7.1-*+) and tests the compatibility with older
AGP consumer versions.
Two projects will be tested:
multiplatformAndroidConsumer:
kotlin("multiplatform") + android target depending on
the previous publication as 'commonMainImplementation' dependency
plainAndroidConsumer:
kotlin("android") depending on the previous publication
as 'implementation' dependency.
Both projects will test the 'assemble' umbrella task to ensure,
compatibility with the given publication.
^KT-49798 implicitly covered as well
This test covers ^KT-49798 by publishing an Android library and
checking that 'AgpVersionAttr' is not mentioned in any .module files
of those publications.
The previous implementation would return a 'SharedCommonizerTarget'
containing just a single leaf target. This would trigger the commonizer.
The new implementation will correctly return just a single
LeafCommonizerTarget instead.
^KT-49735 Verification Pending
Prior to this change a 'Collection is empty.' error was reported
when the Android plugin was applied without an Android Kotlin target
being registered.
^KT-41641 Verification Pending
This convention seems to be more robust against clashes against user
specified source set names. We could potentially foresee users to
use "cinterop" as source set name, but the pattern
$sourceSetName-cinterop seems robust enough.
^KT-49596 Verification Pending
- Also increase the KotlinProjectStructureMetadata's format
version to 0.3.2
- Move new default location into /cinterop/{sourceSetName}
^KT-49596 Verification Pending
This is faster than the current approach which creates
`JavaClassDescriptor`s, converts them to protos, and then snapshots
these protos.
- Refactor unit tests to faciliate further changes
- moves test data to a directory that matches the tests' package name
- moves expected snapshots to a separate directory
- adds public and private fields/properties to sample class
- Compute changes between ASM-based Java class snapshots
- Don't collect members of an added Java class as changes
as it's enough to report the name of the added Java class as changed (we
also do that for added Kotlin classes and Kotlin/Java removed classes).
- Add unit tests for impact analysis in advance
- Compute impacted symbols of changed symbols
Also do not collect added classes/class members as they don't impact
recompilation.
-Use ClassId when computing Java class changes
It is more precise than JvmClassName, which can be ambiguous around the
`$` character (e.g., ClassId "com/example/A$B.C" and "com/example/A.B$C"
both have the same JvmClassName "com/example/A$B$C").
- Compute impacted set of changed symbols across Kotlin and Java
- Add unit tests for impact analysis across Kotlin and Java
- Compute supertypes of Kotlin classes during snapshotting
- Handle inner classes when computing list of changed symbols.
For the reported symbols, always check all options:
class member, inner class, top level class, top level member.
Test: IncrementalJavaChangeClasspathSnapshotIT.testAddingInnerClass
Yahor Berdnikau