Каков наилучший способ развернуть мой веб-проект (или проект уха) на удаленный сервер и стеклянную рыбку?
Как использовать ant -deploy.xml и build-impl.xml, которые netbeans создают для этой цели?
Использование папки autodeploy и отдельного добавления sun-resources.xml в GF Или Используя ant и....
Не могли бы вы объяснить мне шаг за шагом?
Привет
Ну, вы можете вручную развернуть приложение через консоль администратора.
Или вы можете использовать команду asadmin. Удаленное развертывание в простейшем из них будет выглядеть следующим образом:
asadmin deploy --user=<adminuser> --host=<hostname> <path to jar/war/ear>
И это может быть сценарий с оболочкой или завернутый в Ant или Maven.
Или вы могли бы использовать более специализированные инструменты (Ant Task, плагин maven glassfish, плагин maven asadmin, Cargo).
Все зависит от вашего контекста, нет единого ответа, и есть много возможностей. Если вы не знаете, что ищете, просто используйте скрипты Ant build, созданные NetBeans.
Используйте комбинацию из
Чтобы ответить на этот вопрос, полезно рассмотреть более широкий подход и рассмотреть весь жизненный цикл разработки/развертывания. Фактическое развертывание .war или .ear архива в Glassfish - всего лишь один шаг цикла.
Если вы хотите быть действительно эффективным, вам необходимо рассмотреть комбинацию инструментов и практик для автоматизации построения и развертывания ваших программных приложений. Это особенно актуально, если вы работаете в "реальной" среде с машинами-разработчиками, станками непрерывной интеграции, машинами QA и производственными машинами.
Я подробно расскажу об этих пунктах в следующих параграфах. В частности, я объясню, почему я думаю, что сегодня пользовательские сценарии оболочки, приводимые в действие maven, лучше, чем плагины maven для плавания, доступные в сообществе.
Для многих людей, занимающихся разработкой java, maven - это хорошо известный инструмент. Для остальных это очень краткое введение. Цель maven - автоматизировать построение программных артефактов. Это структура (в том же смысле, что и объектно-ориентированная структура), что означает, что:
В сущности, когда вы используете maven, вы описываете, какой программный артефакт вы строите (это .jar, это .war, это приложение Android и т.д.). По умолчанию maven ожидает найти исходные файлы, тестовые файлы и ресурсы в определенных местах. По умолчанию, maven знает, что для создания программного обеспечения требуется пройти разные фазы: компиляция, модульное тестирование, упаковка, развертывание, интеграционное тестирование, создание документации и т.д.
Еще одна вещь, которую maven делает для вас (и которая часто является первой причиной использования этого инструмента) - это управление зависимостями. Maven определяет способ идентификации библиотек (с именем и версией), которые доступны через репозитории (есть общедоступные, глобальные репозитории и частные репозитории). С maven вы указываете такие вещи, как "Я полагаюсь на версию magiglib версии 1.2.2". Когда вы попросите maven выполнить сборку, она автоматически загрузит библиотеку, сохранит ее в локальном хранилище и использует ее для построения и упаковки. Не нужно иметь дело с ручной передачей файлов .jar, не рискуя вводить ошибки, потому что разные версии той же самой библиотеки используются разными разработчиками или на разных этапах.
И последнее, но не менее важное: maven предлагает возможность настроить построение вашего программного обеспечения в зависимости от целевой машины развертывания. Подумайте о следующих случаях использования:
Во время разработки подумайте, что у каждого разработчика может быть другая установка (mysql не может прослушивать один и тот же TCP-порт, стеклянную рыбку нельзя установить в том же каталоге, пароли будут разными и т.д.).
Машина разработки, очевидно, отличается от среды непрерывной интеграции, которая сама по себе отличается от QA или производственной среды (опять же, просто подумайте о сети, файловой системе, учетных данных).
Maven поддерживает эти варианты использования с комбинацией переменных, профилей и фильтрации ресурсов:
Maven - чрезвычайно мощный инструмент и, как таковой, имеет кривую обучения. Если вы используете Netbeans, вы можете создать проект, управляемый maven, с помощью нескольких кликов и воспользоваться базовыми функциями (например, управление зависимостями). Для расширенных тем есть очень хорошая документация. Я не буду вдаваться в подробности здесь.
Как только вы поняли значение maven и решили использовать его, следующий вопрос заключается в том, как вы можете использовать его для для фактического развертывания .war или .ear архива в Glassfish (локально или удаленно). Именно здесь у вас есть несколько вариантов, и на протяжении многих лет мы узнали немало вещей (мы уже несколько лет используем maven со стеклянными рыбками).
Первое, что вы можете сделать, это использовать один из плагинов maven из морской рыбы. Доступны разные плагины. Они имеют совершенно разные возможности и различные уровни поддержки. Оказывается, самый мощный плагин на самом деле больше не поддерживается и не работает с Glassfish 3 из коробки. Плагин был интересен, поскольку он позволил не только развернуть архивы в Glassfish, но и создать ресурсы (пулы jdbc, очереди jms и т.д.). Это также позволило создавать домены из стекловолокна "на лету" (очень полезно проводить интеграционные тесты и следить за тем, чтобы для этого использовался новый домен). В любом случае, новые плагины (описанные в документации по продукту) не настолько эффективны и ориентированы на задачу развертывания.
В системе сборки, которую мы создали и развивали на протяжении многих лет, мы смогли добиться большого контроля и гибкости, объединив плагин maven из плава с помощью профилей и фильтрации ресурсов. Решение работает, является солидным, но довольно сложным (наши pom.xml и settings.xml сильно выросли и стали тяжелыми).
Итак, если бы я настраивал новую систему сборки с нуля, я, вероятно, делал бы это по-другому.. Если вы посмотрите на код плагинов maven из Glassfish, вы увидите, что они довольно много оберток вокруг инструмента командной строки asadmin, предоставленного Glassfish (и это связано с изменением параметров и поведения asadmin от одной версии из стеклянной рыбы до другой, что были отключены плагины maven).
Что бы я сделал:
написать набор сценариев оболочки для создания доменов , создать ресурсы (jdbc, jms и т.д.), deploy.war и .ear. Сценарии использовали бы asadmin для взаимодействия с стеклянными рыбками (можно использовать asadmin как локально, так и удаленно);
внедрить переменные maven в этих сценариях и использовать фильтрацию ресурсов для динамического создания версий сценариев, специфичных для среды;; p >
используйте maven exec plug-in для запуска скриптов на разных этапах цикла сборки maven (интеграционный тест, запуск, пользовательские цели и т.д.).
Вы можете использовать задачу ant для развертывания военного файла в glassfish-V3;
Содержимое Build.xml;
<target name="deploy"
description="deploys application to glassfish">
<exec failonerror="true" executable="cmd">
<arg value="/c" />
<arg value="asadmin --user ${gfUser} --passwordfile ${gfPassFile} --host ${host} deploy build/${war}" />
</exec>
</target>
Еще один независимый способ развертывания приложения:
<presetdef name="asadmin">
<java jar="${glassfish.home}/modules/admin-cli.jar" fork="true" jvm="${java.home}/bin/java" >
<arg line="--port ${glassfish.admin.port}" />
</java>
</presetdef>
<target name="deploy">
<asadmin failonerror="true">
<arg value="deploy" />
<arg value="--force=true" />
<arg value="${ear.file}" />
</asadmin>
</target>
вы colud используете asadmin, предварительно заданный с любыми задачами asadmin...
Я обнаружил, что несколько методов работают хорошо в зависимости от вашего сценария:
Glassfish позволяет автоматическое горячее размещение ресурсов, размещенных в правильном месте "внутри" файлов запущенной Glassfish. Место по умолчанию для Glassfish 3.1.2.2 - glassfish-3.1.2.2/glassfish/domains/domain1/autodeply. Ранее я обнаружил, что в Windows он иногда не обнаруживает, что файл был обновлен, поэтому сначала может потребоваться удаление и ожидание развертывания перед его развертыванием.
Страница администратора (порт по умолчанию 4848) содержит раздел развертывания, позволяющий пользователям загружать и развертывать, отключать и включать, а также развертывать приложения. Это то, что я считаю самым надежным для ручного обслуживания.
Он также не требует полного доступа к базовому серверу.
Грузовой проект позволяет автоматически развертывать подходящий экземпляр Glasfish.
Следующая команда, выполненная с pom.xml, описывающей развертывание войны, будет (по состоянию на 2012-10-17) загружать и выполнять стеклянную рыбку с текущим проектом, развернутым на ней.
mvn clean verify -Dcargo.maven.containerId=glassfish3x -Dcargo.maven.containerUrl=http://dlc.sun.com.edgesuite.net/glassfish/3.1.2.2/release/glassfish-3.1.2.2-web.zip org.codehaus.cargo:cargo-maven2-plugin:run
(вместе с небольшим фрагментом в pom.xml, в котором рассказывается о дополнительных деталях о местонахождении морской рыбы)
Поддержка Maven была хорошей с Glassfish 3. Основное преимущество заключается в том, что вам не нужно загружать и распаковывать и запускать Glassfish вручную - maven может делать все это автоматически.
Для получения инструкций см. http://embedded-glassfish.java.net/.
Я использовал это ненадолго, но, похоже, это хорошая альтернатива решениям, ориентированным на IDE.
Добавление точек в ответ от @Pascal Thivent, (Я надеюсь, что это будет полезно для других с похожим вопросом)
1) Это просто щелчок мышью, чтобы начать, остановить, развернуть приложение с помощью Netbeans.
2) Помимо работы с Eclipse или Netbeans или вашей любимой IDE
2.1) В среде Windows dev: начните с инструментов командной строки, таких как asadmin, во время разработки. 2.2) В среде Linux dev: используйте сценарии оболочки и автоматизируйте процесс развертывания.
2.3) Используйте удаленное развертывание autodeploy и Netbeans в среде dev. 2.4) использование удаленного сценария или командной строки основано на необходимости
3) Вы придумали наиболее подходящий подход, например, разработать script "на основе потребностей и интересов проекта и других таких как организационный процесс.
Без maven или ant просто добавление необходимых банок вручную - неплохая идея. После добавления баннеров разверните консоль администратора или просто используйте build script.
Maven сработает несколько раз с javaEE-баночками.. но у вас есть решения в SO. Я несколько раз езжу с Maven на основе существующего типового проекта и организационного процесса. Я также использую ant, который поставляется по умолчанию с проектом Netbeans Java EE.