Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Liberty server tasks blow away jvm.options #786

Closed
five-iron opened this issue Nov 10, 2022 · 11 comments · Fixed by #787
Closed

Liberty server tasks blow away jvm.options #786

five-iron opened this issue Nov 10, 2022 · 11 comments · Fixed by #787

Comments

@five-iron
Copy link

#513 causes a delete of jvm.options and other configs during liberty tasks. What I guess we're supposed to do is to set up jvmOptions or jvmOptionsFile in the liberty.server block in build.gradle, or create a jvm.options in the config folder. This a problem for me because if you don't have these options set, then your server's jvm.options just gets deleted when running any liberty server gradle tasks. I'd rather just have the server's jvm.options persist instead.

Is this intended? If so, can we add an option to not delete the deployed jvm.options?

@cherylking
Copy link
Member

@five-iron If you mean the jvm.options in the build folder where the Liberty server got created gets deleted, then the answer is yes it is intended. The jvm.options should come from either the build.gradle configuration or a config file under source config folder. If you mean something else, please respond with more details.

@five-iron
Copy link
Author

Yeah I think you've captured what I'm saying. My setup right now doesn't use a build folder for creating a server, I'm pointing to a preinstalled location, so the path looks like this: C:\liberty_install_loc\wlp\usr\servers\defaultServer\jvm.options.

How hard would it be to prevent gradle from touching this file altogether (or at least when those jvmOption-related configs are not set, so as to not blow away the deployed file)?

@cherylking
Copy link
Member

cherylking commented Nov 10, 2022

@five-iron I see. So I can understand why you wouldn't want it deleted from a pre-installed Liberty, but we have nothing built into the code to prevent that from getting deleted. The problem is our plugin will not know if that file was pre-existing or came from our plugin configuration on a previous run. Perhaps we can have some special logic if the user is pointing to a pre-installed Liberty, then leave the files as is unless plugin configuration is specified currently. I will discuss with my team.

@five-iron
Copy link
Author

@cherylking Do you know when this could get released / when the next regular deployment cycle might be?

@cherylking
Copy link
Member

@five-iron We typically wait for more fixes to go in, but it is not a problem for me to do a minor fix release if this is important for your forward development/work. Let me see if I can fit this in my schedule tomorrow or early next week.

@five-iron
Copy link
Author

Don't sweat it if you can't fit in, it's not a blocker for us just a minor annoyance.

@cherylking
Copy link
Member

Ok, thanks. I went ahead and create a snapshot if you want to give it a try. Are you familiar with how to pull in snapshots from Sonatype?

@five-iron
Copy link
Author

Hm no I am not familiar with that. I tried searching maven.org but can't find snapshots anywhere for liberty-gradle-plugin.

@cherylking
Copy link
Member

@five-iron The [readme](Liberty Tools helps you quickly a) has a small bit on using snapshots. The version would be 3.5.2-SNAPSHOT.

@five-iron
Copy link
Author

Thanks I was able to download the snapshot and verify that it works as intended.

@cherylking
Copy link
Member

@five-iron Published release 3.5.2 this afternoon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants