Request for plugin to recognize predefined (built in) server config variables like "server.config.dir"

[bwa]

Using liberty-maven-plugin 3.3.3.

When running liberty:dev goal I can see a error. This is a reference in server.xml

[DEBUG] (org.codehaus.mojo.pluginsupport.ant.AntHelper) Copying C:\Users\bwa.KLP\.m2\repository\no\klp\kundeside-authorisation-service-ear\2.26-SNAPSHOT\kundeside-authorisation-service-ear-2.26-SNAPSHOT.ear to C:\dev\git2\notifications-service\kundeside-notifications-service-rest\target\liberty\wlp\usr\servers\defaultServer\lib\kundeside-authorisation-service-ear.ear

[INFO] copyDependencies copied file kundeside-authorisation-service-ear-2.26-SNAPSHOT.ear to location C:\dev\git2\notifications-service\kundeside-notifications-service-rest\target\liberty\wlp\usr\servers\defaultServer\lib/kundeside-authorisation-service-ear.ear.

[debug] Variable server.config.dir cannot be resolved.
[info] The variables referenced by location ${server.config.dir}lib/eaw-ear.ear cannot be resolved.

It seems to not fail anything, but appear in the dev goal. The source of this use of the variable is server.xml. I'm also starting an another application copied to the lib directory with copy dependencies.

snippet from server.xml:

    <enterpriseApplication    
            id="eaw-ear" 
            name="eaw-ear"       
            location="${server.config.dir}lib/eaw-ear.ear">
            >
            <classloader apiTypeVisibility="spec, ibm-api, api, third-party" commonLibraryRef="db2lib">
                <privateLibrary>
                    <folder dir="${shared.config.dir}/dev_classpath"></folder>      
                </privateLibrary>
            </classloader>
    </enterpriseApplication>     

[cherylking]

When you mention copy dependencies, do you mean the copyDependencies parameter provided by the liberty-maven-plugin? If so, can you please share the parts of your pom.xml that are using copyDependencies? The copyDependencies configuration parameter was meant for copying true dependencies for an application (such as a database driver). So I am confused why it is being used to copy ear applications.

Also, I think there should be a / after the reference to ${server.config.dir} similar to how you have one after the reference to ${shared.config.dir}.

[bwa]

@cherylking Yes, it's the copyDependencies, because I'm utilizing the maven version range to always get the latest version of a additional ear copyed to the lib folder, and hence hardcoding the location of the ear.

If I add use ${server.config.dir}/lib/eaw-ear.ear, the result is a double // ... so that's another 'bug' ...

[cherylking]

Ah, interesting about the double //. But can you share more of your pom.xml including the copyDependencies, or maybe a sample project for reproducing?

[bwa]

the copyDependencised with strip version makes me able to start all the dependent applications of the currrent war module. Both upstream and downstream....

Not what you may created it for, but it is really awesome if I want to fire up a simple war and add all the rest for a bigger application in a easy way with just a mvn -Pliberty command.

[bwa]

I'll, create a sample project for the whole world to see this neat feature ...

[scottkurz]

Hi @bwa, just wanted to note that if you read the "copyDependencies" documentation you'll see that the location used can be:

.. a path relative to the target server configuration directory.

So if you had intended to express:

<copyDependencies>
    ...
   <location>${server.config.dir}lib/eaw-ear.ear</location>

you could simply do:

<copyDependencies>
    ...
   <location>lib/eaw-ear.ear</location>

Maybe that answers your question?

[bwa]

Hi @scottkurz Actually everything do works in my projects, but the error message should be looked into. It should not happen. Can be a wrong message ,

[scottkurz]

I see, @bwa .. sorry for not having understood, and thanks for explaining a second time. You're using copyDependencies to deploy application binaries.

I'm not sure if we've considered this type of usage.. Since an application location is usually relative to the server's apps directory, it's not typical to need an absolute path and apparently the plugin doesn't honor the standard Liberty built-in server variables on this attribute, on this element, and issues a warning.

You mentioned "dependent" applications which is sounding like more of a multi-module use case. We are currently looking at doing some work with multi-module projects, and are gathering some thoughts under https://github.com/OpenLiberty/ci.maven/issues/697.

We would be interested to hear your thoughts there. Also, I see you also opened issue: https://github.com/OpenLiberty/ci.maven/issues/1078 which seems to have some overlap here as well.

It might be that adding more first-class multi-module support would be a better solution than just making a quick fix to the code to honor the built-in server.config.dir, which could still leave us with additional issues that might not work in this case, if our deploy logic doesn't fully handle it.

[bwa]

@scottkurz Not exactly. https://github.com/OpenLiberty/ci.maven/issues/1078 is about having plugin config in the parent project, and only additions config in current (child) project. There the liberty plugin does not execute the same as maven plugins in general. If multiple executions are detected, the migth be executed both ... And demostrated very well in https://github.com/bwa/openliberty-maven-plugin-multimodule/tree/master/parent ...

And it's not multi module project either. It's more about multiple project. Small differens in naming, but big difference in reality.

[scottkurz]

Thinking about this more ... maybe this would be worth tackling by first simply constraining the scope to copyDependencies and no more (e.g. not worry about install locations). To keep the discussion going I added a draft PR. Will look to add more properties a bit later.

[scottkurz]

Since there were some other points brought up in the beginning of this issue, I'm going to leave this issue alone and opened new issue #1324, and linked my PR to that issue.

[scottkurz]

As mentioned in https://github.com/OpenLiberty/ci.maven/issues/1324#issuecomment-1049911160, because of the way Maven core resolves plugin parameter values, a parameter value that is entirely a property substitution like:

<location>${shared.resource.dir}</location>

will be difficult to enable with a function like this.

This could be worked around by appending a '/' to the end... but it does unfortunately mean that the most obvious usage (IMO), will only work when carefully reading the docs.

Otherwise, the #1324 PR would solve a good piece of this. @cherylking, any thoughts (when you get a chance)?