Показаны сообщения с ярлыком Eclipse. Показать все сообщения
Показаны сообщения с ярлыком Eclipse. Показать все сообщения

четверг, июля 7

Eclipse и большие XML файлы

При попытке открыть очередной XML файл в несколько сотен килобайт внутри Eclipse, последний тупо "завис". Различные попытки "поиграть" с параметрами запуска не приводили к успеху.

В итоге, действенным способом оказалось предварительно отформатировать XML, а потом уже "скармливать" его Eclipse.

самый простой и быстрый способ, это в консоли выполнить:
xml_pp -l -i.bak file

В итоге, получим отформатированный XML-файл file и его резервную копию (оригинал) в виде file.bak

Правда нужно это больше только для удобоваримого визуального чтения файла) а в обиходе лучше использовать таки однострочный xml-файл для уменьшения размера оного.


Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

понедельник, августа 30

Zend Framework XML-конфиг и константы

В предыдущем посту я написал про то, как легко перейти с INI-конфигурации на XML-конфигурацию. В использовании оной есть как плюсы, так и минусы.

из плюсов, как минимум то, что не приходится писать кучу повторяемых "веток" вида "resources.frontController" - мы пишем простое XML-дерево.
из минусов:
1) чтение XML-конфигурации несколько дольше (по тестам, что нашёл - ~0,15 сек). но есть подозрение, что ещё быстрее, чем ini-файл будет подсовывание напрямую массива как конфигурации
2) При автоматическом форматировании XML в редакторах, значения с zf-константами форматируются "криво" - переносятся на новые строки.

Решением проблемы (2) мы и займёмся.
Для начала скажу, что для разработки я использую Eclipse, а для загрузки файлов на сервер - ant-скрипт, который делает предварительную сборку файлов перед загрузкой на сервер. В нём же производятся некоторые действия над файлами, одно из которых я приведу ниже.

Определим правило, что константы вместо "<zf:const zf:name="константа">" в xml-конфиге будем описывать как "%ZF.константа%". для замены содержимого в файле, воспользуемся task-ом replaceregexp, выглядящий следущим образом:

<replaceregexp flags="g">
 <!-- заменяем "%ZF.константа%" на "<zf:const zf:name="константа" />" -->
 <regexp pattern="%ZF.(.*)%" />
 <substitution expression="&lt;zf:const zf:name=&quot;\1&quot; /&gt;" />
 <fileset dir="${target}/application/configs" includes="**/*.xml" />
</replaceregexp>

собственно на этом всё. :)
Итого: на этапе разработки мы получаем удобный XML, без "лишних" тегов, а на сервере правильный xml-конфиг с понятными для ZF константами

Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

воскресенье, июля 4

Maven2 и несколько серверов для WAR-архива. часть 1: работа с зависимостями

Предистория:
С недавних пор решил перебраться с Ant на Maven. Причины? они просты - в Maven неплохо реализована работа с зависимостями (которую я активно использую в Eclipse), но мне было неудобно каждый раз выискивать и копировать эти зависимости ручками на сервер (что тестовый, что "боевой"). В итоге было решено перебраться полностью. А там, где возможностей не хватает, то использовать Antrun плагин, позволяющий использовать ant-скрипты.

Итак, лирика закончилась. Приступим к реализации цели поста.

Имеется исходная задача:
1) набор зависимостей для проекта (здесь и далее подразумевается разработка WAR-архива)
2) "боевой" удалённый сервер
3) тестовый удалённый сервер (отличается от "боевого" настройками для отладки)
4) на серверах установлен Tomcat6 с настроенной поддержкой shared-lib


Первая проблема, с которой я столкнулся, была возможность указания в конфигурации единого правила для копирования зависимостей на разные сервера "по запросу".

Для определения dependency-библиотек, которые будут копироваться в shared-каталог tomcat, будем использовать указание scope как provided (подробнее про scope читать на русском тут)

Несколько продолжительные изыскания привели к следующей схеме профилей:

  • профиль "development" - указываем свойства, специфичные для сервера разработки, такие как пути и логины/пароли
  • профиль "production" - указываем свойства, специфичные для "боевого" сервера (всё те же пути и логины/пароли)
  • профиль "dependency" - в этом профиле описываем плагины (и их работу), отвечающие за копирование зависимостей на выбранный сервер
пример профиля "development" (для профиля "production" подставляются другие значения свойств):
<profile>
 <id>development</id>
 <properties>
  <hostname>servername.dev</hostname>
  <ssh.host>${hostname}</ssh.host>
  <ssh.username>логин</ssh.username>
  <ssh.password>пароль</ssh.password>
  <ssh.tomcat.lib.shared>/srv/tomcat/shared/lib</ssh.tomcat.lib.shared>
 </properties>
</profile>

Теперь перейдём к самому "сложному" - копированию зависимостей на сервер.
для этого потребуется 2 шага - сбор зависимостей и, собственно, само их копирование.

Для сбора зависимостей, воспользуемся плагином maven-dependency-plugin, для которого укажем некоторые нюансы его работы:
<plugin>
 <artifactId>maven-dependency-plugin</artifactId>
 <version>2.1</version>
 <executions>
  <execution>
   <id>10-copy-dependencies</id>
   <phase>process-resources</phase>
   <goals><goal>copy-dependencies</goal></goals>
   <configuration>
    <IncludeScope>provided</IncludeScope>
    <outputDirectory>${project.build.directory}/dependency</outputDirectory>
    <overWriteReleases>false</overWriteReleases>
    <overWriteSnapshots>false</overWriteSnapshots>
    <overWriteIfNewer>true</overWriteIfNewer>
   </configuration>
  </execution>
 </executions>
</plugin>

Кратко поясню, что здесь написано.
1) указано выполнение плагина с моими настройками на этапе работы с ресурсами (process-resources) проекта. подробнее про Lifecicle проекта можно глянуть тут
2) указываем, какие (IncludeScope) и куда (outputDirectory), а так же режим копирования

Теперь перейдём к шагу копирования полученных зависимостей на удалённый сервер. Для этого воспользуемся ant задачей scp
<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-antrun-plugin</artifactId>
 <version>1.4</version>
 <executions>
  <execution>
   <id>90-antrun-copy-dependencies</id>
   <phase>process-resources</phase>
   <goals><goal>run</goal></goals>
   <configuration>
    <tasks>
     <scp todir="${ssh.username}@${ssh.host}:${ssh.tomcat.lib.shared}" 
      password="${ssh.password}">
      <fileset dir="target/dependency" />
     </scp>
    </tasks>
   </configuration>
  </execution>
 </executions>
 <dependencies>
  <dependency>
   <groupId>ant</groupId>
   <artifactId>ant-jsch</artifactId>
   <version>1.6.5</version>
  </dependency>
  <dependency>
   <groupId>com.jcraft</groupId>
   <artifactId>jsch</artifactId>
   <version>0.1.42</version>
  </dependency>
 </dependencies>
</plugin>

Кратко поясню, что здесь написано:
1) Указано выполнение плагина maven-antrun-plugin с моими настройками на этапе работы с ресурсами (process-resources) проекта
2) Для выполнения плагина подключены необходимые зависиимости, доступные только на этапе работы плагина (требуются для scp-задачи)

Теперь описанные выше два плагина мы добавляем в профиль "dependency" следующим образом:
<profile>
 <id>copy-dependency</id>
 <build>
  <finalName>${hostname}</finalName>
  <plugins>
   <plugin>
    <artifactId>maven-dependency-plugin</artifactId>
    ...
   </plugin>
    <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-antrun-plugin</artifactId>
     ...
   </plugin>
  </plugins>
 </build>
</profile>

На этом конфигурирование Maven для проекта закончилось.

Следующий шаг - настройка запуска сборок в eclipse для проекта maven.
воспользуемся плагином m2eclipse и в диалоге Run>Run configurations... создадим 2 конфигурации:




В профиле мы указываем сразу 2 профиля - один (например "development") используется для предоставления свойств, а второй ("dependency") реализует процедуру копирования зависимостей на сервер согласно указанных свойств
Так же мы указываем 2 шага выполнения Maven - clean (очистка от предыдущей сборки) и работу с ресурсами (process-resources).

Итог:
создавая и комбинируя различные профили, можно добиться практически такой же гибкости как у Ant, при этом Maven "заставляет" нас придерживаться строгой структуры каталогов (что тоже можно немного изменить) и последовательностей сборки проекта.

Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

четверг, апреля 15

логические ошибки

"Слепо" доверять интеллектуальным подсказчикам IDE - зло!

простой пример появления логической ошибки:


пишем код:
if (cookies.length != 0) {
    for (int i = 0; i < cookies.length; i++) {
     isAuth = isAuth || cookies[i].getName().equalsIgnoreCase(paramCooikeAuth);
     break;
    }
   }
логическая ошибка - наличие break без условия прерывания. IDE (в данном случае, Eclipse) предлагает удалить "i++", как не требующуюся в цикле (всё равно не будет использована). "Слепо" соглашаемся Чуть позже замечаем ошибку про break и добавляем условие:
if (cookies.length != 0) {
    for (int i = 0; i < cookies.length;) {
     isAuth = isAuth || cookies[i].getName().equalsIgnoreCase(paramCooikeAuth);
     if (isAuth) break;
    }
   }
Но следом получаем вечный цикл for, так как отсутствует счетчик, удалённый ранее! Следствие: прежде чем согласиться на то, что предлагает IDE - подумайте, ПОЧЕМУ он это предлагает, ведь может так оказаться, что ошибка-то совсем не в том месте, где её "видит" IDE! UPD: в конечном итоге код всё равно сократился до (см. ниже), но как говориться, "осадок остался" :)
if (cookies.length != 0) {
    for (int i = 0; i < cookies.length; i++) {
     if (isAuth = cookies[i].getName().equalsIgnoreCase(paramCooikeAuth)) break;
    }
   }

Если вам пригодилась статья, то отправьте 5 рублей автору. Спасибо!

четверг, марта 4

Не запускается Lotus Designer 8.5 (Eclipse)

Выдаёт ошибку "platform command processor has encountered a problem".

Удалите файл com.ibm.designer.domino.personality.config.xml в каталоге "%NOTES_DATA%\workspace\.metadata\.plugins\com.ibm.rcp.personality.framework\personalityWindowState"

источник + проверено на себе :)

Мелочи про Eclipse

Разные приятные мелочи и полезности при работе с Eclipse

1) Проблема "Иконка в Linux не всегда показывается у приложения. Среда Gnome"
Просто скопировать файл ECLIPSE_HOME/icon.xpm в /usr/share/icons/eclipse.xpm

2) Изменение имени автора (@author) по-умолчанию.
При добавлении в JavaDoc описание ключа @author, автоматически подставляется имя текущего пользователя.
Добавьте в eclipse.ini после строки "-vmargs" строку "-Duser.name="Ваше_имя_автора"


понедельник, марта 16

Eclipse

Дабы не забыть, напишу сюда плагины, что стоят в Eclipse.

  • PDT - ("ушел" с PHP на Java)
  • QuickREx
  • RSE (Remote System Explorer) - после решения потребностей через maven, перестал быть нужным
  • m2eclipse - шустрый малый. делает ровно столько, сколько мне нужно и когда его попросишь
  • Spring IDE - проект "умер" :(
  • JBoss Tools - монстр, хотя и немного неуклюжий, но много умеющий.
  • Eclipse IAM (мне не понрался в usability). использую m2eclipse
  • Linux Tools
  • Checkstyle
  • Emonic - крайне редко, в виду ухода от .Net разработки под Mono