Eclipse: запуск собственного приложения eclipse под linux мгновенно возвращает к командной строке - PullRequest
1 голос
/ 25 февраля 2010

Я занимаюсь разработкой веб-приложения OSGI на основе Eclipse / Equinox (с использованием встроенной Jetty) и использую PDE-Build без головы для сборки приложения. Моя сборка создает zip-файл для Linux GTK и один для моего локального macosx.

До сих пор это работало хорошо, и я мог просто разархивировать zip-файл linux на моем сервере, основанном на Debian, и запустить . / Eclipse из командной строки, и приложение запустилось бы.

Вчера у меня была готова новая сборка, развернул ее, разархивировал и запустил . / Eclipse , и ничего не произошло. Нет вывода ... ничего. Он немедленно вернул мне командную строку.

christoph@myserver:~/myapp$ ./eclipse 
christoph@myserver:~/myapp$

То, что я пробовал потом, запускалось вручную с помощью средства запуска равноденствия:

christoph@myserver:~/myapp$ java -jar plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar

Это выглядело намного лучше, и казалось, что приложение запускается как обычно .... но примерно через 10 секунд оно остановилось в середине запуска, и я вернулся в командной строке.

Кто-нибудь имеет представление, в чем может быть причина или как я могу отладить, что происходит с файлом запуска eclipse? Я думаю, что ничего не менял в скриптах сборки в течение нескольких недель, и полученный zip-файл имеет обычный размер, который был раньше. Я также перезагрузил сервер.

Я пробовал такие вещи, как . / Eclipse -noexit , . / Eclipse -debug , . / Eclipse -clean и . / Eclipse -refresh , . / eclipse -vm / path / to / my / jdk / java , но все имеет тот же эффект. Нет выхода, ничего.

Спасибо Christoph

Ответы [ 2 ]

1 голос
/ 26 февраля 2010

Обновление : эта проблема решена. Прокрутите до конца этого ответа для решения.

Да, я думаю, что нашел это ... по стечению обстоятельств. Я еще не уверен, что является основной причиной, но я знаю, какой симптом вызывает проблемы при запуске.

В основном я думаю, что это связано с условиями гонки моего Build-процесса и Delta-пакета и следующих jar-файлов / папок:

Папка : org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520

против.

Jar : org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519.jar

Место, на которое я наткнулся, было несколько сообщений во время сборки, которые я часто видел, но никогда не задумывался о: Например.

[java] [eclipse.generateFeature] сверток org.eclipse.equinox.launcher.gtk.linux.x86: [java] [eclipse.generateFeature] Выбрана другая версия синглтона: org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520

Звучит так, будто сборка обработана что-то еще ...?!? Что мне кажется странным.

В случае, если он работал , этот файл jar был извлечен (так что это была папка с именем org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200. v20090520 ), и в этой папке содержался файл eclipse_1206.so .

В случае, если не работал , была также папка с именем org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520 , но файл eclipse_1206.so был НЕ в этой папке.

Я также проверил это на моей локальной машине с Ubuntu, и это дало мне больше выходных данных в неработающем случае , чем на машине Debian.

Когда он не работал под Ubuntu, я получил что-то вроде этого:

$ ./eclipse

(.: 26981): GLib-GObject-WARNING **: недействительный (NULL) экземпляр указателя

(.: 26981): GLib-GObject-CRITICAL **: g_signal_connect_data: утверждение G_TYPE_CHECK_INSTANCE (экземпляр) не удалось

(.: 26981): Gtk-CRITICAL **: gtk_settings_get_for_screen: утверждение Ошибка GDK_IS_SCREEN (screen)

(.: 26981): GLib-GObject-CRITICAL **: g_object_get: утверждение `G_IS_OBJECT (объект) 'не удалось

(.: 26981): GLib-GObject-WARNING **: значение «ИСТИНА» типа gboolean' is invalid or out of range for property visible 'типа `gboolean'

(.: 26981): Gtk-CRITICAL **: gtk_settings_get_for_screen: утверждение Ошибка GDK_IS_SCREEN (screen)

(.: 26981): GLib-GObject-CRITICAL **: g_object_get: утверждение `G_IS_OBJECT (объект) 'не удалось

(.: 26981): Gtk-WARNING **: Экран для GtkWindow не установлено; вы должны всегда устанавливать экран для GtkWindow перед использованием окно

(.: 26981): Gdk-CRITICAL **: gdk_pango_context_get_for_screen: утверждение `GDK_IS_SCREEN (экран) ' не удалось

(.: 26981): Панго-Критический **: pango_context_set_font_description: утверждение `context! = NULL 'не удалось

(.: 26981): Панго-Критический **: pango_context_set_base_dir: утверждение `context! = NULL 'не удалось

(.: 26981): Панго-Критический **: pango_context_set_language: утверждение `context! = NULL 'не удалось

(.: 26981): Панго-Критический **: pango_layout_new: утверждение `контекст ! = NULL 'не удалось

(.: 26981): Pango-CRITICAL **: pango_layout_set_text: утверждение `layout! = NULL 'не удалось

(.: 26981): Панго-Критический **: pango_layout_set_attributes: утверждение `layout! = NULL 'не удалось

(.: 26981): Pango-CRITICAL **: pango_layout_set_alignment: утверждение `layout! = NULL 'не удалось

(.: 26981): Панго-Критический **: pango_layout_set_ellipsize: утверждение Ошибка PANGO_IS_LAYOUT (макет)

(.: 26981): Pango-CRITICAL **: pango_layout_set_single_paragraph_mode:утверждение `PANGO_IS_LAYOUT (макет) ' не удалось

(.: 26981): Панго-Критический **: pango_layout_set_width: утверждение `layout! = NULL 'не удалось

(.: 26981): Панго-Критический **: pango_layout_get_extents: утверждение `layout! = NULL 'не удалось

(.: 26981): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: утверждение `GDK_IS_SCREEN (экран) ' не удалось

(.: 26981): Gtk-CRITICAL **: gtk_settings_get_for_screen: утверждение Ошибка «GDK_IS_SCREEN (screen)»

(.: 26981): Gtk-CRITICAL **: gtk_icon_size_lookup_for_settings: утверждение `GTK_IS_SETTINGS (настройки) ' не удалось

(.: 26981): Gtk-WARNING **: недействительно размер значка 6

(.: 26981): Gtk-CRITICAL **: gtk_icon_theme_load_icon: утверждение GTK_IS_ICON_THEME (icon_theme) ошибка сегментации

На хосте Debian (vserver.de) я получил вывод NO , как описано в моем первом вопросе выше.

Возможно, в процессе сборки иногда использовался первый, а иногда и второй. Я не могу объяснить, почему в данный момент. Я также заметил, что папка предназначена для простой архитектуры _x86 (32 бита), а jar - для архитектуры x86_64 (64 бита). Не уверен, почему 64 выбран вообще, потому что я не указал x86_64 в моих build.properties.

Кроме того, я не понимаю, что полученная папка с именем org.eclipse.equinox.launcher.gtk.linux.x86_1.0.200.v20090520 содержит файл eclipse_1206 .so , хотя этот файл присутствует ТОЛЬКО в org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519.jar (обратите внимание на ... x86_64 ... )

Заключение Я думаю, что основная причина в том, что у меня какая-то непоследовательная / сломанная / испорченная targetplatform или delta-pack. Может быть, я также делаю что-то не так, как я делаю сборку PDE без головы, но я не мог сказать пока, потому что это казалось работающим ... иногда ... а иногда нет :)

Я подтвердил свое утверждение выше, заменив соответствующую папку на папку, которая содержала файл eclipse_1206.so , и неожиданно это сработало. Воспроизводимые. Поэтому, если у вас есть похожие проблемы с загрузкой в ​​Linux, возможно, проверьте наличие eclipse_1206.so в папке / jar программы запуска равноденствий (например, org.eclipse.equinox.launcher.gtk.linux.x86_1. 0.200.v20090520)

Тем временем я выясню, в чем была основная причина и как правильно настроить сборку, и запишу это в блоге.

Спасибо всем, кто до сих пор пытается помочь.

* +1135 * * Кристоф 1136 *

Обновление решения: Решением было загрузить новый Eclipse Deltapack для версии 3.5 и заменить все мои плагины ..launcher .. на моей целевой платформе новыми. Проблема была в поврежденном модуле запуска, в котором отсутствовал файл eclipse_1206.so .

Обновление 2010/03/01: В другой заметке я обнаружил, что SVN по умолчанию игнорирует расширение файла .so, которое также является источником моих проблем. Мое решение, которое я описал выше, до сих пор работало только локально, и это было правильно. Но сегодня я хотел проверить, верны ли, наконец, и правильные ли сборки, исходящие с моего сервера сборки ... они все еще были сломаны. Я мгновенно проверил папку плагина запуска и вижу, что eclipse_1206.so снова отсутствует. Затем я проверил репозиторий SVN, и на самом деле файла там не было. Оказывается, SVN по умолчанию игнорирует эти файлы, которые я сейчас описал здесь: SVN по умолчанию принимает файлы .so

0 голосов
/ 25 февраля 2010

Если файл журнала не создан, это может быть связано с ошибкой eclipse.ini (например, дополнительные пробелы в конце одной из строк eclipse.ini содержимого)

Этот .ini файл как-то недавно изменился?
(Или укажите путь, который больше не доступен на сервере развертывания, где вы видите эту проблему?)

...