Investigate use of consistent LMP version internally from Boost when called by liberty:dev goal

[scottkurz]

Assuming OpenLiberty/ci.maven#530 is merged, when liberty-maven-plugin:dev (LMP) calls boost:package then boost will internally use its own version of LMP internally in the calls it makes via mojo-executor to liberty-maven-plugin.

Until we've proven otherwise, it would seem this could create problems. E.g. what if the wrong version of a Mojo is loaded by Boost.

We should investigate this more.

[cherylking]

Since LMP is calling the boost plugin, it seems like it could pass along the necessary info about itself so that boost could use the same version of LMP.

[scottkurz]

UPDATE: I played around a bit and at least don't see that there is any kind of fundamental problem with loading multiple versions of LMP in the liberty:dev:v1 -> boost:package -> liberty:package:v2 sequence. I was able to load mojos from the correct, distinct versions in a path like this.

Also, noticing that ci.common hosts the ServerFeatureUtil and that each of the two LMP versions in this path will use this with static methods, I put a static init in ServerFeatureUtil and built two test LMP versions using two distinct ci.common versions (modifying the static init in ServerFeatureUtil). I saw that, correctly, each respective use of ServerFeatureUtil ran the static init for the correct version.

So it seems the question is simply: which version of LMP do we want to use from Boost? Do we want it to be:

• one that boost hard codes (as it does today, potentially different from the liberty:dev LMP version)
• the one used to invoke liberty:dev?
• another one specified by the user?

But it's not as if there is a huge problem with how it works today

So will leave this open to investigate.