2013-02-25 14 views
5

Zbudowałem aplikację Eclipse RCP (Indigo) z Tycho. Kompilacja działa na maszynie Win 7, 64-bit.Dystrybucja Mac aplikacji Eclipse RCP zbudowanej za pomocą Tycho na Windows nie uruchamia się

POM rodzic obejmuje:

<plugin> 
    <groupId>org.eclipse.tycho</groupId> 
    <artifactId>target-platform-configuration</artifactId> 
    <version>${tycho-version}</version> 
    <configuration> 
    <resolver>p2</resolver> 

    <environment> 
    <os>linux</os> 
    <ws>gtk</ws> 
    <arch>x86_64</arch> 
    </environment> 
    <environment> 
    <os>win32</os> 
    <ws>win32</ws> 
    <arch>x86_64</arch> 
    </environment> 
    <environment> 
    <os>macosx</os> 
    <ws>cocoa</ws> 
    <arch>x86_64</arch> 
    </environment> 

... 

Konfiguracja produkt wygląda następująco (z kilku przeoczeń i dodatkowa linia łamie dla readbility):

<product name="My App" uid="myapp.product" id="myapp.core.product" application="myapp.core.application" version="0.1.4.qualifier" useFeatures="true" includeLaunchers="true"> 

    <configIni use="default"> 
    </configIni> 

    <launcherArgs> 
     <programArgs>-data @noDefault</programArgs> 
     <vmArgsMac>-XstartOnFirstThread 
         -Dorg.eclipse.swt.internal.carbon.smallFonts</vmArgsMac> 
    </launcherArgs> 

    <launcher name="myapp_0_1_4"> 
     <solaris/> 
     <win useIco="false"> 
     <bmp/> 
     </win> 
    </launcher> 

    <vm> 
     <macos include="false">org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6</macos> 
    </vm> 

    <plugins> 
     <plugin id="com.ibm.icu"/> 
     <plugin id="myapp.core"/> 
     <plugin id="org.eclipse.core.runtime"/> 
     <plugin id="org.eclipse.core.runtime.compatibility.registry" fragment="true"/> 
     <plugin id="org.eclipse.equinox.app"/> 
     <plugin id="org.eclipse.equinox.common"/> 
     <plugin id="org.eclipse.osgi"/> 
     <plugin id="org.eclipse.swt"/> 
     <plugin id="org.eclipse.swt.win32.win32.x86_64" fragment="true"/> 
     <plugin id="org.eclipse.ui"/> 
     <plugin id="org.eclipse.ui.workbench"/> 
    </plugins> 

    <features> 
     <feature id="org.eclipse.rcp" version="3.7.2.v20120120-1424-9DB5FmnFq5JCf1UA38R-kz0S0272"/> 
     <feature id="myapp.platform_dependencies.feature" version="0.1.4.qualifier"/> 
     <feature id="myapp.core.feature" version="0.1.4.qualifier"/> 
     <feature id="myapp.ui.feature" version="0.1.4.qualifier"/> 
     <feature id="myapp.model.feature" version="0.1.4.qualifier"/> 
    </features> 

    <configurations> 
     <plugin id="org.eclipse.core.runtime" autoStart="true" startLevel="0" /> 
     <plugin id="org.eclipse.equinox.common" autoStart="true" startLevel="2" /> 
    </configurations> 

</product> 

Kompilacja przebiega bez problemów, i generuje pliki zip, które rozpakowane w docelowym systemie operacyjnym Windows & Linux zawiera działające programy uruchamiające. (W systemie Linux, muszę zrobić plik wykonywalny wyrzutni, zanim będzie mógł go uruchomić.)

W systemie Mac OS X (10.6.8), jednak wyrzutnia (myapp.app) nie robi nic ...

Po uruchomieniu java -jar -XstartOnFirstThread plugins/org.eclipse.equinox.launcher_[version] aplikacja zostanie uruchomiona, aczkolwiek bez ekranu powitalnego.

Wyobrażam sobie, że mam złe ustawienie w mojej konfiguracji produktu, ale nie mam nic przeciwko temu.

+0

Należy dodać, że używam repo Indigo p2 zamiast lokalnej platformy docelowej w kompilacji. –

+0

Notatka dla .app początkujących takich jak ja: 'myapp.app' jest tak naprawdę folderem, a ustawienie wykonywalnego bitu dla tego folderu - o ile nie zostanie wykonane rekursywnie - niczego nie zmieni. Rzeczywisty plik programu uruchamiającego znajduje się w tym folderze na * myapp.app/Contents/MacOS/myapp *, a ustawienie wykonywalnego bitu dla tego pliku ('chmod + x myapp') zmyśli i sprawi, że aplikacja będzie wykonywalna (a) poprzez uruchomienie tego pliku z wiersza poleceń (z poziomu * myapp.app/Contents/MacOS/* z './myapp'), (b) poprzez dwukrotne kliknięcie * myapp.app/Contents/MacOS/myapp *, lub (c) przez dwukrotne kliknięcie na * myapp.app * (w Finderze) –

Odpowiedz

3

Nie oczekuje się, że wieloplatformowa kompilacja w systemie Windows na komputery Mac będzie działać. Powodem jest to, że Tycho/p2 musiałaby symulować system plików z uprawnieniami Unix. W teście śledzenia Tycho znajduje się request for this, ale wdrożenie IMHO nie jest warte wysiłku.

+0

Przeczytałem raport o błędzie i nie będę w tym momencie uczestniczył w dyskusji implementacja wykonywalnej funkcji bitowej dla systemu Windows jest przydatna, czy nie (i tak jestem raczej agnostykiem OS), ale czy możesz potwierdzić, że przeniesienie kompilacji do, na przykład, Linuksa to rozwiąże? –

+2

Tak, wieloplatformowe kompilacje z działaniem Tycho, jeśli maszyna kompilująca jest systemem * nix. – oberlies

1

Właśnie dowiedziałem się, jak zrobić plik wykonywalny OSX .app z systemu Windows.

Możesz ustawić kompilację Tycho do generowania plików .tar.gz dla Mac/Linuxa, a następnie użyć narzędzia do ustawienia uprawnień do pliku wykonywalnego w pliku tar, jako że tar obsługuje * uprawnienia nix.

Oto fragment kodu pokazujący, jak ustawić to w pliku pom.xml. (W tym fragmencie jest również tworzony folder Mac .app i dodawane są wersje do plików archiwów): http://snipt.org/Aggid3

Oto klasa Java, która wykonuje bit uprawnień. Wymaga to Guava i Apache Commons Compress: http://snipt.org/Aggic1

Oto Montowane słoik łącznie ze wszystkimi zależnościami: https://mega.co.nz/#!WcNjyRjS!KE7tM1xYrt1l9JIguUAsrgpLe2V0NS1QIj_NvdAnm88

przykładem wykorzystania przy użyciu powyższego byłoby: java -jar gztperms.jar „My produktowych 0.0.1.201309091838-macosx.cocoa.x86.tar.gz "" Mój produkt-plik wykonywalny-0.0.1.201309091838-macosx.cocoa.x86.tar.gz "" My Product.app/Contents/MacOS/My Product "

Mam dość trywialny skrypt post-build oparty na mrówkach, który wykonuję z Jenkinsa, który znajduje plik .gz i uruchamia ten skrypt na nim i zawsze ything teraz działa z linku artefaktu.

Powiązane problemy