MacOS用のLinuxアプリケーションバンドルでの構築方法について

そのため、最近、Java Swingで記述された1つのアプリケーションのビルドスクリプトを更新する機会がありました。 このアプリケーションは長い間開発されており、単一の世代のプログラマーによって書かれたわけではありませんが、その仕事は明確に行われているため、メインプラットフォーム(Window、Unix、MacOS)向けに組み立てられています。 そこで、MacOS用の古いアプリバンドルのアセンブリをアップグレードすると同時に、組み込みのjreバージョン1.8を組み込むことにしました。 そして、興味深いことが明らかになりました:古いバンドルはAppleのJava 6で構築され、今からは機能しませんでした。Info.plist形式は変更されました。Oracleはそのプロパティをより気に入っているため、古いJavaApplicationStubは今や違法で、長生きするJavaAppLauncherなど、多くの興味深いものがあります。 私は個人的にLinuxを好んでいます。たとえば、MacOSの愛好家は私を許してくれます。そして、このような馴染みのある端末コンソールでさえ、私の問題に打ち勝った同じ勇敢な人々の経験を求めてインターネットで長い試練を経た後、私の魂を弱く暖めました。 これはほとんど信じられないことですが、最終的に、David Clunieブログに記事を見つけました。彼はこの問題の解決策を見つけるための私のすべての試みを段階的に説明しました。 私はタックルを求めることに興味があります。オリジナルの愛好家はここにある切望された記事へのリンクです、私は私の翻訳の品質について事前に謝罪します、 彼は完全で文字通りではありません。



要約:

Javaアプリケーションを実行可能なMacバンドルにパックするのは複雑なプロセスではありませんが、時間の経過とともに変化します。 JavaApplicationStubはJavaAppLauncherファイルに置き換えられ、バンドルのコンテンツを簡単にアセンブルしてInfo.plistを手動で編集できますが、Info.plistのバンドルの構造とプロパティは変更されています。



Davidは長年MacとJavaのファンであり、開発におけるクロスプラットフォームアプローチが本当に好きで、私が大好きな端末コンソールも好みます。Xcodeはテキストエディタとしてのみ使用し、makeが大好きで、大規模なプロジェクトを構築するためにantを使用します彼は確かにアリがクールです。 デビッドは、これらすべてが時々彼のコードを読む人々を狂わせると思うが、それは人生だ。



上記のすべてにより、彼のかなり時代遅れのアプローチが、AppleとOracleからのJavaの変更に追いつくことが可能になります。 MacでのJavaアプリケーションの開発とデプロイは、大きな課題ではありません。 Davidは、私のように、Mac、Unix、Windowsの3つの主要なプラットフォームで動作するアプリケーションが必要です。



Mac用のアプリケーションを作成する方法が1つしかなかった場合、jarbundlerと呼ばれるAppleが提供するツールを使用します。 Jarbundlerは、 bundleにパッケージ化されたMacアプリケーション用の正しいファイルおよびフォルダー構造を作成しました。 各Macアプリケーションは、実際には「something.app」と呼ばれるフォルダーで、バイナリーの実行可能ファイルを含む、リソース、プロパティなどのさまざまなファイルで構成されています。 Oracleより前の時代、Appleが独自のバージョンのJavaを提供したとき、必要なバイナリはJavaApplicationStubであり、jarbundlerはアプリケーションの起動時にこのファイルが適切な場所にあると想定しています。 このトピックに関する古いドキュメントへのリンクを次に示します。



jarbundlerを使用してバンドルの正しいフォルダーとファイル構造を取得しようとしたことがあるので、使用を中止し、各新しいアプリケーションのファイルとフォルダーを適切な場所に手動でコピーし、Info.plistファイルを編集しました。 makefile内のこのような標準構造の更新を自動化するのは簡単でした。 私は仕事でApple-JRE固有のものをほとんど使用しなかったため、AppleがJREの配信を停止し、Oracleがそれを開始したとき、開発プロセスにはほとんど影響がありませんでした。 だから今、私はムーンフェイズに応じてOpenJDKの異なるバージョンを使用する習慣があり、それでもすべてがうまく機能しているようです。



他の誰かがこの古いサポートされていないバージョンのJREを使用したからという理由だけで、Davidは長い間Java 1.5のプロジェクトを作成しましたが、最終的には歯ぎしりしてバージョン1.7に切り替えました。 これは、Java 9(彼が既に実験した)がそのような古いターゲット用にコンパイルされなくなることを発見したとき、理にかなっているように見えました。 適切なjavacオプション(-target、-source、および-bootclasspath)を使用してさまざまな(重要な)警告を黙らせる短い実験の後、すべてが順調に進んでいるように見えました。



Java 1.7用にコンパイルされたjarファイルをMacバンドルにコピーして考え、Info.plistのJVMVersionプロパティの値を「1.5+」から「1.7+」に増やしてみませんか? その後、私のアプリケーションは動作しなくなり、「サポートされていないバージョン」というエラーに関する警告を発行しました。



この観点から、長年、 Mac Javaメーリングリストの appbundlerと呼ばれる新しいツールに関するすべての種類のメッセージを無視しました。Oracleの説明では、アプリケーションはインストールされたJREに依存しなくなりました。 受け入れ可能なJREの完全なコピーにリンクされています。



それから著者の少しの反射がありました、結果は彼がappbundlerの使用に切り替えたことです。 そのため、appbundlerの使用はantに依存しており、著者は通常使用しなかった(そして、私はそれを使用したので幸運でした)が、残念なことにantのappbundlerタスクはDavidが必要としていたJVMオプションをサポートしていませんでした。 以下は、appbundlerでサポートされているオプションの説明です。 ブログ記事の執筆時点(2014年10月)で、アバンドラーは少し時代遅れに見え、オラクルが積極的に開発していないことが明らかだったため、著者は少し心配していました。 他の人が積極的に保守しているアバンドラーの別のバージョンがあり、さらに多くのオプションがあり、その使用ははるかに複雑に見えます。 次に、Michael Hallの投稿がMac Java開発者のメーリングリストで見つかりました。Michaelによって書かれたツール、つまりAppConverterは 、古いアプリケーションを新しいアプリケーションに変換することが期待されていました(霧の多いbめきは申し訳ありませんが、Davidには何もありません)追加していません)。 必要なものを見つけたかのように聞こえました。 残念ながら、コンバーターを使用しようとしたときに、約束のとおり、変換されたアプリケーションがドラッグアンドドロップアプリケーションバンドルに応答しなかったことが判明しました。



一般に、AppConverterはDavidには役に立たなかったが、1つの例外を除いて、Davidはバンドルのコンテンツを調べ、これがJavaApplicationStubの代わりに使用されるバイナリJavaAppLauncher実行可能ファイルを含むJavaアプリケーションであることを確認しました。パッケージにはInfo.plistも含まれており、必要です。 すべてに加えて、現在「Contents / Resources / Java」フォルダのすべてのjarファイルが「Contents / Java」に移動していることが判明しました(Mac Java開発者メーリングリストの投稿で確認されましたが、個人的には、これは私にとって悪い決断です個人的に、Info.plistを介して必要なすべてのフォルダーをクラスパスに追加できたのはとても良かったです。たとえば、同じクラスの異なるパッケージと同じ名前のjarファイルがありますが、異なるフォルダーでは、古いバンドルでは、すべて機能しました完全に問題なく、クラスパスに追加されたすべてが1つの単位にコピーされるようになりました このフォルダーは、FOPの異なるバージョンのサポートを忘れてしまう可能性があります。たとえば、fop-0.20.jar; fop-1.0.jar; fop-2.0.jarのように、作業の追加に感謝します)。



そのため、DavidはInfo.plist構造を手動で少し編集し、AppConverterを使用した後に受け取ったバンドルからJavaAppLauncherをコピーし、完全に機能するアプリケーションを取得しました。 。



例として、古いアプリケーションバンドルの構造を次に示します(これが非常に残念です)。



画像



ここに新しいものがありますが、ここからはどこにも行けません:



画像



古いInfo.plistは次のとおりです。



画像



さて、比較のために、新しいもの:



画像



繰り返しますが、クラスパスに何も追加する必要はありません。JavaAppLauncher自体が、Contents / Javaフォルダーにあるすべてのものを自動的にクラスパスに追加します。



現在、すべてのjavaプロパティを共通のJavaタグの下に持つ代わりに、JavaAppLauncherはJava / MainClassの代わりにJVMMainClassNameプロパティを使用し、Java / VMOptionsの代わりにJVMOptionsを使用します。



Davidはさらに、アプリケーションバンドル、彼が使用したソフトウェアバージョン、およびアプバンドラーの作成者が古いバンドル構造とInfo.plistを使用できなかったことに対するinりについての彼のさらなる実験について説明します。 そして、この件に関する最新のドキュメントがあります。



追伸最初、DavidはアプリケーションバンドルにJREを埋め込むことに成功しませんでしたが、希望を失いませんでした。同様のトピックの記事を読み、役立つツールを探し、よく文書化され、 名前を変更しました 。 そして最後に、このたとえ話の神格化、まだMacアプリケーションバンドルの普遍的なランチャーがあります。 要約すると、素晴らしいコメントを残してくれたDylan Myersという名前の男性に感謝したいと思います。 これが私にとっての解決策でした:antのappbundleタスクを使用してバンドルをビルドするなど、antを使用してプロジェクトをビルドしています(組み込みのJREが必要な場合は、Macでビルドする必要があります。 Mac、これはプレハブにすぎません。手動でバンドルを動作状態にしましたが、Info.plistの基本プロパティはappbundleで指定できます)、標準のJavaAppLauncherをuniversaleJavaApplicationStubに置き換え、JavaAppLauncherに名前を変更します。 すべての操作が完了した後、完成したアプリケーションバンドルをLinuxのビルドサーバーに配置すると、Jenkinsは問題なくリポジトリからアプリケーションの新しいバージョンをマージし、antタスクを起動し、必要なjarファイルをバンドルにコピーします。 ご清聴ありがとうございました。



All Articles