Простейший xml файл Phing для сборки пакета расширений Joomla
- 30.05.2015
Мир меняется, и веб-разработка меняется вместе с ним, еще 3 года назад я даже не думал о GIT, как инструмента для разработки расширений, сейчас я уже не могу помыслить, как можно разрабатывать, что-то и при этом не использовать GIT. Не так давно собирая пакет расширений Joomla состоящий из 22 расширений в ручную, я подумал "Какого...", до сих пор делаю это в ручную, ведь это иногда занимает очень много времени и посвятил несколько часов своего времени изучению Phing.
Первой проблемой с которой я столкнулся - это установка Phing на Windows - эта статья поможет вам установить его в windows окружении.
Вторая проблема - формирование xml файла, который бы позволил автоматически собирать пакет, как раз об этом мы и поговорим в этой статье.
Создаем файл для сборки пакета
Я рекомендую использовать имя файла build.xml. Вы можете использовать любое название, но тогда вам придется указывать в командной строке имя файла при наборе команды phing.
Что написать внутри файла для сборки?
В этом коде я привел пример содержимое файла для сборки пакета нашего расширения Slogin. Объясню, как это работает. Создаются папки "build" и "dist", последовательно берется папки из секции "pack-plugins", архивируются и складываются в папку "build", за тем в эту же папку копируется файл pkg_slogin.xml. И после этого берутся все файлы в папке "build" упаковываются в архив который называется "pkg_slogin_v2.2_j2.5_j3.zip" и копируется в папку "dist". При перезапуске файла сборки, папки "build" и "dist" отчищаются.
На что обратить внимание?
pkg_slogin_v2.2_j2.5_j3.zip - это название конечного пакета расширения.
Секция pack-plugins содержит список папок, которые мы архивируем, каждая папка архивируется такой конструкцией:
Где:
${build}/mod_slogin.zip - путь до конечного файла после упаковки.
description="mod_slogin" - описание файла, должно быть уникальным.
dir="mod_slogin" - папка которую мы упаковываем, путь определяется относительно корня директории, где лежит файл xml файл сборки.
Собственно на этом можно считать урок законченным, в конечном итоге мы получили очень простой файл, на редактирование, которого у вас уйдет несколько минут, а в последствии вы сможете пересобрать пакеты расширений за считанные секунды.
Joomla!® CMS — пожалуй, лучшая система управления контентом с открытым исходным кодом

Joomla! — это больше, чем просто программное обеспечение, это люди, включающие разработчиков, дизайнеров, системных администраторов, переводчиков, копирайтеров, и, что самое главное — простых пользователей.
Мы рады пригласить вас в ряды нашего сообщества!
Расширения Joomla
-
Дайджест свежих расширений Joomla №12-13 (23 июля — 14 августа 2016)
-
Дайджест свежих расширений Joomla №10-11 (08-22 июля 2016)
-
Дайджест свежих расширений Joomla №8-9 (26 июня — 07 июля 2016)
-
Дайджест свежих расширений Joomla №6-7 (11-25 июня 2016)
-
Дайджест свежих расширений Joomla №4-5 (28 мая — 10 июня 2016)
Комментарии
А как же запуск тестов? Как минимум phpunit ...
Получается, что используете phing только для архивации и возни с файлами? Он способен на большее.
А на самом деле у каждого свои задачи. Автор этой статьи написал же "простейший". Я перед собой ставил похожую задачу - справиться со сборкой в один пакет целого зоопарка. В ручную это делать весьма не весело. В общем, как и писать слишком детальную автоматизацию.
Ладно тесты... А вот каждый раз делать checkout чтобы собрать архив - это тоже ручная работа, нет? Тем более что в начале автор пишет про работу с git.
Может я отстал от жизни, но я не понимаю, зачем архивы вкладывать в общий архив + xml. Со времен J2.5 инсталлятор умеет работать с директориями. Дело конечно хозяйское и каждый сходит с ума по своему... :)
---
Внезапно стало интересно, кто-нибудь из разработчиков расширений делает авто тесты перед деплоем?
Я это делал для того, чтобы передавать заказчику один архив, которым за раз обновляются все расширения.
Что касается инсталятора, то пакетная установка самая логичная и безглючная, особенно это понимать начал, когда количество установок расширений перевалило за 10ть тысяч... )) да и в целом я знаю многих людей которые не уготавливают все расширения, а ставят, только то что им нужно.
Сейчас как раз обкатываю новую инфраструктуру для третей версии своего cck с почти что полным циклом ci.
Хотел посмотреть, что другие разработчики под J! творят (собственно так и вышел на этот пост и mc-class.ru).
Похоже что особо никто не парится. С другой стороны чего я ожидал... )))))
А вообще, экономия на тестировании, к сожалению, поголовная практика.
Ну конечно, если вам действительно нужен профит от тестирования, а не просто форму авторизации потыкать :) Еще там есть ряд неприятных ограничений унаследованных из JS, например с доменами.
С другой стороны, ничего лучше пока не придумали...
Кстати у меня есть подозрения, что даже у крупных клубов шаблонов и прочего не особо хорошо с тестированием дела обстоят
Да и судя по тому что творится на git у Joomla там тоже особо с тестированием не парятся большинство тестов даже не обновляется похоже.
А потом спрашивают, почему у нас хотфиксы для хотфиксов