If you omit the full package names in a KMP project is there a way to have the java code built with prefixing the full package. For example if you used "package mypackage" can the java code be built as if you used "package com.example.mypackage"?

No, I don't think it's possible, it would create a lot of edge cases. What is your use case for it?

Minor issue is to not have the warning "Package directive doesn't match the file location" because kotlin doesn't require the full path /com/example/mypackage but more importantly when using kotlin JS to have a more simplified naming structure since it requires the fully qualified name to access any class. Java needs full package name but JS is better without it.

Java doesn't need full package, it's not a requirement, you can use mypackage as package name with no problems

@gildor How to specify the package prefix for the IDE? I am not finding it on the page you linked.

@louiscad https://www.jetbrains.com/help/idea/content-roots.html#assign_package_prefix

I was about to use it, and I realized that there's no longer any warning regarding package mismatch if the path after

src/main/kotlin

is contained in the end of the package directive. Happy about it, because the idea-ext Gradle Plugin expected Groovy consumers and I didn't like the boilerplate it was leaving in the Kotlin DSL build files.

It's not only about warning, this setting also needed for some IDE actions such as create new files in the package or move files, otherwise it would create dirs for your root project Though it also can be just set to idea settings (which also can be shared)

Ah yes, I notices moving files was not nice… I think I'll make a buildSrc function to hide the boilerplate

I use only standard maven layouts everywhere, tried non standard only once, getting rid of a few folders doesn't worth all those issues with non-standard configs and strange ide behavior

I hope @elizarov words will lead to action landing in Kotlin 1.5: https://twitter.com/relizarov/status/1305414701552209921?s=19 It seems there's already groundwork as the behavior of the package directive warning infers the base package, and triggers warnings if there's any inconsistency, but fades back away if the root package is consistent with all the files in the hierarchy. IDE refactorings is the only missing part I think.