Plans to update to Launch4j 3.50

TheBoegl / gradle-launch4j

A gradle-plugin to create windows executables with launch4j

Apache License 2.0

298 stars 40 forks source link

Plans to update to Launch4j 3.50 #144

Closed f-cramer closed 1 year ago

f-cramer commented 1 year ago

Launch4j 3.50 was released in late 2022 an includes some major improvements concerning path search. Unfortunately it also renamed multiple properties and changed path search to be the default instead of registry search. Are there any plans to upgrade to 3.50 or would a PR be welcome?

TheBoegl commented 1 year ago

This is definitely planned but I'm not sure how to adapt the configuration change in 3.50.

f-cramer commented 1 year ago

Aren't the changes mostly "remove this parameter" and "replace this parameter with this other one"? I made the changes described here in a fork and (at least for my single use case) it worked just fine.

TheBoegl commented 1 year ago

That's definitely an easy way to approach this, which will require a new major version as it's a breaking change or we try to deprecate and delegate to replacements with reasonable default values.

f-cramer commented 1 year ago

I don't think a plugin is really the place to provide backwards compatibility for features that were removed in the main product, is it? But I don't really know how this was handled for previous updates.

FritjofH commented 1 year ago

I have recently run into the same issues as @f-cramer with issues finding the java path since upgrading to java 17.

I think it would be worth to go for the path of least resistance for this, ie. new major release. Otherwise given the changes below, it wouldn't be that much to delegate and change, right? One thing is removed, and 3 are replaced.

Removed , path search is always first and registry search second in order to improve compatibility with modern runtimes.
Replaced and with which works during path and registry search.
Replaced with which works during path and registry search.
Replaced with .
and are now used during path and registry search, previously they were only checked during registry search.

I'll see if I can find a team member who could assist with this.

TheBoegl commented 1 year ago

I've spent the last few evenings trying to address this and other issues (#88 and #142) with a new version. Unfortunately some tests are still failing, but I'll stay on it and will hopefully finish the new release during the next few nights.

TheBoegl commented 1 year ago

@f-cramer, @FritjofH can you please verify that the latest development version 3.0.0-SNAPSHOT works for you?

FritjofH commented 1 year ago

@f-cramer, @FritjofH can you please verify that the latest development version 3.0.0-SNAPSHOT works for you?

Absolutely, will get on it this coming week. Thanks for your work!

mattiaslundstrom commented 1 year ago

I am working with @FritjofH and we have now tested the snapshot and it worked well for us.

Only change we had to do is that previously "icon" accepted a file as argument, but now it seems to require a string. After changing icon = theFile to icon = theFile.getAbsolutePath() it builds as expected in our environment.

As to whether launch4j 3.50 resolves all the original issues we had with JRE path resolution, this is still being tested.

@f-cramer, @FritjofH can you please verify that the latest development version 3.0.0-SNAPSHOT works for you?

Absolutely, will get on it this coming week. Thanks for your work!

TheBoegl commented 1 year ago

Thanks for your test, @mattiaslundstrom. I'd say that's expected behavior since the icon property as well as other "file-related" properties are defined as String.

I've run some more tests on a work-related project and will close this issue as everything seems to work here.

f-cramer commented 1 year ago

I have totally missed this. Just tried the update on one of our projects and it works perfectly. Thanks a lot