I'm trying to write a maven plugin with kotlin DSL that creates a configuration object. The plugin will depend on that configuration during its operation.
I think I need to use the DSL like following: in runtime load a separate file with kotlin script, execute it and assign result to a variable in the plugin code.
Is there any good way to do it?
It turns out there is a simple answer:
https://github.com/JetBrains/kotlin/blob/master/libraries/examples/kotlin-jsr223-local-example/
Related
Seems name refactoring not that easy in Karate framework. I tried in both IntelliJ and VSCode
Could you please suggest some workaround for same
Eg: If I am calling a feature file at multiple places and in case I want to rename it I would need to rename explicitly file name wherever it has been used.
Yes this is a limitation of the existing plugins. The official IntelliJ plugin has JSON validation and this feature is planned, but not yet released: https://plugins.jetbrains.com/plugin/19232-karate
Is there a way to add a piece of top level KDoc for a Kotlin file?
Since Kotlin supports multiple variables, functions, classes, etc. in a single file, it makes sense to document the file as a whole. However, Documenting Kotlin Code - Kotlin Programming Language seems not to have any instructions on this.
There's no such feature; however, packages and modules can be documented like in Java
In Dokka, additional documentation files are added with include property (e.g. Gradle configuration).
Following https://docs.gradle.org/current/userguide/java_testing.html#sec:configuring_java_integration_tests and https://www.michael-bull.com/blog/2016/06/04/separating-integration-and-unit-tests-with-gradle we are attempting to separate our integration tests from plain unit tests.
The problem we have is internal members in Kotlin are not accessible from such tests. As per Kotlin doco there is a visibility exception for test source sets.
The internal visibility modifier means that the member is visible
within the same module. More specifically, a module is a set of Kotlin
files compiled together:
an IntelliJ IDEA module;
a Maven project;
a Gradle source set (with the exception that the test source set can access the internal declarations of main);
a set of files compiled with one invocation of the Ant task.
Is there a way around it other than not trying to access them? That would call for a major refactoring of hundreds of tests and potentialy the whole codebase.
I was able to get a custom test sourceSet to access internal classes by adding the following code to my custom Gradle plugin.
NamedDomainObjectContainer<KotlinWithJavaCompilation<KotlinJvmOptions>> compilations = project
.getExtensions()
.getByType(KotlinJvmProjectExtension.class)
.target.getCompilations();
compilations.getByName(sourceSet.getName())
.associateWith(compilations.getByName(SourceSet.MAIN_SOURCE_SET_NAME));
I looked at the kotlin-gradle-plugin source code and found the following:
https://github.com/JetBrains/kotlin/blob/v1.3.61/libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/plugin/KotlinPlugin.kt#L488-L490
With change, the tests in my custom source set run just fine, but IntellIJ still shows compilation errors. I'll look further to see if I can make IntelliJ happy as well
I use InteliJ to run JUnit tests.
I would like to specify the name/path of the command it uses to execute them. Specifically, rather than the specified JDKs/bin/java, I'd like to use a custom command (e.g. my_java).
My particular reason is that I'd like my_java to be a small script that launches "java" at a lower priority. If there is an alternate approach, that would be just as useful.
I reached out to JetBrains and asked them directly. According to them, specifying a custom binary is "not possible". They did suggest I look at writing a custom external tool.
I wonder what is the Maven way in my situation.
My application has a bunch of configuration files, let's call them profiles. Each profile configuration file is a *.properties file, that contains keys/values and some comments on these keys/values semantics. The idea is to generate these *.properties to have unified comments in all of them.
My plan is to create a template.properties file that contains something like
#Comments for key1/value1
key1=${key1.value}
#Comments for key2/value2
key2=${key2.value}
and a bunch of files like
#profile_data_1.properties
key1.value=profile_1_key_1_value
key2.value=profile_1_key_2_value
#profile_data_2.properties
key1.value=profile_2_key_1_value
key2.value=profile_2_key_2_value
Then bind to generate-resources phase to create a copy of template.properties per profile_data_, and filter that copy with profile_data_.properties as a filter.
The easiest way is probably to create an ant build file and use antrun plugin. But that is not a Maven way, is it?
Other option is to create a Maven plugin for that tiny task. Somehow, I don't like that idea (plugin deployment is not what I want very much).
Maven does offer filtering of resources that you can combine with Maven profiles (see for example this post) but I'm not sure this will help here. If I understand your needs correctly, you need to loop on a set of input files and to change the name of the output file. And while the first part would be maybe possible using several <execution>, I don't think the second part is doable with the resources plugin.
So if you want to do this in one build, the easiest way would be indeed to use the Maven AntRun plugin and to implement the loop and the processing logic with Ant tasks.
And unless you need to reuse this at several places, I wouldn't encapsulate this logic in a Maven plugin, this would give you much benefits if this is done in a single project, in a unique location.
You can extend the way maven does it's filtering, as maven retrieves it's filtering strategy from the plexus container via dependency injection. So you would have to register a new default strategy. This is heavy stuff and badly documented, but I think it can be done.
Use these URLs as starting point:
http://maven.apache.org/shared/maven-filtering/usage.html
and
http://maven.apache.org/plugins/maven-resources-plugin/
Sean