@Parameter in Abstract classes in other library are ignored

[jmini]

Given a lib project containing sample.lib.AbstactNameMojo:

package sample.lib;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugins.annotations.Parameter;

public abstract class AbstactNameMojo extends AbstractMojo {

  @Parameter(property = "name")
  private String name;

  public String getName() {
    return name;
  }
}

And a plugin (using 'de.benediktritter.maven-plugin-development' version '0.3.1') containing a Mojo extending the abstract one.

package sample.plugin;

import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.Mojo;
import org.apache.maven.plugins.annotations.Parameter;
import sample.lib.AbstactNameMojo;

/**
 * Says "Hi" to the user.
 */
@Mojo(name = "sayhi")
public class GreetingMojo extends AbstactNameMojo {

  @Parameter(property = "greeting")
  private String greeting;

  public String getGreeting() {
    return greeting;
  }

  @Override
  public void execute() throws MojoExecutionException {
    getLog().info("GreetingMojo: " + getGreeting() + " " + getName());
  }
}

The generated metadata do not contains the name information.

Therefore when the plugin will be used, Maven will only configure greeting and name will always stay null.
This can be observed when running maven with -X.

By inspecting the file META-INF/maven/plugin.xml in the generated jar, we see the issue:

<?xml version="1.0" encoding="UTF-8"?>

<!-- Generated by maven-plugin-tools 3.6 -->

<plugin>
  ...
  <mojos>
    <mojo>
      <goal>sayhi</goal>
      ...
      <parameters>
        <parameter>
          <name>greeting</name>
          <type>java.lang.String</type>
          <required>false</required>
          <editable>true</editable>
          <description></description>
        </parameter>
      </parameters>
      <configuration>
        <greeting implementation="java.lang.String">${greeting}</greeting>
      </configuration>
    </mojo>
  </mojos>
  <dependencies>
    ...
  </dependencies>
</plugin>

If the abstract class is in the same project (not in an other lib) it is working as expected, the generated META-INF/maven/plugin.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>

<!-- Generated by maven-plugin-tools 3.6 -->

<plugin>
  ...
  <mojos>
    <mojo>
      <goal>sayhi</goal>
      ...
      <parameters>
        <parameter>
          <name>greeting</name>
          <type>java.lang.String</type>
          <required>false</required>
          <editable>true</editable>
          <description></description>
        </parameter>
        <parameter>
          <name>name</name>
          <type>java.lang.String</type>
          <required>false</required>
          <editable>true</editable>
          <description></description>
        </parameter>
      </parameters>
      <configuration>
        <greeting implementation="java.lang.String">${greeting}</greeting>
        <name implementation="java.lang.String">${name}</name>
      </configuration>
    </mojo>
  </mojos>
  <dependencies>
    ...
  </dependencies>
</plugin>

Other file META-INF/maven/<groupId>/plugin/plugin-help.xml is wrong as well.

[jmini]

My reproducer for this issue can be found here:
https://github.com/jmini/gradle-sandbox/tree/master/issue73-maven-plugin

[britter]

I've pushed a reproducer test here: 1130a30 Now I just need to figure out what's going on and fix it :)

[britter]

This one is going to be tricky to fix. It looks like I need to pass the mojo project's compile dependencies to the maven mojo scanning infrastructure. Not sure when I will have the time look into this.

[britter]

The problem seems to be in how JavaAnnotationsMojoDescriptorEtractor.execute extracts the mojoAnnotatedClasses via it's scanAnnotation(PluginToolsRequest) method. The resulting map is later on used to look up parameters from parent classes and the parent class from another project does not end up in that map. Hence the plugin code has to be changed in a way that the scanning finds the parent class.

[jmini]

I really appreciate your efforts, I had a very quick look at the code and I know this is not a PR I can work on (I do not have the bandwidth to understand what is going on and how to change it)

[britter]

@jmini no worries. I'm just writing this down here as a reminder for myself 🙂

I think it's possible to make this work for dependencies that are build from the same project. It's going to be difficult to implement for external dependencies where the mojo base class is coming from an artifact from an internal repository. The reason being that Maven plugin tools make requests to download the sources jar and the whole infrastructure to do that simply can not be bootstrapped in context of my plugin. But I will try to find a way to make it work for project dependencies at least.

[britter]

I think I found a fix and pushed that to a84a395. It still needs some polishing and testing but it looks promissing.

[britter]

@jmini could you please try if version 0.4.0 fixes the problem for you? Note that extraction only work for project dependencies, but not for exterenal dependencies. So I hope the mojo base class is in one of the modules of the same build.