Question

I’m analyzing a Maven plugin that I can configure inside the configuration section of plugin:

<plugin>
     ...
     <executions>...</executions>
     <configuration>
         <!-- items placed here are visible to the MOJO -->
     </configuration>
</plugin>

The plugin completely ignores any configuration items for an execution, though:

<plugin>
     ...
     <executions>
         <execution>
             <id>execution1</id>
             <phase>test</phase>
             <goals><goal>test</goal></goals>
             <configuration>
                <!-- items placed here are ignored -->
             </configuration>
         </execution>
     </executions>
</plugin>

I run Maven with mvn test. I’m sure that the execution takes place, as Maven prints its id correctly, but the plugin is not configured — prints warnings about incorrect settings that are not present when the <configuration> section is moved outside of <executions>.

The question: is it the way the plugin is implemented, that it accepts only “top level” configuration? I’ve studied its source code and it seemed to me that it’s Maven that invokes setters on a MOJO class and it’s transparent to the plugin which section the options came from.

The MOJO is annotated with:

* @component
* @goal test
* @phase test
* @execute phase="jasmine-process-test-resources"

Answer 1

The plugin in question is forking a custom lifecycle.

The forked custom lifecycle will have the execution with the specified id (execution1) removed (as it is a forked lifecycle)

Thus any of the plugin’s goals that are performed by the forked lifecycle will be missing their configuration. The main mojo itself should be getting the configuration, but what is going wrong is the forked lifecycle executions.

I am guessing which plugin it is, if my guess is right, this is the custom lifecycle and the warnings you are seeing are coming from e.g. other mojos with text like

JavaScript source folder was expected but was not found. Set configuration property
`jsSrcDir` to the directory containing your JavaScript sources. Skipping 
jasmine:resources processing.

With a situation like this you will need to either put the <configuration> section in the outer block or configure the executions for the lifecycle.

Configuring the executions for the lifecycle will require adding executions with ids that are of the magic format. I am not 100% certain, but in your case you would be defining an additional execution with an ids of either default-resources or jasmine-lifecycle-resources in order to ensure that the configuration takes.

The less verbose way is just to put the configuration in the outer section and be done with it.