Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This draft PR is a result of many of my attempts at getting Maven to bind values from
pom.xml
to the Mojo@Parameter
annotated fields whileNativeExtension
is being run.Currently, the only way to access configuration values during extension time is to manually traverse the DOM tree. I strongly believe that this approach is fundamentally wrong and that there should be a better way - a 2 way binding between Mojo fields that are annotated as
@Parameter
and a correspondingString
value that is loaded from the effectivepom.xml
. IMO this was a prerequisite for #260 since the shear amount of nested parameters would soon become unmanageable.I tried to look up a way to utilize existing Maven internal code, however I was unable to decouple the parameter binding logic from the rest of the code. This effectively means that the only way forward is to reinvent the wheel.
My original idea then was to reflecively introspect the Mojos in order to lookup
Parameter
annotations and then use them to bind values from the plugin'sconfiguration
block to the Mojo fields. Unfortunately this doesn't work sinceRetention
parameter of the@Parameter
annotation is set toRetentionPolicy.CLASS
...Unfortunately this leaves only the hard way: simulate what Maven does by doing the following steps:
PluginDescriptor
and get a ParameterMap.private
fields are includedconfiguration
entries to the PluginDescriptorThe last point is problematic since annotated types can be generics, or even classes with nested parameters. In the
ExtensionTimeConfigurationUtility
you can find my attempt at tackling this without external dependencies.This is where I have ran out of time. This was a much bigger challenge than I originally anticipated.
IMO if somebody decides to properly solve this issue, the code for it should definitely be published as a standalone dependency (as opposed to some utility package in this plugin) as many plugins could benefit from it.
With this experience, as a path forward for solving #260 I suggest extracting
maven/config/agent
classes, integrating them into that new PR as dummy values, and proceeding to parse XML by hand. That is exactly what I wanted to avoid, but it is the only way to deliver this feature in real time (unless some Maven wizard creates some way to do what I attempted to implement).After fetching the values, following things should be done:
AgentConfiguration.getAgentCommandLine
in theNativeExtension
in order to configure the agent invocation.mvn native:metadataCopy
).None of these should be particularly difficult.
cc: @sdeleuze @alvarosanchez