Skip to content

Conversation

@koppor
Copy link
Contributor

@koppor koppor commented Nov 17, 2025

Fixes #69

Please guide how to test

gradle publishToMavenLocal

results in

* What went wrong:
Could not read PGP secret key
> unable to decode base64 data: invalid characters encountered at end of base64 data

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.

BUILD FAILED in 1s
Configuration cache entry discarded due to serialization error.
20:53:46: Execution finished 'publishToMavenLocal'.

@jjohannes
Copy link
Member

Thanks for contributing this @koppor!

You can publish locally by running with -Psigning.disable. The unable to decode... error is caused by the setup trying to sign the artifacts.

Alternatively, you can add pluginManagement { includeBuild("<path-to-this-repo-clone") } to the settings.gradle.kts of the project you want to test this in. Then the plugin will be built and used from source.

@jjohannes jjohannes added this to the 1.2 milestone Nov 18, 2025
@koppor
Copy link
Contributor Author

koppor commented Nov 18, 2025

Thank you for the hints @jjohannes. I think, I got that part working.

Now, I am stuck at jlink

  jlink --output C:\git-repositories\jabref\jabgui\build\packages\windows-latest\JabRef\runtime --module-path C:\\git-repositories\\jabref\\jabgui\\build\\libs\\jabgui-100.0.0.jar;C:\\git-repositories\\jabref\\jabls\\build\\libs\\jabls.jar;C:\\git-repositories\\jabref\\jabsrv\\build\\libs\\jabsrv.jar;C:\\git-repositories\\jabref\\jablib\\build\\libs\\jablib.jar;C:\\Users\\olive\\.gradle\\caches\\modules-2\\files-2.1\\com.dlsc.gemsfx\\gemsfx\\3.6.2\\7530fad8f71cc6230ccc62ec28ba04111ed583b8\\gemsfx-3.6.2.jar;C:\\Users\\olive\\.gradle\\caches\\modules-2\\files-2.1\\

Is this JDK or which tool is executing that statement?

grafik

UPDATE - seems to be another issue

[09:36:43.741] Can not find WiX tools. Was looking for WiX v3 light.exe and candle.exe or WiX v4/v5 wix.exe and none was found
[09:36:43.741] Download WiX 3.0 or later from https://wixtoolset.org and add it to the PATH.
Error: Invalid or unsupported type: [msi]

@koppor
Copy link
Contributor Author

koppor commented Nov 18, 2025

@jjohannes Thank you for the hint - seems to work -> JabRef/jabref#14124

@koppor koppor marked this pull request as ready for review November 18, 2025 11:13
@koppor
Copy link
Contributor Author

koppor commented Nov 18, 2025

Error in the tests - only on Windows - maybe, someone has a quick idea how to fix

JavaModulePackagingResourcesTest > can_add_resources_for_jpackage() FAILED
    org.gradle.testkit.runner.UnexpectedBuildFailure at JavaModulePackagingResourcesTest.java:99

@jjohannes
Copy link
Member

jjohannes commented Nov 18, 2025

The tests on Windows are flaky. They sometimes run out of memory. I have to look into that but it is unrelated to this PR.

The failure on Windows is:

The parameter is incorrect.	
java.io.IOException: Command [light.exe, -nologo, -spdb, -ext, WixUtilExtension, -out, C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage12588292048692662514\images\win-exe.image\app-1.0.msi, -sice:ICE27, -loc, C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage12588292048692662514\config\MsiInstallerStrings_en.wxl, -cultures:en-us, C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage12588292048692662514\wixobj\main.wixobj, C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage12588292048692662514\wixobj\bundle.wixobj, C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage12588292048692662514\wixobj\ui.wixobj] in C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage12588292048692662514\images\win-msi.image\app exited with 263 code

Scan

Copy link
Member

@jjohannes jjohannes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the change is good as it is. As the existing tests show that this does not break any functionality, I don't think we need to add additional tests.

I was wondering if there should be other conditions for not using the argsFile file (like if the modulePathAsPath is short).
But I also like to avoid such complexity in the code if it is not necessary.

…java

Co-authored-by: Jendrik Johannes <jendrik.johannes@gmail.com>
Copy link
Member

@jjohannes jjohannes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The build is working now. I assume the weird message we got on Windows (see comment above) was caused by the broken fallback if an IOExcpetion occurs. (And the exception itself was caused by the flakiness in the test.)

@jjohannes jjohannes merged commit 61755c5 into gradlex-org:main Nov 18, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use an args file when command line exceed operating system limits for jpackage

2 participants