User's collector

Внимание!   Данная опция будет доступна только после того, как вы авторизуетесь.
   запомнить меня 

Недавно столкнулся со следующей задачей: на одном веб-сервере под управлением Windows Server 2003 необходимо было установить несколько экземпляров Apache Tomcat 6 для того, чтобы в каждом из них «крутилось» свое собственное приложение. Установить нужно было таким образом, чтобы каждый из этих сервлет-контейнеров являлся в системе обособленным сервисом со своей конфигурацией, параметрами автозапуска, отдельным пунктом в списке установленных программ системы, ну и, в качестве бонуса, собственной иконкой в трее. :)

Windows Server 2003 tray

Посмотрев решения подобной задачи в интернете, обнаружил, что, пожалуй, единственным способом ее решения будет самостоятельная правка реестра системы. Это связано с тем, что стандартный инсталлятор Apache Tomcat 6 не поддерживает возможности его установки в виде нескольких сервисов и не позволяет разнести настройки каждого из экземпляров по отдельным веткам реестра.

Здесь я хочу сделать важное предупреждение. Описываемая в статье техника является работоспособной и проверенной мной на собственном опыте и на реальном рабочем сервере. Она даже не является хаком, поскольку, будь инсталлятор немного более грамотным, он бы выполнял ее автоматически. Я не проверял, но скорее всего эта техника будет работать и на Windows Server 2008. Выполняемые процедуры не затрагивают никаких других настроек и веток реестра, кроме тех, которые непосредственно относятся к каждому отдельному сервису Apache Tomcat. Однако я не несу никакой ответственности за возможный ущерб, связанный с непосредственным, а так же с неосторожным или неправильным применением этой техники. Используйте ее на свой страх и риск. И не забудьте сделать резервную копию важных данных перед началом процедуры. :)

Итак, поехали.

  1. Установите первый экземпляр Apache Tomcat в отдельную директорию, например, в C:\Tomcat6_1. На последнем шаге мастера установки нужно убрать галочку Run Tomcat.
  2. Откройте редактор реестра regedit: StartRun…regedit → нажмите Enter.
  3. Переместитесь к ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tomcat6 и переименуйте ее из Tomcat6 в Tomcat6_1.
  4. Здесь же измените значение свойства DisplayName с Apache Tomcat на Apache Tomcat 6 (1). Именно под этим именем теперь будет отображаться сервис в списке локальных служб системы. Чтобы посмотреть список служб вашей системы выполните следующую последовательность действий: кнопка StartRun…services.msc → клавиша Enter.
  5. System services

  6. Теперь измените часть значения свойства ImagePath с …//RS//Tomcat6 на …//RS//Tomcat6_1. Именно с этим именем будет запускаться экземпляр службы. Это значение понадобится нам в шаге 9.
  7. Далее переходим к ветке HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat6 и переименовываем ее в Tomcat6_1. В дальнейшем это позволит нам установить новый экземпляр Apache Tomcat без перезаписи настроек устанавливаемого в настоящий момент экземпляра.
  8. По тем же самым причинам меняем название ветки HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\6.0 на 6.0_1.
  9. Теперь переходим к ветке HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run и меняем имя ключа с ApacheTomcatMonitor на ApacheTomcatMonitor_1. Это имя приложения по управлению службой. Его изменение позволяет нам избежать перезаписи этого ключа при установке следующих экземпляров Tomcat и управлять каждым из сервисов при помощи отдельного окна приложения.
  10. Service monitor

  11. Теперь изменим завершающую часть значения этого ключа с …Tomcat6 на …Tomcat6_1. Внимание: это значение должно совпадать с тем, которое мы присвоили ключу ImagePath в шаге 5.
  12. Для того, чтобы иметь возможность потом деинсталлировать по отдельности каждый из установленных экземпляров Tomcat, мы должны перейти в ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Apache Tomcat 6.0 и изменить ее название на Apache Tomcat 6.0_1. Это позволит нам избежать перезаписи данных, необходимых для деинсталляции приложения, во время установки последующих экземпляров Apache Tomcat. Здесь же можно изменить значение ключа DisplayName на Apache Tomcat 6.0 (1).
  13. Installed applications

  14. Перезагрузите систему, чтобы изменения вступили в силу.
  15. Для того чтобы распределить установленные экземпляры Tomcat по разным локальным портам, мы должны правильно сконфигурировать каждый из них. Открываем файл C:\Tomcat6_1\conf\server.xml и меняем значения следующих узлов:
    1. <Server port="8005" shutdown="SHUTDOWN"> на 8001 (для каждого из последующих сервлет-контейнеров мы будем использовать порты 8002, 8003 и т.д.).
    2. <Connector port="8080" protocol="HTTP/1.1"connectionTimeout="20000" redirectPort="8443" /> на 8081 (далее будем использовать 8082, 8083 и т.д.).
  16. Выполните инструкции с 1 по 12 для каждого из последующих экземпляров Apache Tomcat, используя для разделения каждого из них увеличенное значение индекса. Допустим, второй экземпляр должен быть установлен в папку C:\Tomcat6_2, ветка реестра из шага 3 должна быть переименована в Tomcat_2, а ключ DisplayName в шаге 4 изменен на Apache Tomcat (2) и т.п.
  17. Перезагрузите систему, чтобы удостовериться в том, что разные экземпляры Tomcat нормально запускаются во время старта Windows.

На этом все на сегодня. Буду надеяться, что заметка окажется вам полезной. Удачного вам дня! :)

Комментариев нет

Теги:

В этом посте каждый может задать вопрос, каким-либо образом относящийся к среде разработки Intellij IDEA, и получить на него вразумительный ответ. На русском. Развернуто и актуально. :)

Если вы уже давно присматриваетесь к этой среде разработки, либо даже пробовали перевести свой рабочий процесс на разработку в ней, но что-то у вас не получалось, не выходило, не настраивалось, вызывало недоумение, приводило в шок; и в результате чего вы так и не смогли взять этот неприступный бастион, этот редут интеллекта, этот ларец, доверху наполненный изумрудами программерской мудрости, и вынуждены были отказаться от использования среды на долгие месяцы и годы, то «вэлкам» внутрь поста. Попробуем вместе решить вашу проблему.

Со временем, если накопится достаточное количество вопросов, то на их основе будет создан Intellij IDEA FAQ, который, я думаю, окажется небесполезным многим разработчикам.

Ну а для начала, всем интересующимся этой темой я рекомендую ознакомиться вот с этим PDF-документом, полным цветных картинок и изумительных комментариев к ним (правда на английском). Ну и не забывайте задавать свои вопросы. :)

27 комментариев

Теги:

Все мы знаем, о таком замечательном методе, как toString(), имеющемся у любого объекта в языках, подобных Java и ActionScript. При попытке работы объектом, как со строкой, будет использовано возвращаемое именно этим методом значение. Поэтому мы можем в своих классах переопределять поведение метода, имеющееся у объекта по умолчанию, и возвращать свои собственные специализированные значения.

В этом отношении язык Groovy не стал исключением — в нем тоже все объекты имеют метод toString(), логику которого можно переопределять, как в собственных классах пользователя, так и в любом другом из уже имеющихся классов и объектов программы, при помощи свойства metaClass. Однако Groovy шагнул дальше — он позволяет нам похожим образом приводить объекты и к булеву значению, и, кроме того, к любому другому типу объектов в приложении.

Рассмотрим для начала ситуацию приведения объекта к булеву значению. Все просто — берете и переопределяете в своем классе (или посредством поля metaClass в объекте или классе, доступа к исходному коду которого у вас нет) метод asBoolean():

GROOVY:
  1. class User {
  2.     String username
  3.     Boolean active
  4.  
  5.     Boolean asBoolean() {
  6.         active
  7.     }
  8. }
  9. assert new User(username: 'mrFreeman', active: true)
  10. assert !new User(username: 'mrFreeman', active: false)
  11.  
  12. // Переопределяем метод в существующем классе посредством свойства metaClass.
  13. String.metaClass.asBoolean = {
  14.     delegate == /groovy/
  15. }
  16. assert !'true'
  17. assert 'groovy'

Ну и, как вы уже могли догадаться, аналогичным способом мы переопределяем метод asType(), чтобы тем самым сделать возможным приведение нашего объекта к любому нужному нам типу:

GROOVY:
  1. String.metaClass.asType = {Class type ->
  2.     if(type == User)
  3.     {
  4.         return new User(username: delegate)
  5.     }
  6.     null
  7. }
  8. assertEquals 'test', ('true' as User).username

Вот такие очень гибкие возможности предоставляет нам Groovy.

Комментариев нет

Теги:

Должно быть каждый Grails-программист, только начавший постигать премудрости метода «разработки приложения посредством тестирования», задается вопросом: «Для чего же в Grails существуют две разновидности тестов, и какая между ними разница?». Ведь на первый взгляд очевидной разницы между ними нет, кроме того, что Unit-тесты создаются в папке test/unit приложения, а интеграционные — в test/integration.

Однако все не так просто, как могло бы показаться. Начнем с Unit-тестов. Они потому так и называются, что производят тестирование очень маленьких частей приложения, единиц или юнитов функциональности: отдельных классов и их методов. Интеграционные тесты же специально разработаны для тестирования достаточно крупных частей приложения: таких, как контроллеры и все их зависимости. Но главное же отличие между этими разновидностями тестов заключается в том, что интеграционные тесты выполняются в контексте запущенного приложения — с одновременным запуском базы данных и доступом ко всем динамическим свойствам и методам, в которых может нуждаться тестируемый код. Т.е. буквально, интеграционные тесты интегрируются в запущенное приложение во время его тестирования. Поэтому отпадает необходимость в моккинге (англ. «mock» - имитирование, подражание).

Давайте рассмотрим более подробно, что будет, и что не будет работать при интеграционном тестировании:

  • все плагины, у которых не исключена возможность интеграционного тестирования, будут загружены;
  • код в классе BootStrap будет выполнен. Контекст Spring-приложения будет полностью развернут;
  • доменные классы будут взаимодействовать с реальной базой данных (по умолчанию, на этапе тестирования используется временная база данных HSQLDB);
  • все динамические свойства и методы, впрыскиваемые Spring, доступны на этапе тестирования;
  • будут использованы «моккнутые» версии свойств request (GrailsMockHttpServletRequest), response (GrailsMockHttpServletResponse) и session (MockHttpSession);
  • фильтры не будут работать;
  • URL-mapping не производит никакого эффекта;
  • нет поддержки тестирования видов (GSP-страниц).

Важной особенностью является то, что интеграционным тестам требуется гораздо больше времени для выполнения, чем Unit-тестам, поскольку в этом случае перед тем, как непосредственно выполнить интеграционные тесты, Grails необходимо осуществить запуск и развертывание приложения. Поэтому, из-за достаточно серьезной экономии времени, Unit-тесты являются более предпочтительными. Однако не стоит относиться с пренебрежением и к интеграционным тестам. Вот список тех ситуаций, когда они могут оказаться просто незаменимыми:

  • когда у вас нет возможности протестировать что-то посредством Unit-тестов;
  • когда вы хотите протестировать взаимодействия между различными объектами в приложении;
  • когда проще протестировать какой-либо функционал, взяв реальные данные из базы, чем «моккать» все подряд в приложении.

На этом все. Удачного вам погружения в физику и магию тестирования!

2 комментария

Теги:

Представим себе типичную ситуацию. Пусть в составе нашего приложении имеются два сервиса:

GROOVY:
  1. class PersonService
  2. {
  3.     def postService
  4.     void foo()
  5.     {
  6.         // …
  7.     }
  8. }

и

GROOVY:
  1. class PostService
  2. {
  3.     def personService
  4.     void bar()
  5.     {
  6.         personService.foo()
  7.     }
  8. }

Как мы видим, оба этих сервиса нуждаются во взаимной инъекции экземпляра другого сервиса и сохранении его в виде внутреннего свойства. С виду все правильно, однако, если мы попытаемся запустить наше приложение, то получим ошибку следующего характера:

CODE:
  1. Error creating bean with name '(inner bean)': Initialization of bean failed;
  2. nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException:
  3. Error creating bean with name 'postService':
  4. org.springframework.beans.factory.FactoryBeanNotInitializedException:
  5. FactoryBean is not fully initialized yet

Ошибка связана с тем, что Spring не может проинициализировать свойство, в которое требуется поместить ссылку на экземпляр объекта, нуждающийся в обратной ссылке на текущий объект. Классическая ситуация «курицы и яйца», по-другому не назовешь. :)

Как же решить проблему? Снимем обязанность по инъекции в одном из классов со Spring и прибегнем к ленивой инициализации свойства. А еще точнее в одном из сервисов сам процесс инъекции поместим в соответствующий геттер. Посмотрите на следующий листинг:

GROOVY:
  1. import org.springframework.context.ApplicationContext
  2. import org.springframework.context.ApplicationContextAware
  3.  
  4. class PostService implements ApplicationContextAware
  5. {
  6.     ApplicationContext applicationContext
  7.  
  8.     PersonService getPersonServiceBean()
  9.     {
  10.         applicationContext.getBean("personService") as PersonService
  11.     }
  12.    
  13.     void bar()
  14.     {
  15.         personServiceBean.foo()
  16.     }
  17. }

Итак, что же мы сделали:

  1. В сервисе PostService мы имплементировали интерфейс ApplicationContextAware.
  2. Добавили в класс инъекцию ApplicationContext.
  3. Вместо инъекции personService мы создали метод-геттер getPersonServiceBean, в котором посредством метода applicationContext.getBean() возвращаем ссылку на экземпляр нужного нам сервиса.
  4. В методе bar к экземпляру сервиса обращаемся посредством свойства personServiceBean, которое, по сути дела, является аналогом вызова геттера getPersonServiceBean(). Обратите внимание, что названием геттера является getPersonServiceBean, а не getPersonService. Тем самым при помощи переименовывания мы пресекаем любые попытки инъекций этого свойства со стороны Spring.

Код сервиса PersonService мы оставляем без изменений — с односторонними зависимостями Spring справляется очень даже хорошо. :) Тестируем приложение и проверяем, что теперь оно запускается без ошибок.

Вот и все на сегодня. Удачного вам дня!

Комментариев нет

Теги:

Давно хотел написать об этом, да все руки не доходили... На сайте JetBrains доступны два четыре относительно новых видеоурока, касающихся поддержки Flex в Intellij IDEA:

  1. «„Hello Flex“ with Intellij IDEA».
  2. «How to configure an Intellij IDEA project for creating a multilingual Flex application».
  3. «Advanced Flex Support in IDEA 8».
  4. «Working with BlaseDS».

Кстати, сам не проверял, но, насколько мне известно, начиная с версии 8.1.1 в IDEA появилась поддержка встраиваемой ASDoc-документации.

P.S.: с Днем Победы вас!

UPDATE: В список добавлены еще 2 урока. Спасибо nicity за информацию.

9 комментариев

Теги:

А знаете ли вы, что, начиная с версии 5, в Java появилась такая интересная «фишка», как импорт статических членов класса? Выглядит это следующим образом. Допустим, в нашем классе в нескольких местах используется метод Math.random(). Если поместить в начало класса следующий импорт:

JAVA:
  1. import static Math.random;

то мы можем в любом месте этого класса вызывать метод при помощи более короткой записи:

JAVA:
  1. double val = random();

Можно импортировать все статические члены класса, указав вместо названия конкретного поля или метода символ *:

JAVA:
  1. import static Math.*;

В Groovy импорт статических членов также поддерживается, но в более продвинутой форме — кроме указания имени импортируемого члена класса, можно указывать еще и псевдоним (англ. alias), через который этот член будет доступен в коде:

GROOVY:
  1. import static Math.random as rand

Таким образом, мы создали псевдоним rand и теперь можем через него производить вызов статического метода Math.random:

GROOVY:
  1. double value = rand()

Кстати, точно таким же образом в Groovy можно указывать псевдоним для импортируемого класса:

GROOVY:
  1. import groovy.lang.ExpandoMetaClass as EMC
  2. // ...
  3. def metaClass = new EMC(Integer)

В ActionScript 3 подобного функционала пока нет, но если он появится в будущих версиях, то этот язык станет чуточку более удобным.

7 комментариев

Теги:

Предлагаю вашему вниманию небольшой трюк по оптимизации Flex приложений.

Часто бывает необходимым наделить свой класс возможностью рассылать события, однако мы почти уверены, что подписываться на эти события объекты-получатели будут крайне редко. Поэтому не хочется наследовать в своем классе весь функционал flash.event.EventDispatcher и запускать «без дела» в коде своего класса распространение событий вызовом метода dispachEvent().

Как раз на этот случай во Flex 4 framework припасен утилитный класс mx.utils.OnDemandEventDispatcher, позволяющий улучшить производительность нашего приложения по двум направлениям:

  • OnDemandEventDispatcher не является наследником EventDispatcher, а только лишь реализует интерфейс IEventDispatcher. Класс посредством композиции делегирует выполнение методов, объявленных в интерфейсе, внутреннему экземпляру EventDispatcher. Сам же внутренний объект-диспетчер создается только в случае необходимости — при первой подписке на рассылку событий от текущего объекта. Таким образом, удается немного сэкономить занимаемый приложением объем оперативной памяти.
  • Если еще ни один объект не подписывался на получение событий, то делегирование методов внутреннему объекту-диспетчеру не производится. Тем самым, глубина стека выполнения функций ограничивается методами объекта-диспетчера. Это хорошо иллюстрирует листинг, взятый из класса OnDemandEventDispatcher:
    Actionscript:
    1. public function dispatchEvent(event:Event):Boolean
    2. {
    3.     if(_dispatcher != null)
    4.         return _dispatcher.dispatchEvent(event);
    5.     return true;
    6. }

Таким вот нехитрым образом, наследуясь там, где это необходимо, от класса OnDemandEventDispatcher мы хоть и ненамного, но все же улучшаем производительность нашего Flex приложения.

Комментариев нет

Теги:

Довольно часто приходится встраивать в ActionScript-приложения дополнительные шрифты, которых может не оказаться на компьютере конечного пользователя. Однако к этой операции нужно подходить со знанием дела. Зачастую совершенно нет необходимости во встраивании шрифта в ролик целиком — в большинстве приложений, с которыми мне приходилось иметь дело, достаточно было организовать поддержку латинских и кириллических символов в текстовых полях, не забывая, конечно же, о цифрах и символах пунктуации. Таким способом можно сократить размер итогового SWF-ролика на несколько десятков килобайт.

Уже достаточно длительный период времени я компилирую приложения при помощи Flex SDK, прибегая к Flash IDE только лишь для того, чтобы встроить векторную графику. Поэтому и речь в этой статье пойдет о том, как встраивать шрифты в приложениях, компилируемых именно таким способом.

Для того чтобы справиться с этой задачей, мы обращаемся к документации по метатэгу Font и видим, что одним из его атрибутов является unicodeRange. Именно при помощи этого атрибута мы можем указывать Unicode-значения символов шрифта (а так же интервалы значений символов), которые компилятор должен встроить в ролик. Прибегнув к таблице символов Unicode, определяем, что нам необходимо импортировать следующие символы:

  • U+0020-U+007F — основная латиница;
  • U+00A0-U+00FF — дополнительные символы, которые могут понадобиться (вроде знака © или русских кавычек-елочек);
  • U+0400-U+04FF — кириллические символы верхнего и нижнего регистров.

Если собрать все вместе, то код для встраивания шрифта должен быть примерно следующим:

Actionscript:
  1. [Embed(source="/../assets/fonts/CHR56__C.TTF",
  2.     fontFamily="CharterC_i", fontStyle="italic",
  3.     unicodeRange="U+0020-U+007F, U+00A0-U+00FF, U+0400-U+04FF")]

Если вам есть чем дополнить эти интервалы символов, то добро пожаловать в комментарии. Вполне возможно, что я что-то упустил. :-)

4 комментария

Теги:

Многие знают, что, за исключением Flex Chartings (платных компонентов для построения графиков), Adobe Flex SDK распространяется в виде открытых исходных кодов. Это означает, что вы всегда можете:

  • посмотреть логику работы того или иного компонента;
  • исправить найденную в SDK ошибку;
  • послать разработчикам патч, исправляющий эту ошибку;
  • самостоятельно скомпилировать из исходников рабочую версию SDK.

Доступ к исходникам Flex SDK предоставляется посредством системы контроля версий SVN, и вы всегда можете загрузить их, обратившись к trunk-у по следующему URL-адресу.

Вы спросите: «Для чего мне это нужно, если можно скачать одну из уже скомпилированных сборок Flex 4 SDK с сайта Adobe, и не придется проделывать никаких дополнительных манипуляций?». Самостоятельная сборка SDK на основе рабочей копии, полученной из системы контроля версий, обладает следующими преимуществами:

  • сюда относится весь предыдущий список возможностей;
  • на вашем компьютере всегда будет самая свежая сборка Flex 4 SDK;
  • для этого вам не нужно будет каждый раз заново скачивать весь архив со сборкой — достаточно будет только обновить измененные разработчиками исходные файлы и перекомпилировать SDK. Это особенно критично, если вдруг вы окажетесь в таком месте, где в наличии есть только медленное и нестабильное соединение с сетью;
  • вы сможете отслеживать и быть в курсе того, над какими элементами трудились в последнее время разработчики Flex 4 SDK.

Однако не нужно забывать о том, что в trunk-е может оказаться нерабочая версия SDK. В этом случае вам нужно будет откатиться на одну из предыдущих ревизий. Немного позже я объясню, как это сделать. Для начала наладим весь процесс сборки. Т.к. я все еще являюсь замшелым «виндузятником» и никак не могу пересесть на другую операционную систему, то весь описываемый процесс будет ориентирован на пользователей Windows. Думаю, пользователи других операционных систем смогут по аналогии с этой статьей настроить сборку на своих компьютерах.

Первым делом нам нужен хороший SVN-клиент, который позволит загрузить исходники из хранилища. Если у вас уже установлена подобная программа, вы можете пропустить этот шаг. Я уже достаточно давно в качестве подобного клиента под Windows использую TortoiseSVN, который встраивается в оболочку операционной системы и позволяет работать с файлами и папками в Проводнике при помощи контекстного меню, появляющегося по щелчку правой кнопкой мыши. Скачиваем и устанавливаем программу. Обратите внимание, что на странице загрузки программы есть множество языковых пакетов (в том числе и русский), позволяющих локализовать язык интерфейса программы. Далее перезагружаем ОС.

Создаем папку, в которой будет располагаться Flex 4 SDK. Я рекомендую создать ее в корне логического диска или файловой системы, а из названия папки исключить пробелы. Например, создать папку c:/flex_sdk_4. Это обусловлено тем, что в таком случае будет удобнее работать с SDK через командную строку.

Щелкаем правой клавишей мыши по папке и в контекстном меню выбираем пункт TortoiseSVNSVN Checkout… (SVN Извлечь…). В появившемся диалоговом окне указываем адрес до папки trunk Flex 4 SDK, глубину охвата при извлечении указываем Fully recursive (Полностью, рекурсивно) и выбираем пункт HEAD revision (HEAD-ревизия) для извлечения. Нажимаем кнопку OK и идем пить кофе, пока будут извлекаться исходные коды Flex SDK.

Теперь нам необходимо установить и настроить Apache Ant (страничка на Википедии) — очень полезный инструмент, позволяющий разработчикам автоматизировать различные процессы во время сборки и тестирования своих приложений. В свою очередь, разработчики Adobe Flex SDK автоматизировали процесс сборки Flex 4 SDK при помощи этого инструмента. Загружаем архив с программой и распаковываем его содержимое в папку C:\Program Files\Ant\. Теперь прописываем путь к папке bin в переменную среды Path. Для этого щелкаем правой клавишей по иконке Мой компьютер и в появившемся меню выбираем пункт Свойства. Переходим на вкладку Дополнительно и нажимаем кнопку Переменные среды. В списке Системные переменные так же через точку с запятой добавляем путь C:\Program Files\Ant\bin к переменной Path. Нажимаем, где нужно, кнопки Применить и OK. Перезагружаем Windows.

Компиляторы Flex SDK представляют собой программы, которые компилируются и работают в среде Java. Поэтому нам нужно установить на свой компьютер JDK. Для этого идем на сайт компании Sun и скачиваем последнюю версию Java SE Development Kit. На момент написания статьи такой версией была JDK SE 6.12. После окончания загрузки устанавливаем среду. Во время всей процедуры инсталляции можно руководствоваться действиями мастера установки по умолчанию. После завершения установки, снова открываем окно редактирования переменных среды и добавляем переменную JAVA_HOME в список системных переменных, а ее значением устанавливаем строку с путем к папке JDK: C:\Program Files\Java\jdk1.6.0_12.

Остался последний этап подготовки системы к компиляции Flex 4 SDK. Дело в том, что во время сборки Flex 4 SDK производится выполнение нескольких UNIX-овых shell-скриптов, которые, естественно, не будут работать под Windows, однако без проблем выполнятся под Mac OS и Linux. Но этот пункт тоже решаем. В корневой папке Flex 4 SDK находится файл README.txt, который содержит строку «This version of Flex is officially built in Cygwin on Windows XP Pro SP2». Т.е. разработчики в Adobe так же собирают SDK под Windows, единственной тонкостью является наличие в системе установленного Cygwin (страничка на Википедии) — эмулятора командной строки UNIX. Устанавливаем Cygwin, воспользовавшись для этой цели специальным загрузчиком и инсталлятором. Для установки указываем папку, находящуюся в корне логического диска. Путь к этой папке не должен содержать пробелов. Можно воспользоваться путем, предлагаемым по умолчанию: C:\cygwin\.

После установки запускаем консоль Cygwin, переходим в папку с исходными кодами Flex 4 SDK и запускаем сборку при помощи Apache Ant:

CODE:
  1. Yuriy@Yuriy-laptop ~
  2. $ cd /cygdrive/c/flex_sdk_4/
  3.  
  4. Yuriy@Yuriy-laptop /cygdrive/c/flex_sdk_4
  5. $ ant

Осталось дождаться окончания билда и собранная своими руками копия Flex 4 SDK готова к работе!

Чтобы синхронизировать свою рабочую копию Flex 4 SDK с теми изменениями, которые внесли в trunk разработчики, необходимо выбрать пункт SVN Update (Обновить) в контекстном меню папки с рабочей копией, дождаться завершения процесса обновления и пересобрать проект. Таким образом вы всегда будете иметь на своем компьютере самую свежую версию Flex 4 SDK.

Теперь пару слов о том, что нужно делать, если вдруг вы обновились до нестабильной ревизии в хранилище Flex 4 SDK. Щелкаем правой клавишей по папке с локальной рабочей копией Flex 4 SDK и в контекстном меню выбираем пункт TortoiseSVNUpdate to revision… (Обновить до ревизии…), в появившемся окне переключитесь на пункт Revision (Ревизия), введите номер одной из предыдущих стабильных ревизий в текстовое поле и нажмите кнопку OK. После завершения обновления пересоберите Flex 4 SDK.

На этом статья закончена. Желаю вам удачных экспериментов с новой версией Flex SDK!

22 комментария

Теги: