Простейший xml файл Phing для сборки пакета расширений Joomla

  • 30.05.2015

Мир меняется, и веб-разработка меняется вместе с ним, еще 3 года назад я даже не думал о GIT, как инструмента для разработки расширений, сейчас я уже не могу помыслить, как можно разрабатывать, что-то и при этом не использовать GIT. Не так давно собирая пакет расширений Joomla состоящий из 22 расширений в ручную, я подумал "Какого...", до сих пор делаю это в ручную, ведь это иногда занимает очень много времени и посвятил несколько часов своего времени изучению Phing.

Первой проблемой с которой я столкнулся - это установка Phing на Windows - эта статья поможет вам установить его в windows окружении.

Вторая проблема - формирование xml файла, который бы позволил автоматически собирать пакет, как раз об этом мы и поговорим в этой статье.

Создаем файл для сборки пакета

Я рекомендую использовать имя файла build.xml. Вы можете использовать любое название, но тогда вам придется указывать в командной строке имя файла при наборе команды phing.

Что написать внутри файла для сборки?

<project name="slogin" default="dist" basedir=".">
	<property name="build" value="build" />
	<property name="dist" value="dist" />
	<property name="filename" value="pkg_slogin_v2.2_j2.5_j3.zip" />


	<target name="init" depends="clean">
		<mkdir dir="${build}" />
		<mkdir dir="${dist}" />
	</target>

	<target name="pack-plugins">
		<zip destfile="${build}/mod_slogin.zip" description="mod_slogin">
			<fileset dir="mod_slogin" />
		</zip>
		<zip destfile="${build}/com_slogin.zip" description="com_slogin">
			<fileset dir="com_slogin" />
		</zip>
		<zip destfile="${build}/lib_slogin_oauth.zip" description="lib_slogin_oauth">
			<fileset dir="libraries/slogin" />
		</zip>
		
		<copy file="pkg_slogin.xml" todir="${build}" />

	</target>
	
	<target name="dist" depends="init, pack-plugins">
		<zip destfile="${dist}/${filename}">
			<fileset dir="${build}/" >
				<include name="**/**" />
			</fileset>
		</zip>
	</target>

	<target name="clean" description="clean up">
		<delete dir="${build}" />
		<delete dir="${dist}" />
	</target>
</project>

В этом коде я привел пример содержимое файла для сборки пакета нашего расширения Slogin. Объясню, как это работает. Создаются папки "build" и "dist", последовательно берется папки из секции "pack-plugins", архивируются и складываются в папку "build", за тем в эту же папку копируется файл pkg_slogin.xml. И после этого берутся все файлы в папке "build" упаковываются в архив который называется "pkg_slogin_v2.2_j2.5_j3.zip" и копируется в папку "dist". При перезапуске файла сборки, папки "build" и "dist" отчищаются.

На что обратить внимание?

<property name="filename" value="pkg_slogin_v2.2_j2.5_j3.zip" />

pkg_slogin_v2.2_j2.5_j3.zip - это название конечного пакета расширения.

<target name="pack-plugins">

Секция pack-plugins содержит список папок, которые мы архивируем, каждая папка архивируется такой конструкцией:

<zip destfile="${build}/mod_slogin.zip" description="mod_slogin">
	<fileset dir="mod_slogin" />
</zip>

Где:

${build}/mod_slogin.zip - путь до конечного файла после упаковки.

description="mod_slogin" - описание файла, должно быть уникальным.

dir="mod_slogin" - папка которую мы упаковываем, путь определяется относительно корня директории, где лежит файл xml файл сборки.

Собственно на этом можно считать урок законченным, в конечном итоге мы получили очень простой файл, на редактирование, которого у вас уйдет несколько минут, а в последствии вы сможете пересобрать пакеты расширений за считанные секунды.

Это интересно:

Вадим Куницын
Россия , Калининград , 32 года

Комментарии  

Иван
-1 # Иван 02.06.2015 00:31
А не лучше собрать рабочую сборку на локальном сервере, акебой заархивировать и ставить на здоровье сборку. Максимум обновить все расширения которые могли устареть за прошедшее время. И все собственно! Зачем этот "секс"?
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
0 # Вадим Куницын 02.06.2015 17:49
Вы точно понимаете, про что тут речь, тут речь? Тут говорит про то, что мне для релиза расширений, чтоб собрать пакет, нужно провести около 30 операций. Упаковать один плагин второй... а тут я запускаю один файл только и у меня на выходе уже готовый пакет расширения, который я могу поместить для скачивания. Как вы собираетесь сборку Joomla распространять, для обновлений или для новых установок, я не понимаю.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Артем
0 # Артем 02.06.2015 15:13
А можно список 22 расширений? :)
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
0 # Вадим Куницын 02.06.2015 17:50
Вот полный файлик для Slogin. Там как раз 22 расширения в пакете.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
mavik
0 # mavik 07.06.2015 16:27
Phing действительно очень полезная вещь, особенно когда надо собрать сразу много расширений. В моем случает из было 23. Писал об этом чуть более года на зад на хабре, может кому будет интересно habrahabr.ru/post/212165/
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
0 # Вадим Куницын 08.06.2015 16:08
Очень интересная статья, жалко, что я на нее не наткнулся раньше :-) пришлось постигать все на других примерах.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
SmetDenis
0 # SmetDenis 08.08.2015 16:59
Архивы собираются не из репы по тегу, а локальной папки? Если да, то не учитываются случайные изменения в коде?
А как же запуск тестов? Как минимум phpunit ...
Получается, что используете phing только для архивации и возни с файлами? Он способен на большее.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
mavik
0 # mavik 08.08.2015 18:03
Правильно, конечно, пишете. Если развивать тему, то можно и тестовую инсталяцию, и функциональное тестирование, и выкладывание в JED сделать. А заодно выполнить запуск спутника, чтобы он свысока все это мониторил :lol:
А на самом деле у каждого свои задачи. Автор этой статьи написал же "простейший". Я перед собой ставил похожую задачу - справиться со сборкой в один пакет целого зоопарка. В ручную это делать весьма не весело. В общем, как и писать слишком детальную автоматизацию.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
SmetDenis
0 # SmetDenis 08.08.2015 18:16
О глобальной автоматизации я не писал. Лишь про простейшие тесты, а главное репозиторий :)
Ладно тесты... А вот каждый раз делать checkout чтобы собрать архив - это тоже ручная работа, нет? Тем более что в начале автор пишет про работу с git.

Может я отстал от жизни, но я не понимаю, зачем архивы вкладывать в общий архив + xml. Со времен J2.5 инсталлятор умеет работать с директориями. Дело конечно хозяйское и каждый сходит с ума по своему... :)
---
Внезапно стало интересно, кто-нибудь из разработчиков расширений делает авто тесты перед деплоем?
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
mavik
0 # mavik 08.08.2015 18:35
Цитирую SmetDenis:
Может я отстал от жизни, но я не понимаю, зачем архивы вкладывать в общий архив + xml. Со времен J2.5 инсталлятор умеет работать с директориями. Дело конечно хозяйское и каждый сходит с ума по своему... :)


Я это делал для того, чтобы передавать заказчику один архив, которым за раз обновляются все расширения.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
0 # Вадим Куницын 09.08.2015 00:24
Мы к сожалению автоматических тестов не делаем, у меня есть иногда поползновения к этому делу, но оно обычно в рутине тонет. Кстати по теме с удовольствием бы что-то готовое использовал... но все допиливать надо... а на это времени как правило нет...
Что касается инсталятора, то пакетная установка самая логичная и безглючная, особенно это понимать начал, когда количество установок расширений перевалило за 10ть тысяч... )) да и в целом я знаю многих людей которые не уготавливают все расширения, а ставят, только то что им нужно.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
SmetDenis
0 # SmetDenis 09.08.2015 00:39
Эх... про тестирование - жаль... :sad: была надежда взглянуть.
Сейчас как раз обкатываю новую инфраструктуру для третей версии своего cck с почти что полным циклом ci.
Хотел посмотреть, что другие разработчики под J! творят (собственно так и вышел на этот пост и mc-class.ru).

Похоже что особо никто не парится. С другой стороны чего я ожидал... )))))
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
mavik
0 # mavik 09.08.2015 01:03
Ну я использую юнит-тестирование для своего проекта, но показывать там особенно нечего - подает в библиотечные функции значения и проверяет что на выходе.

А вообще, экономия на тестировании, к сожалению, поголовная практика.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
0 # Вадим Куницын 09.08.2015 12:20
Кстати кто пользовался selenium? стоит заморачиваться или нет?? В целом у них весьма соблазнительно процесс построения тестов выглядит...
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
SmetDenis
0 # SmetDenis 09.08.2015 12:53
Я пользовался на одном большом проекте с тонной JS (не Joomla). В общем, поддержка сценариев в актуальном состоянии - очень дорогое удовольствие. Для этого даже пришлось нанимать отдельного человека. Писанина тестов - адская жесть и рутина.
Ну конечно, если вам действительно нужен профит от тестирования, а не просто форму авторизации потыкать :) Еще там есть ряд неприятных ограничений унаследованных из JS, например с доменами.
С другой стороны, ничего лучше пока не придумали...
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
0 # Вадим Куницын 09.08.2015 14:17
Вот и я всегда к такому выводу прихожу, что для такого нужно очень много времени... Даже на простейшее описание теста понадобиться много времени... Которое к сожалению ни кто не жаждет оплатить.
Кстати у меня есть подозрения, что даже у крупных клубов шаблонов и прочего не особо хорошо с тестированием дела обстоят :-)
Да и судя по тому что творится на git у Joomla там тоже особо с тестированием не парятся большинство тестов даже не обновляется похоже.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
mavik
+1 # mavik 09.08.2015 14:50
Это проблема не только Joomla! Сейчас работаю в крупном самописном проекте. Увидел автоматические тесты, спрашиваю как их запустить, и получаю такой ответ: Тесты? Ну да, когда-то кто-то писал, но мы давно ими уже не пользуемся. Бизнесу нужен функционал, а платить за работу, которая нового фукнционала не привносит он не хочет, к сожалению.

А потом спрашивают, почему у нас хотфиксы для хотфиксов :-?
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Аркадий Седельников
0 # Аркадий Седельников 09.08.2015 18:30
Тестирование оправдано на большом и очень долгосрочной проекте, иначе пустая трата времени.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору

Добавить комментарий

Обновить
Защитный код

Joomla!® CMS — пожалуй, лучшая система управления контентом с открытым исходным кодом

Joomla! — это больше, чем просто программное обеспечение, это люди, включающие разработчиков, дизайнеров, системных администраторов, переводчиков, копирайтеров, и, что самое главное — простых пользователей.

Мы рады пригласить вас в ряды нашего сообщества!

Скачать Joomla! 3 Документация Joomla! CMS Свернуть

Расширения Joomla

Новости портала

Новое в блогах

Видео