Refactor CreateDmg and BundleMacosJdk: use Property<..>, migrate to Kotlin

[vlsi]

fixes #69

The PR includes the following changes:

• Use Gradle's Property API so the tasks support lazily generated inputs. For instance, jdk dependency is downloaded only in case the task is actually executed
• Migrate to Kotlin
• File.createTempDir is replaced with build directory to better conform with Gradle conventions
• README cleanup: added Kotlin DSL samples, fixed that JDK dependency requires .zip rather than .tgz
• Added cleanTemporaryDirectories option for debugging purposes (if set to false it would skip removing the temporary directories used for preparing the output artifact)
• Added integration test to verify CreateDmg and BundleMacosJdk tasks

[vlsi]

The createDmg test passes locally, however it fails in GitHub Actions :(

arch: posix_spawnp: perl5.18: Bad CPU type in executable

[arimer]

Hello Vladimir. Thanks for contributing! 🎉
Do you mind adding a short discription to this PR to just sumup your idea. This is mostly useful for documentation purposes and might help others during code review.

[vlsi]

@arimer , well, I thought It was summarized in the PR title. I duplicated it to the description as well.

[arimer]

Thanks a lot for this contribution I have still some open questions and points which are commented on the code.

[arimer]

Due the switch to the property API users of this plugins would face problems if they encode a version like 1.4.+ in their project setup.
Therefore I would opt for at least increase the minor verion in L.24.

[arimer]

Maybe @coolya or @sergej-koscejev have an other oppinion.

[vlsi]

Frankly speaking, the version is puzzling here, so I need your input here.
Of course, I can bump minor version to 5

[arimer]

I really like the idea of having a common super class 👍

[arimer]

I really like the idea having a minimal RCP test which can be executed.
Could you maybe just drop some lines in the readme about the test idea and the setup?
This would be great and could help others in the future to update/enrich the test if required.

[vlsi]

I'm puzzled here. Can you please clarify what is not clear?

I'm using a standard approach to use Gradle plugins: org.gradle.testkit.runner.GradleRunner
The test creates Gradle project within a temporary directory and executes a single task there.

[sergej-koscejev]

I can't give a good review on this because I don't use these tasks, they run on our build server to produce a DMG for mbeddr RCP and either they work properly or nobody seems to care about DMGs. I also don't understand if there's a particular problem that this PR is supposed to solve.

@vlsi do you intend to maintain these tasks in the future? Have you had problems with these tasks?

Otherwise I'm tending against merging this PR because I'd like to avoid fixing what isn't broken.

[sergej-koscejev]

Sorry, I overlooked that this fixes #69. In that case let's merge this, but please bump version to 1.5 as @arimer mentioned.

[vlsi]

@sergej-koscejev , sorry for the delay. I've rebased the PR and I bumped the version.

Do you think it can be merged?

[sergej-koscejev]

I can't merge it because the macOS builds fail. @vlsi any idea why?

[vlsi]

macOS builds fail

I think the build fails since macOS scripts are outdated (see #99)
However, I was not sure if that is GitHub's issue or if the scripts went out of date indeed.

[vlsi]

So I guess the ways to proceed are:

• temporarily skip macOS from build matrix (or mark it to ignore errors)
• update macOS scripts

WDYT?

[sergej-koscejev]

I'm fine with updating the macOS scripts. @coolya do you have any opinion?

[coolya]

I'm fine with updating the macOS scripts. @coolya do you have any opinion?

I'm fine with updating the files.

[vlsi]

Well, I did check the scripts from JetBrains, and it looks like they are worse than the scripts in mps-gradle-plugin :((
They use positional arguments instead of named ones, they hard-code certain assumptions (e.g. JetBrains, .png suffix, and so on).

As far as I understand, there's no point in building .dmg without bundling JDK. Java evolves at extreme pace nowadays, so it looks like the only sane way to release MPS-based IDEs (and .dmg in particular) is to bundle the workable JRE right into the distribution.

generic.zip might be helpful, however, it looks like "always bundle JRE" is the way to go for macOS, Windows, Linux.

So I suggest:

1. update mps-gradle-plugins to accommodate macOS notarization
2. heal somehow the Perl failure (e.g. borrow the relevant bits from JetBrains Platform)
3. drop bundleJdk task altogether and let createDmg do everything (create the dmg with jre inside and sign it). An alternative option is to split createDmg (basically avoid shell scripts) into smaller tasks (perform "create dmg", "sign", "notarize" in different Gradle tasks), however, it would probably require more effort, and the gains are not obvious.

WDYT?

[sergej-koscejev]

@vlsi I'm fine with all your suggestions, I just don't want to be the one to do this.

Yes, there's no point in building a .dmg without a JDK because the JetBrains JDK contains some improvements that help their IDEs work properly. The IDEs might crash or misbehave on a standard JDK, AFAIK.