За управление проектом, судя по всему, взялся Илья Харламов, но пока никакой активности не видно — на Google Code лежат только сами исходники, без готовой сборки и даже без скриптов для сборки. Так что есть две возможности — либо скачивать XULPIX с блога первоначального разработчика и пользоваться как есть, благо практически все работает, либо тормошить Илью Харламова, чтобы он привел проект в порядок или, хотя бы, принял в проект разработчика, готового что-то делать.

Сам редактор описывать не буду, лучше один раз увидеть, на YouTube лежит пара роликов:

Firefox покажет результат здесь:

Исходный текст:

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin" type="text/css"?>
<?xml-stylesheet href="mycss.css" type="text/css"?>
<window title="test01.xul" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
 <groupbox>
  <caption label="Underline problem"/>
  <label style="color: red;text-decoration: underline">Text as element content: underline doesn't work.</label>
  <label style="color: red;text-decoration: underline" value="Text as an element attibute: underline works!"/>
 </groupbox>
 
 <groupbox>
  <caption label="Blink problem"/>
   <label style="color: red;text-decoration: blink">Text as element content: blink works!</label>
   <label style="color: red;text-decoration: blink" value="Text as an element attribute: blink doesn't work."/>
  </groupbox>
</window>

Пример подсмотрен на форуме xulfr.org.

Все это подтолкнуло к упрощению процесса сборки — переходу обратно на Apache Ant. При этом требования к окружению свелись к минимуму — должен быть установлен Sun JDK, Ant правильной версии (1.7) и «большие» библиотеки (типа Eclipse).

Конечно, Ant требует описания процесса сборки для каждого проекта, а в Maven для проектов стандартной структуры стандартная сборка уже описана. Ну что ж, пришлось оформить описание сборки виде библиотеки. Теперь на новый простой проект трачу не больше времени, чем при использовании Maven. Библиотека опубликована под именем Buildbase, уже достаточно функциональна и стабильна, но как самостоятельный проект не рекламируется.

Второе преимущество Maven — управление зависимостями: описание зависимостей, скачивание недостающих артефактов из репозитория и т.п. Сначала я нашел простенькую библиотеку и временно перевел все на нее. Затем разобрался с Ivy и понял, что реализация управления зависимостями в этом инструменте сделана гораздо грамотнее, чем в Maven. Написать про Ivy обещал уже давно, мешала одна непонятность — не мог понять, как использовать локальный кэш зависимостей. Месяц назад разобрался и с этим, читайте Getting Started with Ant+Ivy.

Ivy — это официальный подпроект Apache Ant. Надеюсь, скоро он переедет из Инкубатора на свое законное место — в середине декабря вышла beta1, я же без проблем пользуюсь alpha2.

Подключить Ivy к Ant очень просто, для этого надо:

1. Описать внешние артефакты, необходимые для сборки проекта.
2. Описать репозитории, из которых эти артефакты можно получить.
3. Вставить в build.xml вызов задач Ivy, которые обеспечат получение этих артефактов.

Делай раз, файл ivy.xml, который находится в корне проекта (там же, где build.xml):

<ivy-module version="1.3">
    <info organisation="unitesk" module="treedl"/>
    <configurations>
        <conf name="src"/>
        <conf name="jar"/>
        <conf name="all" extends="src,jar"/>
        <conf name="build" visibility="private"/>
        <conf name="runtime"/>
    </configurations>
    <publications>
        <artifact type="jar" ext="jar" conf="jar"/>
        <artifact type="src" ext="zip" conf="src"/>
        <artifact type="all" ext="zip" conf="all"/>
    </publications>
    <dependencies>
        <dependency org="" 
                    name="antlr"        
                    rev="2.7.7"               
                    conf="jar->default; runtime->default"/>
 
        <dependency org="unitesk" 
                    name="atplib"       
                    rev="3.6.5-stable-070809" 
                    conf="jar->default; runtime->default"/>
 
        <dependency org="" 
                    name="xml-resolver" 
                    rev="1.2"                 
                    conf="all->default; build->default"/>
 
        <dependency org="" 
                    name="saxon"        
                    rev="6.5.3"               
                    conf="all->default; build->default"/>
    </dependencies>
    <conflicts>
        <manager name="strict"/>
    </conflicts>
</ivy-module>

В начале перечислены конфигурации проекта — собирается ли source distribution (src), jar или полный дистрибутив (all), который включает в себя и то, и другое.
build — это конфигурация, которая определяет зависимости, необходимые только при сборке. runtime — зависимости, которые потребуются для запуска.
То есть, конфигурации используются для разных целей — и для входа, и для выхода. Врать не буду, сильно я в этом не разбирался. Можно, наверное, и еще сократить эту секцию. Впрочем, работает и ладно.

dependency — это, собственно, зависимость. Имя, версия — тут, вроде, все понятно. По этим атрибутам строится имя артефакта. Если оно другое, внутри dependency можно указать artefact, изучайте документацию.

Делай два, файл ivyconf.xml, который также находится в корне проекта (там же, где build.xml):

<ivy-module version="1.3">
    <ivysettings>
        <settings defaultResolver="chained"/>
        <resolvers>
            <chain name="chained" returnFirst="true">
                <cache name="cacheResolver"/>
                <url name="treedl">
                    <artifact pattern="http://treedl.org/repository/[artifact]/[type]s/[artifact]-[revision].[ext]"/>
                </url>
                <ibiblio name="ibiblio"/>
            </chain>
        </resolvers>
   </ivysettings>
</ivy-module>

Тут определены репозитории, в которых Ivy будет искать зависимости (вернее, резолверы, которые умеют искать в этих репозиториях. Но уж больно слово неуклюжее, а смысл и так ясен). Начнем с конца.

• ibiblio — это стандартный Maven репозиторий на ibiblio. Если используется только он, ivyconf.xml, вроде, вообще не нужен.
• url — это удаленный репозиторий, для которого задан шаблон поиска артефактов. Параметрами шаблона являются атрибуты из ivy.xml.
• cache — это самый нужный репозиторий, который почему-то толком не описан — локальный кэш, куда Ivy скачивает зависимости перед тем, как скопировать их в заданную папку проекта.
• chain — объединяет вышеперечисленные репозитории в список. Если returnFirst="false", то поиск будет производиться по всем перечисленным репозиториям, даже если артефакт уже найден. Поэтому рекомендую ставить returnFirst="true", разрешение зависимостей будет выполняться быстрее.

Делай три, в build.xml добавляем инициализацию Ivy и скачивание зависимостей:

  <target name="setup.ivy">
    <path id="ivy.lib.path">
      <fileset dir="${ivy.dir}" includes="${ivy.jar}"/>
    </path>
    <taskdef resource="fr/jayasoft/ivy/ant/antlib.xml" 
             uri="antlib:fr.jayasoft.ivy.ant" 
             classpathref="ivy.lib.path"/>
    <ivy:settings/>
  </target>
 
  <target name="get.dependencies" depends="setup.ivy">
    <ivy:settings id="ivy.instance"/>
    <ivy:resolve/>
    <ivy:retrieve conf="runtime" pattern="${ivy.retrieve.runtime.pattern}"/>
    <ivy:retrieve conf="build" pattern="${ivy.retrieve.build.pattern}"/>
  </target>

Первая цель определяет задачи, определенные в пространсте имен «ivy». Вторая — скачивание зависимостей:

• ivy:settings — считывание настроек Ivy.
• ivy:resolve — поиск зависимостей в репозиториях.
• ivy:retrieve — собственно, скачивание зависимостей для заданной конфигурации. Атрибут pattern задает место назначения для скачанных артефактов. Значения этих атрибутов могут быть примерно такими:

  ivy.retrieve.runtime.pattern = ${libs.dir}/[artifact].[ext]
  ivy.retrieve.build.pattern   = ${tools.dir}/[artifact].[ext]

Вот, собственно, и все минимальные дополнительные расходы для автоматического скачивания зависимостей. Можно ещё добавить в build.xml автоматическое скачивание самого Ivy, тогда предустанавливать придется только Ant:

  <target name="init.ivy" depends="init.properties">
    <property name="ivy.version" value="2.0.0-alpha2-incubating"/>
    <property name="ivy.dir" value="${buildbase.basedir}"/>
    <property name="ivy.jar" value="ivy-${ivy.version}.jar"/>
    <property name="dir.ivy.jar" value="${ivy.dir}/${ivy.jar}"/>
 
    <available property="ivy.used" file="${ivy.dep.file}"/>
 
    <condition property="ivy.uptodate">
      <or>
        <not>
          <isset property="ivy.used"/>
        </not>
        <available file="${dir.ivy.jar}"/>
      </or>
    </condition>
 
  </target>
 
  <target name="get.ivy" depends="init.ivy" unless="ivy.uptodate">
    <mkdir dir="${ivy.dir}"/>
    <!-- download Ivy from web site so that it can be used even without any special installation -->
    <echo message="installing ivy..."/>
    <get src="http://???????/repository/ivy/jars/${ivy.jar}"
         dest="${dir.ivy.jar}"
         usetimestamp="true"/>
  </target>

Резюме:

• Ivy имеет богатую функциональность и очень гибко настраивается — можно приспособить под любые нужды.
• Ivy — подпроект Apache Ant, что гарантирует развитие и поддержку.
• Документация по Ivy в настоящий момент несколько неполна и неактуальна. Есть надежда, что к выходу из Инкубатора ситуация улучшится.

То ли владельцы блогов по большей части далеки от знания стандартного программистского инструментария, то ли это настолько само собой разумеется, что все молчат. И хаки всякие распространяются не в стандартной форме патчей, а в виде словесного описания.

В общем, в моем списке дел появились две записи:

1. Упрятать код WP этого сайта в Subversion.
2. Найти удобную PHP IDE. (PHPEclipse?)

http://www.collab.net/ — CollabNet (бесплатно на 15 разработчиков)

http://gforge.org/ — GForge (бесплатно на 15 разработчиков)

https://gna.org/projects/savane/ — Savane (GNU General Public License V2 or later, количество разработчиков неограничено)

Вспомните http://sourceforge.net чтобы понять, что эти продукты такое в первом приближении.

Все хотят LAMP (Linux, Apache, MySQL, PHP). Но Savane удалось установить на Windows 2003 Server (по крайней мере frontend). Доработка напильником потребовалась, но хватило и моих нулевых навыков в этой области.