release bug - When packaging server with app into uber jar extensions folder is not included in the final deployment

[doychin]

We try to create uber jar for one war file and we use maven to do that
mvm package-server fails to include the additional extensions we add in the directory of the application where it is deployed before it is packaged into uber jar.

This is a behavior we see with open liberty 18.0.0.3

[scottkurz]

@doychin it looks like you are using the liberty-maven-plugin to package your app and server, and you are having a packaging issue.

We use the WASdev/ci.maven repository to track issues with our maven plugin. You can open a new issue here. It would help to include a pom.xml sample (or snippet).

Thank you.

[hlhoots]

Looks like this might be in the server package command. Kernel team will investigate as soon as possible.

[hlhoots]

@doychin Would you be able to give us an example of the problem? Maybe a snapshot of the directory structure, and a snapshot of what is missing from the package.

[doychin]

Hi, You can check this repository
https://github.com/bgjug/microprofile-hol-1x
It contains Hands On Lab for microprofile. One of the projects (content) is based on Open Liberty.

There is an issue open for that problem in that repository.
bgjug/microprofile-hol-1x#10

[hlhoots]

@doychin
Thanks for that info!

Do you know what package "include" options were used in your pom file? Assuming you might have used the default of 'all' but wanted to check before digging deeper into the issue.

https://github.com/WASdev/ci.maven/blob/master/docs/package-server.md

[doychin]

It is not my project. I think everything is by default. Problem is that extensions are not included in the final fat jar. These are downloaded and extracted before packaging. If application is started without trying to build fat jar everything works properly. Liberty sees zipkin extension.

…

On Wed, May 8, 2019, 16:51 Harry L. Hoots, III ***@***.***> wrote: @doychin <https://github.com/doychin> Thanks for that info! Do you know what package "include" options were used in your pom file? Assuming you might have used the default of 'all' but wanted to check before digging deeper into the issue. https://github.com/WASdev/ci.maven/blob/master/docs/package-server.md — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5881 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABWNBE2BNGV62NIKKVIJCPDPULLHNANCNFSM4GHEF2AQ> .

[hlhoots]

Hi @doychin --

After some troubleshooting and talking with @scottkurz it looks like it is not the OL package command that is the causing the issue but a mismatch in the pom.xml between the userDirectory and the installDirectory. The user and install directories have to be aligned so that the extension you are installing is in the directory structure where the Liberty package command occurs. So what is happening is that the zipkin feature is being installed into the /liberty folder:

<groupId>com.googlecode.maven-download-plugin</groupId> -> <outputDirectory>${project.build.directory}/liberty/wlp/usr</outputDirectory>

And the userDirectory and assemblyInstallDirectory (where the package happens) doesnt match:

<groupId>net.wasdev.wlp.maven.plugins</groupId> -> <userDirectory>${project.build.directory}</userDirectory>
and
<groupId>net.wasdev.wlp.maven.plugins</groupId> -> <assemblyInstallDirectory>${project.build.directory}</assemblyInstallDirectory>

The package command will only pickup things from the folder in which it is executed, thus with the extension in /liberty and the package happening on /wlp the /extensions folder is missing from the content.jar file.

So the package seems to work as expected with these changes - please give them a try and see if they will work properly for your project (note the values all end in /liberty):

<groupId>com.googlecode.maven-download-plugin</groupId> -> <outputDirectory>${project.build.directory}/liberty</outputDirectory> <groupId>net.wasdev.wlp.maven.plugins</groupId> -> <userDirectory>${project.build.directory}/liberty</userDirectory> <groupId>net.wasdev.wlp.maven.plugins</groupId> -> <assemblyInstallDirectory>${project.build.directory}/liberty</assemblyInstallDirectory>

By the way, the copy-resources goal should also align with the user directory(which looks like it is correct in the /liberty folder):

<artifactId>maven-resources-plugin</artifactId> -> <outputDirectory>${project.build.directory}/liberty/wlp/usr/servers/${serverName}/resources/security</outputDirectory>

[hlhoots]

Hi @doychin - any updates on that suggestions above for resolution?

[doychin]

Hi Harry, I've forwarded your comments to the author of the workshop project but at the moment me and him we are busy with other things and can't look at it right now. I'll try to look at your suggestions next week.

…

-- Doychin Bondzhev

[hlhoots]

Sounds good - Thanks!

[doychin]

Hi Harry,
I treid your suggestions and it really worked.
thanks.