как повторно упаковать затмение для моей команды
Используйте двойные кавычки. "test\n" будет работать просто отлично.
Если строка заключена в двойные кавычки ("), PHP будет интерпретировать больше escape-последовательностей для специальных символов:
7 ответов
Я бы не рекомендовал требовать, чтобы все разработчики размещали eclipse в одном месте. Бывают случаи, когда некоторые разработчики могут захотеть попробовать альтернативную версию eclipse, чтобы изучить технологию, которая требует другого набора плагинов или другой базовой версии eclipse.
Разрешите разработчикам установить eclipse там, где они хотят.
Однако, для jar-файлов, которые вам нужны для запуска подключаемых модулей (внешние зависимости, которые необходимо настроить для правильного использования подключаемых модулей):
Зафиксируйте каталог для этих jar-файлов (в отличие от всего каталога eclipse), например c: \ eclipse-helpers или что-то в этом роде.
Чтобы иметь дело с зависимостями сторонних библиотек (в разрабатываемом вами коде), у вас есть несколько хороших вариантов:
Создайте проект (ы) для хранения сторонних библиотек и зарегистрируйте их в своей системе контроля версий исходного кода (которую вы используете , верно?). Затем вы можете добавить библиотеки в путь (пути) сборки проекта (ов) - убедитесь, что вы отметили их для экспорта на вкладке «Порядок и экспорт» на странице пути сборки. Затем вы можете просто добавить эти сторонние проекты в качестве зависимостей проекта.
Укажите сторонние jar-файлы как переменные CLASSPATH при добавлении их в путь сборки ваших проектов. Это позволяет другим разработчикам хранить зависимости в разных местах. Возможно, определите переменную CLASSPATH (в eclipse Window-> Preferences-> Java-> Build Path-> Classpath Variables) с именем THIRD_PARTY_JARS; каждый разработчик может сопоставить его с разными путями, по которым они хотят провести свою работу.
Ссылка на сторонние jar-файлы как на «пользовательскую библиотеку» (Окно-> Настройки-> Java-> Путь сборки-> Пользовательская библиотека). Это похоже на переменные пути к классам, но действует как явный набор jar-файлов.
Включайте сторонние jar-файлы непосредственно в свои проекты. Используйте эту опцию только в том случае, если вам нужны депы в одном месте.
Хотя это не совсем соответствует направлению вопроса, вы можете использовать Yoxos OnDemand . Он позволяет вам создавать собственный дистрибутив Eclipse и загружать его в виде zip-архива. Они добавляют в свою собственную перспективу, где вы можете добавлять дополнительные плагины (прямо из их репозитория) или обновлять плагины, которые у вас есть.
Хотя я никогда не использовал эту функцию, вы можете создавать свои собственные стеки и давать им имена, позволяя любому позже перейти на сайт и загрузить его (с самыми последними версиями плагинов). Кроме того, зависимости для подключаемых модулей при необходимости разрешаются автоматически.
В eclipse - во многих местах можно также использовать относительные пути рабочего пространства или информацию о системной среде для ссылки на внешние файлы. Другой вариант - разместить ваши jar-файлы в проекте рабочей области, чтобы каждый член команды мог проверить его из cvs / subversion / что угодно и начать работать. Подобная работа обеспечивает воспроизводимую среду для сборки серверов или настольных компьютеров даже спустя годы.
Говоря о Yoxos ... он также обеспечивает «Предоставление рабочего пространства». Это означает, что вы можете прикрепить Eclipse Preferences, конфигурации checkstyle и настройки Mylyn в дополнение к вашему списку необходимых инструментов / плагинов для вашей IDE к вашему профилю yoxos. Это означает, что ваша команда может поделиться профилем и сможет начать работу с той же настройкой, независимо от их ОС или чего-то еще. (Также возможно использовать несколько профилей одновременно.)
Мы сделали то же самое с нашей средой разработки (для этого требовалось и Eclipse, и наш собственный плагин, который на ранних этапах должен был запускаться в известном месте).
Мы просто поместили его в c: \ eclipse_ и сделали это требованием для команды. Это, наверное, самое простое решение для вас.
Это ваша команда, вы можете продиктовать это как требование. Если члены вашей команды не абсолютные идиоты, они будут работать с вами.
Я обнаружил, что Yoxos действительно хорош, и он очень хорошо справляется с определением зависимостей. Это действительно хороший инструмент, и стоит взглянуть на него.
I just started using git to manage my eclipse install. I did a write-up. The approach might work for you, and it's probably worth looking at.
Если у всех разработчиков разные пути на своей машине, вместо добавления независимых JAR-файлов вы можете создать то, что Eclipse называет «библиотекой», и включить в нее кучу jar-файлов. Затем другому разработчику просто нужно изменить расположение библиотеки, и он заберет там все банки.