Dokka uses fully qualified class names - kotlin

I'm using dokka to auto generate javadoc for me. Though when it encounters any class not from my project it uses fully qualified names.
Is it possible to use only class names and make dokka provide a link for it? For example:
java.lang.String getName()
I'd want instead of java.lang.String to have String with link to Java doc
My gradle config:
ext.simpleName = project.name.substring(project.name.indexOf('-') + 1, project.name.size())
dokka {
outputFormat = 'javadoc'
outputDirectory = "${rootProject.buildDir}/javadoc/$project.ext.simpleName"
linkMapping {
dir = 'src/main/java'
url = "https://github.com/mibac138/ArgParser/blob/master/$project.ext.simpleName/src/main/java"
}
linkMapping {
dir = 'src/main/kotlin'
url = "https://github.com/mibac138/ArgParser/blob/master/$project.ext.simpleName/src/main/kotlin"
}
}
Also, what exactly is linkMapping? I'm not sure what it does.

For linking to 3rd party libraries you should use externalDocumentationLink pointing to Oracle Java documentation:
dokka{
externalDocumentationLink {
url = new URL("https://docs.oracle.com/javase/8/docs/api/")
}
If you use Kotlin and Java in the same project fully qualified names for Java classes may be necessary

Related

Kotlin Room DB Export schemas

class RoomSchemaArgProvider(
#get:InputDirectory
#get:PathSensitive(PathSensitivity.RELATIVE)
val schemaDir: File
) : CommandLineArgumentProvider {
override fun asArguments(): Iterable<String> {
// Note: If you're using KSP, you should change the line below to return
// listOf("room.schemaLocation=${schemaDir.path}")
return listOf("-Aroom.schemaLocation=${schemaDir.path}")
}
}
I need to Export old db schema in json. I wanted to use the above code if any one used this as per https://developer.android.com/training/data-storage/room/migrating-db-versions#export-schemas please help me with the same.
i tried to use as per this https://developer.android.com/training/data-storage/room/migrating-db-versions#export-schemas
problem faced during testing migration. hence i need this solution.
java.io.FileNotFoundException: Cannot find the schema file in the assets folder. Make sure to include the exported json schemas in your test assert inputs. See https://developer.android.com/training/data-storage/room/migrating-db-versions#export-schema for details. Missing file: com.sboxnw.freeplay.data.database.SugarBoxDatabase/2.json
at androidx.room.testing.MigrationTestHelper.loadSchema(MigrationTestHelper.java:484)
at androidx.room.testing.MigrationTestHelper.createDatabase(MigrationTestHelper.java:238)
at com.sboxnw.freeplay.DownloadMigrationTest.testAllMigrations(DownloadMigrationTest.kt:72)
I need to Export all old db json schema for migration testing .
It is failing due to src path not define correctly. You can add source path directly in defaultConfig of build.gradle
javaCompileOptions {
annotationProcessorOptions {
arguments = ["room.schemaLocation": "$projectDir/schemas".toString()]
}
}

kotest change environment variables

I am writing tests for Ktor app using Kotests, but stumbled into the problem how can I change env variables for tests preferably globally. I have tried adding withEnvironment but it throw quite strange error into me
Unable to make field private final java.util.Map java.util.Collections$UnmodifiableMap.m accessible: module java.base does not "opens java.util" to unnamed module #3daa422a
java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.util.Map java.util.Collections$UnmodifiableMap.m accessible: module java.base does not "opens java.util" to unnamed module #3daa422a
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
my test file looks like this
class VisitorSpec : FreeSpec({
val ds = createDataSourceTest()
val visitor = RegisterVisitorDTO(
email = TestConstants.VISITOR_EMAIL,
username = TestConstants.VISITOR_USERNAME,
password = TestConstants.PASSWORD,
firstName = TestConstants.VISITOR_FIRST_NAME,
lastName = TestConstants.VISITOR_LAST_NAME,
gender = TestConstants.VISITOR_GENDER,
birthday = TestConstants.VISITOR_BIRTHDAY,
)
"check visitor routes" - {
val loginData = LoginDTO(TestConstants.VISITOR_EMAIL + 0, TestConstants.PASSWORD)
"can get list of visitors with correct query" {
withEnvironment(
mapOf(
"POSTGRES_URL" to "jdbc:postgresql://localhost:5432/test",
"POSTGRES_USERNAME" to "test_user",
"POSTGRES_PASSWORD" to "test_pass"
)
) {
testApplication {
val client = getClient(ds)
repeat(6) {
registerConfirmedUser(
client, visitor.copy(
email = "${TestConstants.VISITOR_EMAIL}$it",
username = "${TestConstants.VISITOR_USERNAME}$it",
)
)
}
val accessToken = loginUser(client, loginData).run { this.body<LoginResponseDTO>().accessToken }
client.get("/api/v1/visitors?page=1&count=5") {
header("Authorization", "Bearer $accessToken")
}.apply {
val response = this.body<VisitorPaginatedResponseDTO>()
response.data.size.shouldBe(5)
response.totalCount.shouldBe(6)
response.currentPage.shouldBe(1)
}
}
}
}
...
if I remove
withEnvironment(
mapOf(
"POSTGRES_URL" to "jdbc:postgresql://localhost:5432/test",
"POSTGRES_USERNAME" to "test_user",
"POSTGRES_PASSWORD" to "test_pass"
)
)
it will just work but with default db, any advice on this?
In some places, it was advised to use
override fun listeners() = listOf(
SystemEnvironmentTestListener("fooKeyEnv", "barValueEnv"),
SystemPropertyTestListener("fooKeyProp", "barValueProp")
)
but ide tells me that this method is deprecated.
Thanks in advance for any advice.
Recent Java versions prohibit modifying the environment variables with the default access settings (JEP 403: Strongly Encapsulate JDK Internals). Kotest and some other testing frameworks that manipulate the environment variables got affected by this, you can find the related issues:
https://github.com/kotest/kotest/issues/2849
https://github.com/stefanbirkner/system-lambda/issues/23
https://github.com/junit-pioneer/junit-pioneer/issues/509
One solution would be to add the arguments to the JVM running the tests that would make the Java Platform Module System allow the access to the API used by the test framework. Here's an answer that explains the arguments: How to set environment variable in Java without 'illegal reflective access'? How to use add-opens?
The simplest form of the argument, if you are not using Java modules in your code, would be:
--add-opens java.base/java.util=ALL-UNNAMED
If you are running the tests using Gradle, then you can pass this argument to the jvmArgs of the test task:
tasks.withType<Test>().named("jvmTest") {
jvmArgs("--add-opens", "java.base/java.util=ALL-UNNAMED")
}
Note: modifying the module access in this way could make the tests pass even if some of your code needs illegal access to the JDK internals. Make sure that your code doesn't do that or that you have other tests that check for this without modifying module access rights.
It seems that some other libraries, like system-stubs, provide a way to modify the environment variables in tests without illegal reflective access to the JDK internals.

Kotlin Cinterops native library name

I'm using cinterops to link a dynamic library in a mingw binary executable. Everything is working fine, except that the .dll name that the executable asks is different from the one declared at the .def file.
I don't know where this different name is coming from!
This is from my gradle.build.kts:
mingwX86("mingw"){
compilations["main"].cinterops{
val scape2 by creating {
val cafmSrc = "C:/Software/SCAP E2/CAFM_src"
val scapSrc = "C:/Software/SCAP E2/TO/ETME2"
val modifiedSrc = "C:/Software/SCAP E2/Modified CAFM files"
includeDirs.headerFilterOnly(cafmSrc, scapSrc, modifiedSrc)
extraOpts.add("-verbose")
}
}
binaries {
executable()
}
}
This is my scape2.def file:
headers = scape2.h
headerFilter = scape2.h \ GEO_API_SCAPTO.h
linkerOpts.mingw = -LC:/Users/lscarmin/git/calculation-module4 -lscape2
I was expecting that the dll name to be scape2.dll.
But when I run the executable, it asks for ETME2.dll!
If I rename scape2.dll to ETME2.dll, the code works. (editado)
Well, it seems that the file name used is the one defined inside the dll. I have renamed the dll file, but the name used will be the original one.
I didn't know that this info was kept inside the dll

Setting the version number for .NET Core projects

What are the options for setting a project version with .NET Core / ASP.NET Core projects?
Found so far:
Set the version property in project.json. Source: DNX Overview, Working with DNX projects. This seems to set the AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion unless overridden by an attribute (see next point).
Setting the AssemblyVersion, AssemblyFileVersion, AssemblyInformationalVersion attributes also seems to work and override the version property specified in project.json.
For example, including 'version':'4.1.1-*' in project.json and setting [assembly:AssemblyFileVersion("4.3.5.0")] in a .cs file will result in AssemblyVersion=4.1.1.0, AssemblyInformationalVersion=4.1.1.0 and AssemblyFileVersion=4.3.5.0
Is setting the version number via attributes, e.g. AssemblyFileVersion, still supported?
Have I missed something - are there other ways?
Context
The scenario I'm looking at is sharing a single version number between multiple related projects. Some of the projects are using .NET Core (project.json), others are using the full .NET Framework (.csproj). All are logically part of a single system and versioned together.
The strategy we used up until now is having a SharedAssemblyInfo.cs file at the root of our solution with the AssemblyVersion and AssemblyFileVersion attributes. The projects include a link to the file.
I'm looking for ways to achieve the same result with .NET Core projects, i.e. have a single file to modify.
You can create a Directory.Build.props file in the root/parent folder of your projects and set the version information there.
However, now you can add a new property to every project in one step by defining it in a single file called Directory.Build.props in the root folder that contains your source. When MSBuild runs, Microsoft.Common.props searches your directory structure for the Directory.Build.props file (and Microsoft.Common.targets looks for Directory.Build.targets). If it finds one, it imports the property. Directory.Build.props is a user-defined file that provides customizations to projects under a directory.
For example:
<Project>
<PropertyGroup>
<Version>0.0.0.0</Version>
<FileVersion>0.0.0.0</FileVersion>
<InformationalVersion>0.0.0.0.myversion</InformationalVersion>
</PropertyGroup>
</Project>
Another option for setting version info when calling build or publish is to use the undocumented /p option.
dotnet command internally passes these flags to MSBuild.
Example:
dotnet publish ./MyProject.csproj /p:Version="1.2.3" /p:InformationalVersion="1.2.3-qa"
See here for more information: https://github.com/dotnet/docs/issues/7568
Not sure if this helps, but you can set version suffixes at publish time. Our versions are usually datetime driven, so that developers don't have to remember to update them.
If your json has something like "1.0-*"
"dotnet publish --version-suffix 2016.01.02" will make it "1.0-2016.01.02".
It's important to stick to "semvar" standards, or else you'll get errors. Dotnet publish will tell you.
Why not just change the value in the project.json file. Using CakeBuild you could do something like this (optimizations probably possible)
Task("Bump").Does(() => {
var files = GetFiles(config.SrcDir + "**/project.json");
foreach(var file in files)
{
Information("Processing: {0}", file);
var path = file.ToString();
var trg = new StringBuilder();
var regExVersion = new System.Text.RegularExpressions.Regex("\"version\":(\\s)?\"0.0.0-\\*\",");
using (var src = System.IO.File.OpenRead(path))
{
using (var reader = new StreamReader(src))
{
while (!reader.EndOfStream)
{
var line = reader.ReadLine();
if(line == null)
continue;
line = regExVersion.Replace(line, string.Format("\"version\": \"{0}\",", config.SemVer));
trg.AppendLine(line);
}
}
}
System.IO.File.WriteAllText(path, trg.ToString());
}
});
Then if you have e.g. a UnitTest project that takes a dependency on the project, use "*" for dependency resolution.
Also, do the bump before doing dotnet restore. My order is as follows:
Task("Default")
.IsDependentOn("InitOutDir")
.IsDependentOn("Bump")
.IsDependentOn("Restore")
.IsDependentOn("Build")
.IsDependentOn("UnitTest");
Task("CI")
.IsDependentOn("Default")
.IsDependentOn("Pack");
Link to full build script: https://github.com/danielwertheim/Ensure.That/blob/3a278f05d940d9994f0fde9266c6f2c41900a884/build.cake
The actual values, e.g. the version is coming from importing a separate build.config file, in the build script:
#load "./buildconfig.cake"
var config = BuildConfig.Create(Context, BuildSystem);
The config file looks like this (taken from https://github.com/danielwertheim/Ensure.That/blob/3a278f05d940d9994f0fde9266c6f2c41900a884/buildconfig.cake):
public class BuildConfig
{
private const string Version = "5.0.0";
public readonly string SrcDir = "./src/";
public readonly string OutDir = "./build/";
public string Target { get; private set; }
public string Branch { get; private set; }
public string SemVer { get; private set; }
public string BuildProfile { get; private set; }
public bool IsTeamCityBuild { get; private set; }
public static BuildConfig Create(
ICakeContext context,
BuildSystem buildSystem)
{
if (context == null)
throw new ArgumentNullException("context");
var target = context.Argument("target", "Default");
var branch = context.Argument("branch", string.Empty);
var branchIsRelease = branch.ToLower() == "release";
var buildRevision = context.Argument("buildrevision", "0");
return new BuildConfig
{
Target = target,
Branch = branch,
SemVer = Version + (branchIsRelease ? string.Empty : "-b" + buildRevision),
BuildProfile = context.Argument("configuration", "Release"),
IsTeamCityBuild = buildSystem.TeamCity.IsRunningOnTeamCity
};
}
}
If you still want to have the Solution Level SharedVersionInfo.cs you can do it by adding these lines to your project.json file:
"buildOptions": {
"compile": {
"includeFiles": [
"../../SharedVersionInfo.cs"
]
}
}
Your relative path may vary, of course.
use external version.txt file with version, and prebuild step to publish this version in projects

eclipse RCP UI through java code

Can I implement Eclipse RCP UI using java code only and not plugin.xml?
While it might be possible in theory (eclipse plugins are OSGi bundle which are read by the extension registry), I don't think it is practical (unless you re-implement the extension registry lifecycle).
Eclipse Equinox precisely extends the concept of bundles with the concept of extension points, hence the mandatory presence of plugin.xml.
You can programmatically add and remove extensions. See following example methods (adapt on demand):
public void addExtension() throws UnsupportedEncodingException {
String pluginXmlAsString = "<a string with the content of plugin.xml";
InputStream pluginXmlIs = new ByteArrayInputStream(pluginXmlAsString.getBytes(StandardCharsets.UTF_8.name()));
IExtensionRegistry extensionRegistry = Platform.getExtensionRegistry();
Object token = ((ExtensionRegistry) extensionRegistry).getTemporaryUserToken();
IContributor contributor = ContributorFactoryOSGi.createContributor(Platform.getBundle("org.acme.mybundle"));
extensionRegistry.addContribution(pluginXmlIs, contributor, false, null, null, token);
}
public static void removeExtensionsContributedByMe() {
String extensionPointId = "<ID of the extension point for remove an extension of";
String extensionContributor = "org.acme.mybundle";
ExtensionRegistry extensionRegistry = (ExtensionRegistry) Platform.getExtensionRegistry();
IExtensionPoint extensionPoint = extensionRegistry.getExtensionPoint(extensionPointId);
IExtension[] extensions = extensionPoint.getExtensions();
Object token = extensionRegistry.getTemporaryUserToken();
for (IExtension extension : extensions) {
if (extensionContributor.equals(extension.getContributor().getName())) {
extensionRegistry.removeExtension(extension, token);
}
}
}
We use this for unit tests which add extensions as preparation and remove extension to clean up. This way the tests do not influence each other (which would be the case if the extensions are "hard coded" in plugin.xml or fragment.xml).