Maven 2 & 3

[regression] Help plugin does not work

Details

  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

The following command:

mvn help:describe -Dplugin=site

Gives the error:

[ERROR]

Maven encountered an error while configuring one of the mojos for your build.

Mojo:
Group-Id: org.apache.maven.plugins
Artifact-Id: maven-help-plugin
Version: 2.0.2
Mojo: describe
brought in via: Direct invocation

While building project:
Group-Id: org.apache.continuum
Artifact-Id: continuum-docs
Version: 1.2-SNAPSHOT
From file: /Users/brett/scm/continuum/continuum/continuum-docs/pom.xml

Here is the configuration it attempted to apply to the mojo:<configuration>
<artifactId>$

{artifactId}

</artifactId>

<full>$

{full}

</full>

<groupId>$

{groupId}

</groupId>

<localRepository>$

{localRepository}

</localRepository>

<medium>$

{medium}

</medium>

<mojo>$

{mojo}

</mojo>

<output>$

{output}

</output>

<plugin>$

{plugin}

</plugin>

<project>$

{project}

</project>

<session>$

{session}

</session>

<settings>$

{settings}

</settings>

<version>$

{version}

</version>
</configuration>

Error message:org.codehaus.plexus.component.configurator.ComponentConfigurationException: Invalid parameter supplied while setting 'org.apache.maven.plugin.MojoExecution@a2f216' to org.apache.maven.plugins.help.DescribeMojo.setMojo( java.lang.Class )

Issue Links

depends upon

Bug - A problem which impairs or prevents the functions of the product. MNG-4312 Magic expressions injected by PluginParameterExpressionEvalutor conflict with expressions used by plugins to access system properties

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Task - A task that needs to be done. MNG-4259 Create a new name for the current PluginManager and create a backward compatible PluginManager implementation in maven-compat which delegates to the new implementation

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jason van Zyl added a comment -

This is due to two separate issues. The first is that the plugin expression evaluator wasn't processing command line properties first and there is a field in the help plugin called "plugin" which interferes with the field in the plugin descriptor configuratino called "plugin". The command line was being processed first so this wasn't a problem anymore. The plugin plugin should block field names/setters that are the same as elements in the default plugin descriptor.

The second problem is that the plugin manager and lifecycle executor have been changed so much that most of the methods the help plugin needs are no longer there. The help:describe mojo is a chunk of core logic in a plugin. Something like this could probably be way smaller and in the embedder which would be useful to IDE integration pieces.

Show
Jason van Zyl added a comment - This is due to two separate issues. The first is that the plugin expression evaluator wasn't processing command line properties first and there is a field in the help plugin called "plugin" which interferes with the field in the plugin descriptor configuratino called "plugin". The command line was being processed first so this wasn't a problem anymore. The plugin plugin should block field names/setters that are the same as elements in the default plugin descriptor. The second problem is that the plugin manager and lifecycle executor have been changed so much that most of the methods the help plugin needs are no longer there. The help:describe mojo is a chunk of core logic in a plugin. Something like this could probably be way smaller and in the embedder which would be useful to IDE integration pieces.
Hide
Permalink
Benjamin Bentmann added a comment -

The trunk of the Help Plugin seems to work to a reasonable degree with 3.x. The last released version of the plugin bypassed interface abstractions and made assumptions about the underlying implementation, that's just a no go. We should get into the habbit of discussing problems and use cases that plugin authors experience on the dev list to see how this can eventually be solved with proper help of the core. All this code using implementation classes is just prone to break.

Show
Benjamin Bentmann added a comment - The trunk of the Help Plugin seems to work to a reasonable degree with 3.x. The last released version of the plugin bypassed interface abstractions and made assumptions about the underlying implementation, that's just a no go. We should get into the habbit of discussing problems and use cases that plugin authors experience on the dev list to see how this can eventually be solved with proper help of the core. All this code using implementation classes is just prone to break.

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Brett Porter
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: