Использование Maven для настройки проекта Drupal PHP

чего я хочу достичь?

в настоящее время мы работаем над проектом PHP, которая использует Друпал.

Я отчаянно хочу узнать, как создать один шаг построить для всего проекта. Предпочтительно, используя что-то новое (для меня), которое кажется очень мощным: Maven

в основном я хочу автоматизировать следующий процесс:

  1. проверка Drupal от официального CVS хранилище.
  2. проверка официальных сторонних модулей из их соответствующих репозиториев CVS.
  3. проверьте наши пользовательские модули из нашего репозитория mercurial.
  4. скопируйте / переместите все модули в соответствующий каталог в Drupal.
  5. оформить заказ и установить нашу тему.
  6. добавить пользовательский профиль установки drupal.
  7. создать новую схему базы данных MySQL.
  8. если возможно, автоматизируйте Друпал настройки подключения к БД.

в будущем я хотел бы запустить эту сборку на сервере интеграции Hudson (или любом другом).

Почему Maven? (почему не муравей или Phing?)

кроме желания узнать что-то новое (я использовал Ant раньше), я думаю, что управление зависимостями Maven может хорошо работать для модулей drupal.

вы думаете, что это достаточная причина для использования Maven, хотя Maven не был первоначально предназначен для проектов PHP? Я знаю, что Ant изначально не использовался для PHP, но есть гораздо больше примеров людей, использующих Ant и PHP вместе.

кстати, я думаю, что переключусь на Ant, если я не смогу заставить Maven работать в ближайшее время. Процедурный стиль Ant просто легче для меня понять.

что у меня есть до сих пор?

у меня есть пом.xml-файл, который использует плагин SCM, для проверки источника drupal. Когда я бегу:

mvn scm:checkout

источник выписывается в новый каталог:

target/checkout

когда я пытаюсь:

mvn scm:bootstrap

он жалуется на то, что цель установки не определена.

вот пом.XML-код:

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.example</groupId>
  <artifactId>drupal</artifactId>
  <version>1.0</version>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-scm-plugin</artifactId>
          <version>1.1</version>
          <configuration>
            <username>anonymous</username>
            <password>anonymous</password>
          </configuration>
      </plugin>
    </plugins>
  </build>
  <scm>
    <connection>scm:cvs:pserver:cvs.drupal.org:/cvs/drupal:drupal</connection>
    <developerConnection>scm:cvs:pserver:cvs.drupal.org:/cvs/drupal:drupal</developerConnection>
    <tag>DRUPAL-6-12</tag>
    <url>http://cvs.drupal.org/viewvc.py/drupal/drupal/?pathrev=DRUPAL-6</url>
  </scm>
</project>

и, наконец, каковы мои вопросы?

  • Maven неправильный инструмент для этого?

если нет,

  • как бы вы это сделали?
  • это scm:bootstrap цель, которую я должен использовать?
  • что способ перемещения каталогов Maven в файловой системе?
  • должны install цель будет использоваться для перемещения модулей в каталог drupal?
  • в настоящее время все наши пользовательские модули находятся в одном репозитории Mercurial. Можно ли создать pom.xml и проверка каждого модуля индивидуально?
  • любой общий совет был бы признателен.

Спасибо за ваше время!

5 ответов


Наверняка вы не используете Maven, вот некоторые мысли:

  • Maven-это инструмент сборки Java и программное обеспечение для управления зависимостями с четко определенным жизненным циклом, который выглядит так: проверка, компиляция, тест, пакет, интеграция-тест, проверка, установка, развертывание. То, что вы используете, - это плагин scm, который может stick на любой из этапов, определенных здесь, и выполните некоторые действия, но если вы не сделаете сложных изменений в POM (я не слышал, чтобы кто-то делал это) жизненный цикл будет продолжать выполняться.
  • Maven также предназначен для упаковки банок, войн и с использованием некоторых плагинов EARs, SARs ,RARs (не это RARs) и некоторые другие файлы; возможно, вам придется запрограммировать новый плагин, чтобы получить тип пакетов, которые вы ожидаете или используете сборка плагин, который сделает вещи более сложными.

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

после прочтения того, что вы хотите сделать с вашим проектом, я бы предложил вам создать сценарий (сценарий оболочки или пакетный скрипт в зависимости от вашей ОС) для выполнения этой работы. SVN и CVS имеют инструменты командной строки, которые могут быть вызваны из вашей сборки файлы сценариев. Я думаю, вы выбрали Maven, среди других причин, потому что Хадсон и многие другие программы непрерывной интеграции хорошо интегрированы с ним, но вы можете использовать их со сценариями тоже.

Если вам удобно использовать Ant, и вы считаете, что его использование облегчит время создания вашего приложения, я думаю, не так плохо ;) (я не использовал Ant для других целей, кроме проектов Java)


Я на 98% уверен, что вам действительно нужно Drush Make, которые могут рекурсивно создавать проекты Drupal при условии, что они предоставляют свои собственные .сделать файл со списком зависимостей. Он может загружать из нескольких файлов SCMs, web, patch, и вы можете контролировать, где они загружаются. Он также поддерживает внешние библиотеки, такие как WYSIWYG, PHP-файлы или библиотеки JS.

посмотреть "Открыть" Атриум make-файл для пример того, что он может сделать.


на Drush 'module' - отличный инструмент для создания сценариев в Drupal. Но, помимо этого, я думаю, что ваш подход к выполнению проверок CVS для каждой "сборки" немного отличается от базы - если у вас нет действительно веских причин иметь каждый кусок проекта в отдельном репозитории, лучше всего иметь фиксированные проверки Drupal core & contributed modules, совершенные в репозитории вашего проекта. Это не только устраняет зависимость от сетевого подключения и стабильность внешнего сервера, но это позволяет вам иметь локальные модификации внесенных модулей (к сожалению, вы, вероятно, в конечном итоге будете делать это где-то вниз по линии).

Как только вы вынете требование делать проверки из нескольких репозиториев, вы, вероятно, заметите, что ваша задача становится намного проще, оставляя вас с некоторыми простыми манипуляциями MySQL и выписыванием настроек.РНР.


проект http://www.php-maven.org know поставляется с плагином сборки, позволяющим миру php maven (или миру maven для проектов php). Снимок версии 2 можно найти в наших группах google (поток новостей доступен по адресуhttps://groups.google.com/group/maven-for-php/t/e055e49c89ccb8c5?hl=de).

однако это дает вам полный контроль над проектом и уважает жизненный цикл maven по умолчанию, чтобы maven команды:

  • mvn чистый
  • mvn пакет
  • mvn развернуть
  • сайт mvn

будет работать правильно.

поддержка Drupal может быть включена в версии 2.1, где мы сосредоточены на фреймворках (zend, flow3...) и типы проектов (web, cli, libs...). Было бы намного прояснить, что такое maven и как это может помочь вам во время разработки php. Как заявил Вистор Хьюго на своем раннем комментарии, преимущества Mavens заключаются не только в выполните определенную команду вручную, но внедрить всю структуру проекта и весь жизненный цикл проекта через maven. Поскольку большинство php-парней еще не имели контакта с java и особенно maven, мы создаем учебники, чтобы у всех была довольно простая запись в мире maven.


Я люблю maven, хотя я думаю, что это очень специфическая java, как упоминалось выше.

Я имел успех для обработки задач repeable с пхинг. Я использовал в проекте Zend для подготовки сборки или просто закрепления обычных задач (например. очистить БД, загрузить дамп БД).

Phing не обеспечит вам полное управление жизненным циклом как maven, но вы можете написать сами вручную. Можно внедрить команды сценария оболочки для построения.xml, чтобы вы могли использовать все, что вы использовали бы в обычном сценарий оболочки. Я предпочитаю phing над обычным скриптом оболочки, потому что он может обрабатывать зависимые цели, поэтому, если ваша сборка.xml содержит хорошо разработанные цели, которые зависят друг от друга, вы получите очень полезные цепочки для достижения указанных целей.

Это работает для меня.

еще один отличный инструмент для drupal-drush, который делает администрирование drupal скриптовым. Вы можете делать много конкретных вещей drupal с консоли. Я думаю, вы можете вызывать команды drush из сценариев phing.