Мне буквально на прошлой неделе привезли липольки USPS-ом. Отправляли, правда, сингапурской почтой, USPS уже на этой стороне взяла посылку. Видимо, выбора у них уже не было :)
По-моему, мы старались делать так, чтобы список используемых плагинов был пустой (типа запускать всё, что есть в workspace+TP). А дальше уже использовать ленивость+заточенную Target Platform, чтобы лишнее не запускалось.
Про EMF согласен. Эх, если бы для Eclipse на основе EMF сделали бы аналог IDEA-вского PSI — это было бы очень, очень круто.
Да ладно? Те Target Platform, которые указывают на P2 репозитории, выглядят просто и прилично. Малюсенький XML со ссылкой на удалённый репозиторий
Вообще, от сочетания Maven + Tycho + P2 в консоли и PDE + P2 в IDE у меня остались самые лучшие впечатления. Сборка получается простая и консистентная. Если есть какая-то проблема — она выявляется сразу, а не в рантайме, как это происходит при использовании всяких BND/maven-bundle-plugin. Вся настройка в IDE — это загрузка проекта с определением Target Platform и нажатие одной кнопки «Set Target Platform». При этом ты спокойно можешь перекрывать те бандлы, какие тебе надо.
А так как теперь поддержка P2 ещё и в Nexus OSS есть, так вообще красота должна быть. Я в своё время извращался с Tycho, чтобы генерировать P2 репозитории для использования в качестве Target Platform, а сейчас по идее достаточно будет деплоить артефакты в P2 репозиторий на Nexus и всё.
С run configurations проблем не припомню, сохраняли их в VCS без проблем. Правда, сильно сложных случаев вроде не было. Причём в отличии от IDEA их можно локализовывать в отдельные проекты. Не работаешь с каким-то проектом — run configuration не замусоривает тебе UI.
В теории, у IDEA тоже так и есть. Есть пара файлов, которые меняются (workspace.xml, например) и те, которые не меняются. У них даже в документации написано, какие можно хранить в VCS.
Вот только на практике IDEA «стабильные» файлы всё равно постоянно меняет.
Чтобы разработчики одной кнопкой могли открыть проект со всему нужными настройками. В идеале POM должен выполнять эту обязанность, но на практике — не получается.
Что не так с pom-ками? Вот несколько примеров по памяти:
Нет run configurations (хотя вот их как раз можно в VCS более-менее безопасно хранить).
Требуются некоторые дополнительные действия по открытию проекта. Если открывать с «нуля» (не имея каталога .idea), то нет run configurations. Если сохранить часть настроек в .idea, то 10-ка вообще отказывается открывать проект (ругаясь, что нет modules.xml). 11-ая открывает, но требует нажатия кнопки «reimport all maven projects», т.е надо всем 200 разработчикам объяснить, что не надо паниковать при виде пустого проекта.
Настройки VCS для Perforce автоматически не подключаются из pom-ки. Те, кто работал с Perforce, должны понимать, почему критически важно иметь включенную поддержку Perforce в IDE.
Возможно, ещё дело в настройках форматирования, и.т.д, но я пока не вникал в это.
Т.е в идеале нужно уметь открывать проект одной кнопкой и получать полностью настроенное рабочее окружение. Только с POM это не получается.
Во-первых, медленно (у нас ~200 модулей). Любое изменение POM-ов — зависание на секунду. И это без автоматического ре-импорта! Каждый ре-импорт — это ещё секунд 20.
Ненадёжно работает поддержка фильтрации ресурсов (иногда перестаёт делать определённые подстановки и непонятно в чём дело и как чинить). Хотя сам факт наличия поддержки Maven-овской семантики фильтрации ресурсов — это хорошо.
Несколько случаев, когда валидация идёт не по правилам Maven (а, видимо, по тому, как показалось правильным разработчикам). Например, пустой relativePath в ссылке на родителя и стабильные снэпшот версии (вот это вообще обидно).
Игнорируются настройки VCS, когда открываешь проект с POM-а, хотя в POM указаны правильные URL-ы. Причём, например, git всё-таки детектится (видимо, по наличию каталога .git), а вот Perforce — нет (он ничего в рабочий каталог не сохраняет).
Это всё мелочи, конечно, но всё равно мешает. Особенно тогда, когда нужно пересадить 200 человек на Maven, а большинство из них его видит в первый раз.
Брошу ещё одну какашку в сторону IDEA. Eclipse-овские проектные файлы (.classpath, .project и прочие) гораздо проще держать в системе контроля версий. Я навскидку не вспомню ни одной проблемы, главное вместо путей переменные использовать (хотя обычно пути и не нужны).
В IDEA же, даже в новом формате проектов (каталог .idea), фиг чего сохранишь в системе контроля версий. Она постоянно корячит проектные файлы (даже, казалось бы, вполне стабильные *.iml) при малейших изменениях на диске. Очень неудобно.
Вот, кстати, ещё одна какашка в сторону IDEA. Eclipse-овские проектные файлы (.classpath, .project и прочие) гораздо проще держать в системе контроля версий. Я навскидку не вспомню ни одной проблемы, главное вместо путей переменные использовать (хотя обычно пути и не нужны).
В IDEA же, даже в новом формате проектов (каталог .idea) фиг чего сохранишь в системе контроля версий. Она постоянно корячит свои проектов при малейших изменениях на диске. Очень неудобно.
Открывать проект с pom.xml — тоже со своими приколами.
Печаль в том, что на очень большом проекте даже очень мощный компьютер не помогает. Особенно когда дело касается Maven (поддержка которого, к слову, мне в IDEA совсем не понравилась). А если ещё добавить OSGi, то совсем грустно становится.
А вот это уже отдельный вопрос, должен ли это быть отдельный протокол. Я пытался объяснить, почему не целесообразно добиваться того же самого расширениями.
И что значит — «только из-за SPDY»? В чём проблема в увеличении мажорной версии?
Да, SPDY частично уже бинарный протокол, насколько я понимаю.
Потому, что подход SPDY существенно меняет устройство протокола. Настолько, что это ну никак уже не похоже на HTTP/1.1. Можно, конечно, впихать (типа навесить специальную семантику на специального вида тело и передавать всё через него, и.т.д), но зачем? Все три стороны (клиент, сервер, прокси) всё равно надо будет дорабатывать, чтобы получить поддержку SPDY.
Я вот думаю, что Thread.stop() зря сделали deprecated. При написании прикладного кода это, безусловно, очень вредная и опасная функциональность. Однако же для системного когда (например, код сервера приложений или, допустим, OSGi контейнера), это, фактически, единственный способ относительно надёжно пристрелить поток.
С другой стороны, есть ещё два класса ситуаций, которые требуют поддержки со стороны JVM и с которыми, на текущий момент, ничего поделать нельзя. Это контроль за памятью отдельного приложения и выгрузка классов.
В принципе, для выгрузки классов можно было бы предусмотреть механизм «форсированной» выгрузки, когда все ссылки на объекты выгруженных классов заменяются на специальное значение unloaded и вызывают исключение при обращении к ним. Я думаю, это можно было бы сделать практически без накладных расходов в рантайме (ну разве что сама операция форсированной выгрузки будет не очень быстрой).
Для OutOfMemory можно было бы предусмотреть несколько изолированных «куч» с контролем границы между ними, но с учётом разделяемых данных это довольно сложно сделать.
Можно рассуждать о том, что это всё проблема кривых приложений, и.т.д, и.т.п. Но факт в том, что программисты делают ошибки, и ничего с этим не поделаешь. Надо как-то это контролировать. Не только багрепортами, но и самим рантаймом. Вот, например, при разработке Erlang это учли, и повальная смерть процессов там — вполне нормальное явление. Конечно, там нет разделяемой памяти, это существенно упрощает дело.
Стабильно выходит, что 11-ая в 1.5 раза быстрее индексирует. Абсолютные величины, похоже, сильно зависят от дискового кэша — в последний забег всё очень шустро проиндексировалось, 3 минуты 10-ка против 2 минут 11.
Как узнать, сколько файлов было проиндексировано? Она ж и в JAR смотрит, и в ~/.m2 куда-то заглянула.
Про EMF согласен. Эх, если бы для Eclipse на основе EMF сделали бы аналог IDEA-вского PSI — это было бы очень, очень круто.
Вообще, от сочетания Maven + Tycho + P2 в консоли и PDE + P2 в IDE у меня остались самые лучшие впечатления. Сборка получается простая и консистентная. Если есть какая-то проблема — она выявляется сразу, а не в рантайме, как это происходит при использовании всяких BND/maven-bundle-plugin. Вся настройка в IDE — это загрузка проекта с определением Target Platform и нажатие одной кнопки «Set Target Platform». При этом ты спокойно можешь перекрывать те бандлы, какие тебе надо.
А так как теперь поддержка P2 ещё и в Nexus OSS есть, так вообще красота должна быть. Я в своё время извращался с Tycho, чтобы генерировать P2 репозитории для использования в качестве Target Platform, а сейчас по идее достаточно будет деплоить артефакты в P2 репозиторий на Nexus и всё.
С run configurations проблем не припомню, сохраняли их в VCS без проблем. Правда, сильно сложных случаев вроде не было. Причём в отличии от IDEA их можно локализовывать в отдельные проекты. Не работаешь с каким-то проектом — run configuration не замусоривает тебе UI.
О каких-то проблемах писал, может исправят.
Да, их багтрекер мне тоже не нравится :) Плохо гуглится, непонятный какой-то.
Вот только на практике IDEA «стабильные» файлы всё равно постоянно меняет.
Что не так с pom-ками? Вот несколько примеров по памяти:
Нет run configurations (хотя вот их как раз можно в VCS более-менее безопасно хранить).
Требуются некоторые дополнительные действия по открытию проекта. Если открывать с «нуля» (не имея каталога .idea), то нет run configurations. Если сохранить часть настроек в .idea, то 10-ка вообще отказывается открывать проект (ругаясь, что нет modules.xml). 11-ая открывает, но требует нажатия кнопки «reimport all maven projects», т.е надо всем 200 разработчикам объяснить, что не надо паниковать при виде пустого проекта.
Настройки VCS для Perforce автоматически не подключаются из pom-ки. Те, кто работал с Perforce, должны понимать, почему критически важно иметь включенную поддержку Perforce в IDE.
Возможно, ещё дело в настройках форматирования, и.т.д, но я пока не вникал в это.
Т.е в идеале нужно уметь открывать проект одной кнопкой и получать полностью настроенное рабочее окружение. Только с POM это не получается.
Ненадёжно работает поддержка фильтрации ресурсов (иногда перестаёт делать определённые подстановки и непонятно в чём дело и как чинить). Хотя сам факт наличия поддержки Maven-овской семантики фильтрации ресурсов — это хорошо.
Несколько случаев, когда валидация идёт не по правилам Maven (а, видимо, по тому, как показалось правильным разработчикам). Например, пустой relativePath в ссылке на родителя и стабильные снэпшот версии (вот это вообще обидно).
Игнорируются настройки VCS, когда открываешь проект с POM-а, хотя в POM указаны правильные URL-ы. Причём, например, git всё-таки детектится (видимо, по наличию каталога .git), а вот Perforce — нет (он ничего в рабочий каталог не сохраняет).
Это всё мелочи, конечно, но всё равно мешает. Особенно тогда, когда нужно пересадить 200 человек на Maven, а большинство из них его видит в первый раз.
В IDEA же, даже в новом формате проектов (каталог .idea), фиг чего сохранишь в системе контроля версий. Она постоянно корячит проектные файлы (даже, казалось бы, вполне стабильные *.iml) при малейших изменениях на диске. Очень неудобно.
Вот, кстати, ещё одна какашка в сторону IDEA. Eclipse-овские проектные файлы (.classpath, .project и прочие) гораздо проще держать в системе контроля версий. Я навскидку не вспомню ни одной проблемы, главное вместо путей переменные использовать (хотя обычно пути и не нужны).
В IDEA же, даже в новом формате проектов (каталог .idea) фиг чего сохранишь в системе контроля версий. Она постоянно корячит свои проектов при малейших изменениях на диске. Очень неудобно.
Открывать проект с pom.xml — тоже со своими приколами.
На ровном месте куча каких-то тупых проблем.
Я бы с удовольствием вернулся на Eclipse, но увы.
>Т. е. предлагается только из-за SPDY увеличить мажорную версию протокола, так? Я правильно понимаю, что он ещё и не текстовый теперь?
И что значит — «только из-за SPDY»? В чём проблема в увеличении мажорной версии?
Да, SPDY частично уже бинарный протокол, насколько я понимаю.
В «magic». Попробуй добавить synchronized(v) {… }.
С другой стороны, есть ещё два класса ситуаций, которые требуют поддержки со стороны JVM и с которыми, на текущий момент, ничего поделать нельзя. Это контроль за памятью отдельного приложения и выгрузка классов.
В принципе, для выгрузки классов можно было бы предусмотреть механизм «форсированной» выгрузки, когда все ссылки на объекты выгруженных классов заменяются на специальное значение unloaded и вызывают исключение при обращении к ним. Я думаю, это можно было бы сделать практически без накладных расходов в рантайме (ну разве что сама операция форсированной выгрузки будет не очень быстрой).
Для OutOfMemory можно было бы предусмотреть несколько изолированных «куч» с контролем границы между ними, но с учётом разделяемых данных это довольно сложно сделать.
Можно рассуждать о том, что это всё проблема кривых приложений, и.т.д, и.т.п. Но факт в том, что программисты делают ошибки, и ничего с этим не поделаешь. Надо как-то это контролировать. Не только багрепортами, но и самим рантаймом. Вот, например, при разработке Erlang это учли, и повальная смерть процессов там — вполне нормальное явление. Конечно, там нет разделяемой памяти, это существенно упрощает дело.
Как узнать, сколько файлов было проиндексировано? Она ж и в JAR смотрит, и в ~/.m2 куда-то заглянула.