In a Kotlin/native project, gradlew build successfully builds the project, but emits the warning:
Kotlin Multiplatform Projects are an Alpha feature. See:
https://kotlinlang.org/docs/reference/evolution/components-stability.html.
To hide this message, add 'kotlin.mpp.stability.nowarn=true' to the
Gradle properties.
So, I tried adding kotlin.mpp.stability.nowarn=true to settings.gradle.kts. This didn't work, I get the error:
Script compilation errors:
Line 2: kotlin.mpp.stability.nowarn = true
^ Unresolved reference: mpp
Line 2: kotlin.mpp.stability.nowarn = true
^ Variable expected
2 errors
I tried renaming settings.gradle.kts to settings.gradle to use Groovy syntax, but then I get the error:
A problem occurred evaluating settings 'kangaroo-kotlin'.
> Could not get unknown property 'kotlin' for settings 'kangaroo-kotlin' of type org.gradle.initialization.DefaultSettings.
How to correctly set the flag to get rid of the warning?
Add the flag to a file named gradle.properties, which should be located in the same directory as settings.gradle.kts
── my-project/
├── gradle/
├── src/
├── build.gradle.kts
├── settings.gradle.kts
└── gradle.properties
# contents of gradle.properties
kotlin.mpp.stability.nowarn=true
Related
I have a gradle project setup which looks similar to the one graphed below and I have some trouble setting up the dependencies between the different modules
┌Top Kotlin Project
│
├── Project1
│ │
│ ├── ModuleA1 (uses C1)
│ ├── ModuleA2
│ ├── ModuleA3
│ └── settings.gradle
├── ModuleB1 (uses C1)
├── ModuleC1 (library project)
└── settings.gradle
The Modules in A1,A2,A3 and B1 are basically isolated Gradle applications with their own build.gradle.kts
Module C1 is supposed to be a library module with shared code, that is used by Module A1, and Module B1.
Originally I thought I only had to declare C1 as an implementation dependency in the build.gradle.kts files of A1 and B1, like this
implementation(project(":ModuleC1"))
and include it in the settings.gradle of the Top Kotlin Project and also Project 1
include(":ModuleC1")
project(":ModuleC1").projectDir = File("../modulec1") #this line only needed in settings.gradle of Project1
However this does not work for multiple reasons.
First of all, all other projects/modules need to include all the repositories ModuleC needs, which means, whenever ModuleC changes I might need to also change the build files of other modules.
Most importantly though, all modules need the kotlin gradle plugin to build.
However if ModuleC1 includes the plugin and ModuleA1 as well, I get error that
> Plugin request for plugin already on the classpath must not include a version
If I do not include the Plugin in ModuleC1 it works for ModuleA1, but ModuleC1 cannot be built alone anymore.
The gradle.build.kts of ModuleC1 currently looks like this:
plugins {
kotlin("jvm") version "1.6.20"
`java-library`
}
group = "org.test.project"
version = "0.1"
repositories {
mavenCentral()
}
dependencies {
testImplementation("org.junit.jupiter:junit-jupiter-api:5.8.1")
testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.8.1")
}
tasks.getByName<Test>("test") {
useJUnitPlatform()
}
In conclusion I think, this setup of simply including the ModuleC1 in the other projects/modules is pretty flawed and there must be a better way to do this.
In summary, my goals are to be able to develop ModuleC1 independently but be able to use it in the other modules as if it was just another package there.
I'm trying to configure a Kotlin Multiplatform Project with Android and Ktor modules in it. After configuration, running the Ktor app fails with this message:
/usr/lib/jvm/java-8-openjdk-amd64/bin/java -javaagent:/home/lenqnr/intellij-idea/lib/idea_rt.jar=44331:/home/lenqnr/intellij-idea/bin -Dfile.encoding=UTF-8 -classpath /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/charsets.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/cldrdata.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/dnsns.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/icedtea-sound.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/jaccess.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/java-atk-wrapper.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/localedata.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/nashorn.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/sunec.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/sunjce_provider.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/sunpkcs11.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/zipfs.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jce.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jsse.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/management-agent.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/resources.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.ktor/ktor-server-netty/1.2.2/86f06a652bf2859236835e802cd81dc884a72c61/ktor-server-netty-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.ktor/ktor-server-host-common/1.2.2/80e62a4dab4e116aeb50e8017838b83836764bf9/ktor-server-host-common-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.ktor/ktor-server-core/1.2.2/37ba2773c666ff3f9f35a6d5949b8b8c2edd6adf/ktor-server-core-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.ktor/ktor-http-cio-jvm/1.2.2/22659690f735fa439b4f91b83ef846e3ec7dedf1/ktor-http-cio-jvm-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.ktor/ktor-http-jvm/1.2.2/1381ef340b58a3287f1da884b9db7280466c67ff/ktor-http-jvm-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.ktor/ktor-network/1.2.2/e8b2d5f46acfc25d7e893dde14f8da41ab28b7fd/ktor-network-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.ktor/ktor-utils-jvm/1.2.2/7c51add50945d74c07926e11acd33b66295903c8/ktor-utils-jvm-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk8/1.3.40/2d1d0a2f27fd060787075c69113846803fc27734/kotlin-stdlib-jdk8-1.3.40.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/ch.qos.logback/logback-classic/1.2.1/706a8b8206ead3683ec639dd270d11fd948fbb0e/logback-classic-1.2.1.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk7/1.3.40/2995de8f68444ad47f29e7b59962ac31e6301d7e/kotlin-stdlib-jdk7-1.3.40.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-coroutines-io-jvm/0.1.10/ec98e487d8c710126001c4f3086e4a0b9c0d3179/kotlinx-coroutines-io-jvm-0.1.10.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-io-jvm/0.1.10/74f179ae134d78ad360770801807c7078e71885/kotlinx-io-jvm-0.1.10.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-coroutines-jdk8/1.2.2/71653b85af2fe6baeb5314c2863dffe7aac8068a/kotlinx-coroutines-jdk8-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-coroutines-core/1.2.2/6ff48bdfc38a8c22e3fc37605b6a6afaed3b6dbd/kotlinx-coroutines-core-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.3.40/f2f8357e000fd80d8d799110f012b86fd4637386/kotlin-reflect-1.3.40.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.3.40/b8a521c687329303778548e2f09b0ba5b2665236/kotlin-stdlib-1.3.40.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/atomicfu/0.12.9/5cee16643956d76c52c7ef345448b0990b6e1e04/atomicfu-0.12.9.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-api/1.7.25/da76ca59f6a57ee3102f8f9bd9cee742973efa8a/slf4j-api-1.7.25.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/com.typesafe/config/1.3.1/2cf7a6cc79732e3bdf1647d7404279900ca63eb0/config-1.3.1.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-codec-http2/4.1.36.Final/ed198d8a5283910b0c062a50dd28ef4688dcb2a5/netty-codec-http2-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty.alpn/alpn-api/1.1.3.v20160715/a1bf3a937f91b4c953acd13e8c9552347adc2198/alpn-api-1.1.3.v20160715.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-transport-native-kqueue/4.1.36.Final/a2c6883a0f2e0adc15e6d764ced0ef044e2311c7/netty-transport-native-kqueue-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-transport-native-epoll/4.1.36.Final/5eb8b3ad0a99a16e5ae492da27544b1143e00606/netty-transport-native-epoll-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/ch.qos.logback/logback-core/1.2.1/378913dfc3c6c71e7e2a2853eff2c3e8ac27599/logback-core-1.2.1.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-coroutines-io/0.1.10/798b764e7f9396e63eb263a83c0385686d69f3e0/kotlinx-coroutines-io-0.1.10.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-io/0.1.10/c407b4bf931379824cf002f110df028cfe18c87c/kotlinx-io-0.1.10.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-coroutines-core-common/1.2.2/8b54928fbb813408684911eb27d6afeb23c92a4b/kotlinx-coroutines-core-common-1.2.2.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-common/1.3.40/ff8f3da514fc2877d1303d55e22d6da8156c29fb/kotlin-stdlib-common-1.3.40.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains/annotations/13.0/919f0dfe192fb4e063e7dacadee7f8bb9a2672a9/annotations-13.0.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/atomicfu-common/0.12.9/ba80bc10a440ea504b5cebd262becf9870e309c3/atomicfu-common-0.12.9.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-codec-http/4.1.36.Final/62b73d439dbddf3c0dde092b048580139695ab46/netty-codec-http-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-handler/4.1.36.Final/1c38a5920a10c01b1cce4cdc964447ec76abf1b5/netty-handler-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-codec/4.1.36.Final/8462116d327bb3d1ec24258071f2e7345a73dbfc/netty-codec-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-transport-native-unix-common/4.1.36.Final/d95d7033f400f9472db9da7834c443b96cd4bab0/netty-transport-native-unix-common-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-transport/4.1.36.Final/8546e6be47be587acab86bbd106ca023678f07d9/netty-transport-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-buffer/4.1.36.Final/7f2db0921dd57df4db076229830ab09bba713aeb/netty-buffer-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-resolver/4.1.36.Final/e4d243fbf4e6837fa294f892bf97149e18129100/netty-resolver-4.1.36.Final.jar:/home/lenqnr/.gradle/caches/modules-2/files-2.1/io.netty/netty-common/4.1.36.Final/f6f38fde652a70ea579897edc80e52353e487ae6/netty-common-4.1.36.Final.jar ApplicationKt
Error: Could not find or load main class ApplicationKt
Process finished with exit code 1
I noticed the module's output path is not included in the -classpath option. How should I fix it?
Here's what I did:
Create new Gradle project with no additional libraries and frameworks using IntelliJ IDEA
Add new Android module
Add new Multiplatform module
Add new Ktor module
Define main method as shown in the Ktor quick start
If you follow these steps, then I'm pretty sure you'll face the same problem. I'm working on Ubuntu 18.04 just in case.
project structure:
hello
├── android
├── common
├── server
│ ├── resources
│ └── src
│ └── Application.kt
├── build.gradle
└── settings.gradle
settings.gradle in root project:
include ':android', ':common', ':server'
build.gradle in root project:
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath("com.android.tools.build:gradle:3.4.1")
classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.40")
}
}
allprojects {
repositories {
google()
jcenter()
}
}
It seems like a bug, not just a problem. I found a temporary workaround from JetBrains issue tracker.
In IntelliJ IDEA, Go to "Settings / Build, Execution, Deployment / Build Tools / Gradle / Runner" and check the "Delegate IDE build/run actions to Gradle" option as true and it'll work correctly.
(related to add standard libraries to RPATH for build tree executables)
I have the following directory structure as minimal working example
.
├── baz.cc
├── baz.h
├── CMakeLists.txt
└── sub
├── CMakeLists.txt
└── foo.cc
sub is in practice a git submodule and should not be edited for my specific corner case but remain generic.
sub/CMakeLists.txt defines a test that does not run in my setup because a shared library is not added to the RPATH by cmake. To reproduce this behavior, it can be thought be
enable_testing()
add_executable(foo foo.cc)
set_property(TARGET foo PROPERTY SKIP_BUILD_RPATH TRUE)
target_link_libraries(foo ${CMAKE_CURRENT_BINARY_DIR}/../libbaz.so)
include_directories(..)
add_test(NAME footest COMMAND foo)
(foo.cc can be:
#include "baz.h"
int main() {
return bazinga() - 42;
}
let's assume a shared library with the bazinga symbol will always be available, e.g. from /usr/lib)
My top level CMakeLists.txt is
add_subdirectory(sub)
add_library(baz SHARED baz.cc)
I want to get the footest running by manipulating its LD_LIBRARY_PATH as suggested here. This would be by adding
set_tests_properties(footest PROPERTIES ENVIRONMENT "LD_LIBRARY_PATH=/path_where_libbaz.so_is_on_my_target_system")
This line does the job when I add it to sub/CMakeLists.txt, but fails with the following error when I edit the top level CMakeLists.txt
CMake Error at CMakeLists.txt:3 (set_tests_properties):
set_tests_properties Can not find test to add properties to: footest
given the above reason, I want to do the fixup without editing anything in the subdirectory.
Is there a way to set properties of tests that are defined in other directories than the current one?
I have a spring boot 1.5.1 project that uses profile properties file. In my /src/main/resources I have all my properties files
When using IntelliJ 2016.3.4 I set the
Run Configuration | Active Profile
to "local" and run it. I see this in the console:
The following profiles are active: local
But there is a value in the property file
data.count.users=2
and used as:
#Value("${data.count.users}")
private int userCount;
that is not being picked up and thus causing the error:
Caused by: java.lang.IllegalArgumentException: Could not resolve
placeholder 'data.count.users' in string value "${data.count.users}"
However, if I run this via gradle
bootRun {
systemProperty 'spring.profiles.active', System.properties['spring.profiles.active'] }
as
gradle bootRun -Dspring.profiles.active=local
then everything starts up using the local profile as expected. Can anyone see why this is not being properly picked up? In IntelliJ Project Structure I have my /src/main/resources defined as my Resource Folders.
UPDATE:
Adding screenshot of Configuration:
I could be wrong here but it doesn't look like the spring.profiles.active environment variable is actually set in your configuration, regardless of what you've selected as your Active Profile. This may be a bug with IntelliJ.
However, setting the environment variable in Run -> Edit Configurations definitely works for me.
Pease add Spring facet to your Spring Boot module to get full support
Is classpath of module heimdall the correct one, i.e. does it contain the shown resources folder with your application.properties?
If this doesn't help, please file a minimum sample project reproducing the exact structure of your project in our bugtracker, there are too many variables to investigate https://youtrack.jetbrains.com/issues/IDEA.
Using -Dspring.config.location in VM options in IntelliJ helped me.
-Dspring.config.location=file:/C:/Users/<project path>/src/main/resources/application-dev.properties
This could also be due to a non-standard configuration setup, for instance:
src/main/resources
├── application.properties
├── config1
│ ├── application-dev.properties
│ ├── application-prod.properties
│ ├── application.properties
│ └── logback-spring.xml
├── config2
│ ├── application-dev.properties
│ ├── application-prod.properties
│ ├── application.properties
│ └── logback-spring.xml
└── config3
├── application-dev.properties
├── application-prod.properties
├── application.properties
└── logback-spring.xml
This can be solved by passing using the parameters logging.config & spring.config.name for logback & spring respectively. For the above example:
java -jar \
-Dspring.profiles.active=dev \
-Dlogging.config=classpath:config1/logback-spring.xml \
-Dspring.config.name=application,config1/application \
target/my-application.0.0.1.jar
Here root application.properties is used, overridden by config1/application.properties, overridden by config1/application-dev.properties. The parameters (environment variables) can be specified in IDEA's run configuration in VM Options.
As far as advanced IDE support (highlighting, completion etc.) is concerned, there is an open issue for complex/custom configuration setups: IDEA-180498
I have a shared Windows8.1 project with a Phone and Desktop project in it. I defined different configurations to build x86/x64 for desktop and ARM for phone.
msbuild works fine without error, but there is no final *.appxbundle file on the output folder (or anywhere else) although i set the parameter AppxBundle=Always.
my command looks like this:
msbuild myApp.sln /p:OutputPath=%OUTPATH%;Configuration=Phone;Platform=ARM;AppxBundle=Always;AppxBundlePlatforms=ARM
/t:Rebuild,Publish
The output is:
OUTPATH
├── ForBundle
│ └── AppxManifest.xml
├── AppxManifest.xml
├── App.WindowsPhone.build.appxrecipe
├── App.WindowsPhone_3.2.1_ARM.appx
├── App.WindowsPhone_3.2.1_scale-100.appx
├── App.WindowsPhone_3.2.1_scale-140.appx
├── App.WindowsPhone_3.2.1_scale-180.appx
├── resources.pri
└── SomeDependency.winmd
I tried to pack this folder with makeappx.exe bundle but this didn't work and I realized the folder looks a bit different to what is into a appxbundle.
Creating a appxbundle via VS GUI is no problem, but I would like to automate that step!
Thanks in advance!
There's a hint comment in Microsoft.AppXPackage.Targets:
When building on the command line or in TFS (determined by looking at the $(BuildingInsideVisualStudio) property), if build is
invoked on an
app package-producing project, the package for the project will be produced as part of building the project without specifying
any additional
flags or targets. This is control by an MSBuild property named GenerateAppxPackageOnBuild which is set to true by default.
If $(BuildingInsideVisualStudio) = false and $(GenerateAppxPackageOnBuild) = true, then build will also produce a
package.
true
FYI, the file has moved for VS 2022, new location isL
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VisualStudio\v17.0\AppxPackage