HelpMojo not getting doc strings

[hwbllmnn]

Hi,

I recently switched a Java maven plugin to Kotlin. It's mostly working, but the documentation strings are not being displayed in the generated HelpMojo. So I was happy to find this ;-) Unfortunately, it isn't working for me (see terrestris/i18n-maven-plugin#3 ). Is there some pitfall I'm not seeing? I thought I pretty much copied everything from your example pom.xml in the README.

Thanks, Andreas

[freemanjp]

I tried building your plugin but the parent POM isn't public so it failed. But I still have a couple of guesses as to what's causing the problem:

1. Kotlin source directory specified in Kotlin plugin config (rather than under Maven build)

i.e.

     <plugin>
        <groupId>org.jetbrains.kotlin</groupId>
        <artifactId>kotlin-maven-plugin</artifactId>
        ...
            <configuration>
              <jvmTarget>1.8</jvmTarget>
              <sourceDirs>
                <sourceDir>src/main/kotlin</sourceDir>
              </sourceDirs>

Rather than:

<build>
    <sourceDirectory>src/main/kotlin</sourceDirectory>

I think this is the most likely cause as it means the maven-plugin-plugin won't know where to find the Kotlin source files where the doc strings are.

2. Using val rather than lateinit var for injected properties

    @Parameter(defaultValue = "\${project}", required = true, readonly = true)
    private val project: MavenProject? = null

Instead of:

    @Parameter(defaultValue = "\${project}", required = true, readonly = true)
    private lateinit var project: MavenProject

While I prefer immutability and constructor injection with Kotlin, AFAIK you can't do that with Maven plugins, so lateinit var is the next best thing (notice how it allows you to specify the value as not null). Not sure whether this is the cause, but it's a significant difference to how I implemented my plugin (https://github.com/gantsign/ktlint-maven-plugin).

Hope that helps.

[hwbllmnn]

The nexus is lately acting up, the pom should actually be available, sorry.

The specification of the build sourceDirectory was indeed the culprit. It's working perfectly now, thanks! Also thank you for the lateinit pointers, it indeed feels cleaner this way.