- Rename assertNotIs to assertIsNot
- Extract parts of implementation to helper internal PublishedApi
functions in order to inline minimum amount of code at use sites
- Remove PublishedApi from messagePrefix, no longer needed
:kotlin-test:kotlin-test-js:kotlin-test-js-it will still have old version as integration test run logic cannot be fully refactored to the new version (approximately till 3.1)
Relates to #KT-44611
So that the lambda can contain non-local control flow, such as suspend
calls. Inline-only helps preserving line numbers in the failed assertion
stack traces.
KT-44717
It is required to run tests authored with kotlin-test, so it seems
convenient to have it as a runtime dependency of kotlin-test-junit5
variant.
Depend on the version 5.6.0, which is approx. one year old.
Can be upgraded in the consumer project if necessary.
Also upgrade junit-jupiter-api dependency to 5.6.0, so that users could
use more recent JUnit functionality in JVM tests,
but continue compiling the artifact against 5.0.0 to leave a
possibility to downgrade JUnit platform dependency if needed.
KT-45107
When they are used explicitly in common source sets, they cannot be
resolved in platform ones after that since they only have
common kotlin-api variants in their metadata.
KT-40225
To do that, extract parts of publishing setup into reusable functions.
This change makes signing and repository configuration applied to all
project publications, not just to the Main one.
Also:
- Get rid of dependencies from non-default variants in the root pom
- Add an empty javadoc jar
KT-40225
The next step for JVM IR adoption in our project is going to be enabling
`kotlin.build.useIR`, but keeping `kotlin.build.useIRForLibraries`
disabled until we fix all remaining ABI incompatibility issues for
library code.
- Add exports for jvm package names used in kotlin.test annotations;
- Export transitively underlying test framework modules
Otherwise "This class does not have a constructor" happens when using
an aliased annotation, e.g. kotlin.test.Test aliased to org.junit.test
KT-41320
- unsupported common exceptions
- common 'synchronized'
- jquery API
- experimental kotlin.time API
- js Math object
- DefaultAsserter constructor-like fun
- Switch to building stdlib with bootstrap compiler since IR is stable
enough
- Build stdlib with coreLibs by default
- Include JS IR stdlib to kotlin distribution
They are used only in main build's .gradle.kts files, so it is more
flexible to define them as extensions - no need to republish
kotlin-build-gradle-plugin when another such property is to be added.
This avoids having both libraryJarWithoutIr and default jar artifact,
which points to the same path as libraryJarWithIr, in the dependent
projects' classpath.
Use libraryJarWithIr instead.
For local builds where libraryJarWithIr doesn't contain any IR, this
should have the same effect.
jar task is disabled, but its artifact is still used through
the runtime configuration in the other projects.
In fact, dependent projects get both
libs/kotlin-stdlib-js-1.3-SNAPSHOT.jar
lib/dist/kotlin-stdlib-js-1.3-SNAPSHOT.jar
in their classpath.
However the former artifact is built with libraryJarWithIr task after
jar task is skipped. This leads to a situation during the parallel build
that a dependent project tries to read that artifact
when libraryJarWithIr task writes it.
This commit adds a dependency edge between the disabled jar and custom
libraryJarWithIr tasks, so that the artifact is ready by
the moment jar task has finished.
The default Jar task is disabled, but its archive file is still
configured as an artifact to be published in the 'archives' configuration.
Thus, neither 'install', nor 'publish' tasks could not find this file
when `libraryJarWithIr` isn't triggered and does not build it.
Removing that artifact from the 'archives' configuration artifacts makes
'install' task publish nothing.
Therefore it's better to revert the change so that 'libraryJarWithIr' task
always runs and produces an artifact with the default name.
This reverts commit a9fec211
The switch `includeStdlibJsIr` now affects which artifact is published:
the one with IR or the one without. Previously it affected
whether or not IR was bundled into the artifact "with IR".
Ilya Gorbunov