Generate metadata for reflection on method parameters #415
Conversation
|
Thanks @basil ! Released it. Jenkins POM is also in progress |
| @@ -95,6 +95,9 @@ | |||
| <scmTag>HEAD</scmTag> | |||
| <!-- Where to put temporary files during test runs. --> | |||
| <surefireTempDir>${project.build.directory}/tmp</surefireTempDir> | |||
|
|
|||
| <!-- Generate metadata for reflection on method parameters --> | |||
| <maven.compiler.parameters>true</maven.compiler.parameters> | |||
There was a problem hiding this comment.
Is there a reason you did not do this in <configuration> of the plugin? Is there some expectation that some plugins would want to opt out?
There was a problem hiding this comment.
Is there a reason you did not do this in
<configuration>of the plugin?
Is there a reason I should have?
Is there some expectation that some plugins would want to opt out?
No expectation of that, but I thought it best to provide an escape hatch should this cause some unexpected problem.
There was a problem hiding this comment.
Is there a reason I should have?
Just generally better style to typed configuration that is explicitly scoped to a particular mojo, unless there is a specific expectation that the property will be overridden sometimes.
There was a problem hiding this comment.
Is there an action item for me here?
There was a problem hiding this comment.
OK, I'll take this as a note for future work then. I'm happy to redo this if you think there is a need, but right now it seems good enough.
See jenkinsci/stapler#226 and the Maven documentation. Once widely adopted, this would allow us to use reflection rather than ASM in Stapler for discovering method parameters. To test this change, I verified that a plugin was not able to access method parameters via reflection with the current plugin parent POM but was able to access them from a plugin parent POM with these changes. I also verified that plugins can opt out of this functionality if desired by setting
maven.compiler.parameterstofalsein their<properties>section.