Eclipse, Gwt и Maven - Как сделать свою жизнь проще

Недавно у меня был research проект в котором мы изучали возможности GWT 2.x, а также изучали способы интеграции maven и GWT. Тремя самыми интересными решениями я хочу поделиться. Используемые компоненты:

• Eclipse 3.6
• GWT 2.0.4
• Maven 2.2.1
• gwt-maven-plugin 1.2.0

1. Hot redeploy клиентского кода

Как известно GWT из java кода клиентского интерфейса генерирует JS-код. Даже на небольших проектах такой цикл compile + deploy занимает 30+ секунд времени.

Путем небольших настроек maven проекта это время можно свести к нулю, обеспечив hot redeploy клиентского кода.

Как написано на официальном сайте GWT - работа над интеграцией GWT и Maven ведется, но еще не закончена. Основной проблемой в данный момент является расположение генерируемых файлов и web.xml. Поэтому для корректной работы hot redeploy необходимо достигнуть взаимопонимания между GWT, Maven и Eclipse.



1.1. Настройка Eclipse

1.1.1 В свойствах вашего клиентского модуля Properties->Google->Web Application убедитесь что опция This project has a WAR directory выбрана и указывает на src/main/webapp directory. Это стандартная папка с описанием для maven WAR проектов. Также убедитесь что опция Launch and deploy from this directory НЕ выбрана.

1.1.2 В свойствах вашего клиентского модуля Properties->Java Build Path выберите вкладку "Source" и убедитесь что параметр Default output folder активирован и указывает на папку target/your-project-name/WEB-INF/classes.

1.1.3 При запуске приложения через Run As->Web Application (or Debug) вы увидите диалоговое окно с предложением выбора папку war. Необходимо указывать не src/main/webapp, а директорию с результатом компиляции target/your-project-name.

После этих настроек ваше приложение можно будет запускать как Web Application. Для активации сделанных изменений необходимо будет выполнять команд GWT Compile Project.

1.2. Настраиваем Maven

Для работы с GWT вам необходимо подключить плагин gwt-maven-plugin.

1.2.1. Мы использовали gwt-maven-plugin версию 1.2.0-11137. Вот пример настроек плагина:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.2.0-11137</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test</goal>
</goals>
</execution>
</executions>
<configuration>
<runTarget>com.epam.dms.Application/Application.html</runTarget>
</configuration>
</plugin>

1.2.2. Кроме настроек плагина необходимо немного модифицировать поведение Maven:

<build>
... <outputDirectory>war/WEB-INF/classes</outputDirectory>
... </build>

С помощью этой директивы мы говорим Maven что компилировать классы надо не в target/..., а в war/WEB-INF/classes

1.2.3. Чтобы корректно собирать war-файл с gwt приложением необходимо настроить плагин maven-war-plugin:


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0.2</version>
<configuration>
<warSourceDirectory>war</warSourceDirectory>
<webXml>src/main/webapp/WEB-INF/web.xml</webXml>
</configuration>
</plugin>

1.2.4. После этих нехитрых манипуляций клиентское приложение можно будет запускать как mvn gwt:run. В качестве сервера приложений будет использоваться встроенный в GWT Jetty. А все изменения в код клиента будут автоматически подхватываться без каких-либо дополнительных действий.

2. Отладка GWT приложения

После выполнения настроек из раздела 1 нам нужно будет только запускать приложение как mvn gwt:debug. Сервер приложений будет стартовать в режиме удаленной отладки и вы сможете подключиться к нему на стандартном порту с помощью Debug As->Remote Java Application

3. Автоматическое развертывание проекта на Tomcat

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

В качестве тестового сервера приложений был выбран Apache Tomcat 6.0.24.

3.1. Настройка maven

Нашей целью было корректно развертывать приложение с помощью tomcat:deploy в различных окружениях (как на машинах разработчиков, так и в тестовом окружении)

Мы решили использовать tomcat-maven-plugin

3.2. Настройка tomcat-maven-plugin

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<version>1.0</version>
<configuration>
<url>${appserver.home}</url>
<path>${appserver.context}</path>
<server>${appserver.id}</server>
</configuration>
</plugin>

3.3. В зависимости от окружения мы активировали тот или иной profile:

<profiles>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<appserver.home>http://localhost:8080/manager/</appserver.home>
<appserver.context>/dms</appserver.context>
<appserver.id>tomcat-local</appserver.id>
</properties>
</profile>
<profile>
<id>ci</id>
<properties>
<appserver.home>http://appserver:8585/manager/</appserver.home>
<appserver.context>/dms</appserver.context>
<appserver.id>tomcat-ci</appserver.id>
</properties>
</profile>
</profiles>


3.4. Логин и пароль к manager интерфейсу tomcat завались в глобальных настройках maven (.m2/settings.xml):

<servers>
<server>
<id>tomcat-local</id>
<username>admin</username>
<password>admin</password>
</server>
</servers>

3.5. На CI сервере (мы использовали hudson) была создана задача autodeploy, которая запускалась при успешной сборке проекта. Она последовательно выполняла mvn -P ci tomcat:undeploy tomcat:deploy

Заключение:

Каждая из этих операций позволяет вам сэкономить от 10 до 60ти секунд за операцию. На первый взгляд это совсем немного, но если посчитать сколько раз в день разработчик пересобирает приложение чтобы увидеть свои изменения - цифра издержек получается существенной.

А возможность в любой момент дать стороннему человеку ссылку на свежую версию нашего приложения (пусть и нестабильную) - избавляет нас от головной боли о срочном развертывании где-то текущей версии системы.