Support late property resolution to allow easy jacoco agent integration

[bmarwell]

Dear Liberty-Maven-Plugin-Team!

Currently, the liberty-maven-plugin does not support the "very special" late property resolution.
With late property resolution, property can be defined as @{property} instead of ${property}.
Surefire and failsafe make use of them.

What is the use case?

Some plugins, for example jacoco, define the variables later in the build lifecycle. Jacoco will define (by default) a variable called <argLine>-javaagent:/path/to/.m2/org/jacoco/jacoco-agent-lib.jar</argLine>.
However, as ${} variables are resolved by maven before jacoco will be executed, Suerfire/Liberty would just see an empty variable (at best) or the maven build will fail due to an unset variable.
For this reason, @{} variables were introduced with late resolution.

This way we could define something like this:

<properties>
  <liberty.jvm.jacoco.argline>@{argLine}</liberty.jvm.jacoco.argline>
</property>

Currently, Liberty will write just a plain @{argLine} into the file jvm.options. Instead I would like to see the -javaagent: line.

Please implement @{} variables so we can easily integrate the jacoco agent.

Hint: Googling for "liberty-maven-plugin" "jacoco" does not yield any results.

[cherylking]

@bmarwell So would the argLine property value exist in the Maven Project properties at runtime? And we just need to recognize the @{xxx} syntax and resolve xxx before writing it to the jvm.options in your example?

[bmarwell]

Yup, here's the exact location:
https://github.com/apache/maven-surefire/blob/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/DefaultForkConfiguration.java#L219-L247

Now, before working on this: Is adding the jacoco agent even possible on Liberty? Has anyone ever tried that?

[cherylking]

Now, before working on this: Is adding the jacoco agent even possible on Liberty? Has anyone ever tried that?

No idea :-)

[scottkurz]

A quick search found this https://stackoverflow.com/questions/30740082/using-jacoco-with-liberty-profile-8-5-5-4-in-eclipse-does-not-produce-any-code-c but I'm not sure who's tried it more recently. That at least suggests there is some version of JaCoCo that once provided some value, working with some version of Liberty, but that's fairly old information and I don't know any more at this point either.

Can I ask too, for this use case, are we assuming that (assuming we added support for this resolution) you'd still need to run to actually run the jacoco plugin before the liberty plugin, during the same build? So for Liberty dev mode, you might have to run? :

mvn jacoco: liberty:dev

[bmarwell]

Can I ask too, for this use case, are we assuming that (assuming we added support for this resolution) you'd still need to run to actually run the jacoco plugin before the liberty plugin, during the same build? So for Liberty dev mode, you might have to run? :

mvn jacoco: liberty:dev

Hey,
I can try to add inclnolocationclasses=true (taken from the issue you linked).

I will also ty to add the agent argLine manually for now.

[cherylking]

@bmarwell Question: Do we only need to resolve the @{xxx} properties that are referenced in Maven properties? Or do we also need to handle them in the configuration parameters for the plugin (such as the jvmOptions parameter)?

Also, I presume we do not need to look for and resolve these types of references within config files specified by other parameters such as jvmOptionsFile. Correct me if I am wrong.

[bmarwell]

Huh. Good questions.

Do we only need to resolve the @{xxx} properties that are referenced in Maven properties? Or do we also need to handle them in the configuration parameters for the plugin (such as the jvmOptions parameter)?

I am pretty sure it would be confusing if they were NOT equivalent. So, I'd say yes: both the properties and jvmOptions parameter should support this. I.e. late resolution.

Also, I presume we do not need to look for and resolve these types of references within config files specified by other parameters such as jvmOptionsFile.

I think this is not needed. So far and as I know, late resolution is only implemented in maven's pom.xml itself (e.g. for the plugins surefire, jacoco, etc.).

[cherylking]

The 3.8.3-SNAPSHOT has been refreshed to include this functionality. See the doc update here.

[bmarwell]

@cherylking I forgot to say thanks -- works like a charm.

Here is an example how I use it:

• reserve a port using build-helper-maven-plugin, e.g. wiremock.port and liberty.port
• I start wiremock as a background process in pre-integrationtest on that port (no late binding needed)
• configure liberty application to use that port for requests, e.g. <liberty.env.APP_ENDPOINT_URL>https://localhost:@{wiremock.port}/</liberty.env.APP_ENDPOINT_URL>
• the plugin generates APP_ENDPOINT_URL=https://localhost:30142/ (or similar) in the server.env file, which is picked up by my application 😊
• be happy about an integration test which doesn't need external systems you do not control 🎉

This is especially useful when building on shared systems, i.e. without docker support.