[mac] bundled universalJavaApplicationStub is not correct EOL

[umjammer]

I'm submitting a…

• bug report
• feature request
• other

Short description of the issue/suggestion:

an app created by javapackager plugin doesn't work.

Steps to reproduce the issue/enhancement:

1. create pom.xml
2. mvn package -Dmaven.test.skip=true
3. click the application created

What is the expected behavior?

the application works.

What is the current behavior?

mac said "cannot open the application"

Do you have outputs, screenshots, demos or samples which demonstrate the problem or enhancement?

$ target/Notificator/Notificator.app/Contents/MacOS/universalJavaApplicationStub
zsh: target/Notificator/Notificator.app/Contents/MacOS/universalJavaApplicationStub: bad interpreter: /bin/bash^M: no such file or directory
$ dos2unix target/Notificator/Notificator.app/Contents/MacOS/universalJavaApplicationStub
dos2unix: converting file target/Notificator/Notificator.app/Contents/MacOS/universalJavaApplicationStub to Unix format...
$ target/Notificator/Notificator.app/Contents/MacOS/universalJavaApplicationStub                                                                                                                                     1.2.1
Hello World!

after dos2unix, the application works.
provided universalJavaApplicationStub's EOL is wrong.

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• JavaPackager version: 1.6.7
• OS version: macos 11.6.6
• JDK version: 1.8.0_291
• Build tool:
  • Maven
  • Gradle

Other information (e.g. related issues, suggestions how to fix, links for us to have context)

[fvarrui]

Hi @umjammer!

I'm sorry ... I fear I reintroduced an old issue 😞

On the one hand, there's a new feature in version 1.6.7 that allows you to select the binary/script used to start the application (macConfig.macStartup=SCRIPT|UNIVERSAL|X86_64|ARM64). On the other hand, there's a problem when releasing the plugin to Maven Central from Windows, whereby line breaks in resource files are replaced by \r\n.

What does one thing has to do with the other?

When adding the new feature, I forgot to have in mind replacing line breaks when choosing SCRIPT option, as in 1.6.6:

JavaPackager/src/main/java/io/github/fvarrui/javapackager/packagers/MacPackager.java

Lines 113 to 123 in dd2fa51

	// copies universalJavaApplicationStub startup file to boot java app
	File appStubFile = new File(macOSFolder, "universalJavaApplicationStub");
	FileUtils.copyResourceToFile("/mac/universalJavaApplicationStub", appStubFile, true);
	FileUtils.processFileContent(appStubFile, content -> {
	if (!macConfig.isRelocateJar()) {
	content = content.replaceAll("/Contents/Resources/Java", "/Contents/Resources");
	}
	content = content.replaceAll("\\$\\{info.name\\}", this.name);
	return content;
	});
	appStubFile.setExecutable(true, false);

Last param is unixStyleNewLines=true:

FileUtils.copyResourceToFile("/mac/universalJavaApplicationStub", appStubFile, true); 

This replaces \r\n with \n.

And right now, in 1.6.7, this is done so:

JavaPackager/src/main/java/io/github/fvarrui/javapackager/packagers/MacPackager.java

Lines 112 to 122 in edd95e5

	// copies universalJavaApplicationStub startup file to boot java app
	File appStubFile = new File(macOSFolder, "universalJavaApplicationStub");
	String universalJavaApplicationStubResource = null;
	switch (macConfig.getMacStartup()) {
	case UNIVERSAL: universalJavaApplicationStubResource = "universalJavaApplicationStub"; break;
	case X86_64: universalJavaApplicationStubResource = "universalJavaApplicationStub.x86_64"; break;
	case ARM64: universalJavaApplicationStubResource = "universalJavaApplicationStub.arm64"; break;
	case SCRIPT: universalJavaApplicationStubResource = "universalJavaApplicationStub.sh"; break;
	}
	FileUtils.copyResourceToFile("/mac/" + universalJavaApplicationStubResource, appStubFile);
	appStubFile.setExecutable(true, false);

Notice the missing third parameter when copying the resource.

Yes!!! I know, I should add unit tests to the plugin, but I haven't had time 😢

[fvarrui]

A possible work around could be to use macConfig.macStartup=UNIVERSAL|X86_64|ARM64 instead of SCRIPT.
Please, try this and give us some feedback. Thanks!!!

[umjammer]

macConfig.macStartup=X86_64

works fine!

but i intend to wait patiently this issue will be resolved 👍

[fvarrui]

Fixed in devel branch (JavaPackager 1.7.0-SNAPSHOT).

[umjammer]

1.7.0-SNAPSHOT

works well!

thanks 😄

[jzy3d]

Thank you, I also got this problem. However when running with 1.7.0-SNAPSHOT on {macOS11.4, Apple M1, Azul JDK 11}, running mvn clean package throws

[ERROR] Failed to execute goal io.github.fvarrui:javapackager:1.7.0-SNAPSHOT:package (default) on project quantum: Could not remove folder 
/Users/martin/Dev/jzy3d/external/quantum/target/Quantum/Quantum.app/Contents/PlugIns/jre/Contents/Home/legal: Unable to delete directory 
/Users/martin/Dev/jzy3d/external/quantum/target/Quantum/Quantum.app/Contents/PlugIns/jre/Contents/Home/legal.

Thanks in advance!

[fvarrui]

Hi @jzy3d!
There seems to be a bug with commons-io:commons-io:2.7, which has been fixed in 2.11.0. I've just upgraded this dependency in branch issue-239. Please, could you try the fix and give some feedback? Thanks!

[jzy3d]

Thank you a lot for your prompt reply @fvarrui. I confirm that using branch issue-239 resolve the above failure.
And now I get the EOL problem solved!
Congratulation and thank you so much for your work.

[fvarrui]

Great!!! Branch issue-239 merged into devel, ready to be released in v1.7.0. Thanks!!

[fvarrui]

JavaPackager 1.7.0 released to Maven Central