Apache Lenya — необычная opensource CMS на Java

    В комментариях к топику Spring в действии — пробуем opensource CMS на Java я обмолвился об Apache Lenya, одной из opensource CMS на Java, и меня попросили написать о ней подробнее.
    Apache Lenya Logo

    Почему Apache Lenya


    «Почему CMS на Java?» — первый вопрос, который у меня возник, когда поступили требования от заказчика. Ответ оказался простым: заказчик, крупная корпорация, имел опыт разработки проектов на Java, поэтому доверял ей больше всего. «Java EE» звучит для уха бизнесмена серьёзнее и надёжнее, чем, скажем, PHP. Как обстоят дела с надёжностью и серьёзностью на самом деле не суть важно, но всё же стоит учитывать, что крупные корпорации доверяют продуктам других крупных корпораций.

    Итак, мы в компании стали искать CMS Java. Оказалось, что их существует не так уж и мало, как платных, так и свободно-распространяемых. Подробнее можно посмотреть здесь в Википедии
    После анализа лицензий, а нам нужно было серьёзно «допиливать» CMS под нужды заказчика, выбор остановился на нескольких кандидатах: Nuxeo EP, Daisy, Hippo CMS, Alfresco и собственно Apache Lenya. Все были опробованы. После анализа исходных кодов и оценки сложности доработки мы решили остановится на Apache Lenya. Эта CMS предоставляла самые широкие возможности по изменению исходного кода, которые были легко доступны. Благо лицензия Apache License позволяла менять код и использовать потом продукт в коммерческих целях. Возникшие по началу проблемы были решены с помощью небольшого, но достаточно активного комьюнити.

    Main Manu Bar

    Возможности Apache Lenya


    Apache Lenya предоставляет стандартные для CMS возможности (у меня есть опыт работы только Joomla, поэтому большая часть сравнений с ней):
    • WYSIWYG-редактор содержимого. Даже 2: Kupu и BXE. Легко добавляется более привычный FCKEditor.
    • Редактор форм для случаев, когда обычный WYSIWYG-редактор не справляется
    • Блокировка редактируемых страниц для предотвращения ситуаций, когда одна и та же страница редактируется несколькими пользователями
    • Интернационализация
    • Задание расписания на публикацию содержимого
    • Перемещение, копирование, архивация, удаление как отдельных страниц, так отдельных частей сайта
    • XHTML+CSS для разделения самого содержимого и внешнего вида
    • Возможность перенести страницы в архив
    • Разграничение прав доступа пользователей и групп пользователей к различным страницам или частям сайта
    • Интегрированный поиск по сайт (Apache Lucene)

    А также не самые обычные:
    • Контроль версий. Любую отредактированную страницу можно откатить на несколько ревизий назад
    • Редактируемый жизненный цикл страниц. Одно- и двухэтапный цикл «Черновики-Опубликованные» включены в поставку
    • Разделение сайта на секции: Разработка, Опубликованное и Вспомогательное (Staging)
    • Все операции записываются в журнал операций
    • Конфигурационные данные хранятся в файлах. При желании можно подменить классы, обеспечивающие чтение/запись данных, на классы, работающие с базой данных
    • Идентификация пользователей по LDAP

    Особенности:
    • Концепция «Публикаций»

    Данная концепция позволяет переиспользовать уже созданную структуру сайта (или структуру и данные одной публикации) для новой публикации. Различные публикации могут использовать общую структуру сайта, но содержать различную информацию. Например, есть публикация по умолчанию, default, которая уже содержит в себе шаблоны XSLT, данные о пользователя, группах пользователей и другую служебную информацию. Публикация production наследуется от default. Тогда публикация production имеет такой же внешний вид (благодаря общим XSLT), доступ ко всем пользователям и группам. Однако может переопределить некоторые права пользователей, рендеринг страниц или вообще всё целиком. В общем, достаточно удобная возможность, если надо поддерживать несколько похожих сайтов.
    • Собирается с помощью Apache Ant
    • Apache Cocoon

    Об это web-framework стоит поговорить отдельно чуть более подробно. Он является сердцем Apache Lenya.

    Apache Cocoon


    Apache Cocoon (оф. сайт) — фреймворк для веб-разработки. Имеет общие черты со Spring Framework, когда тот был ещё версии 2 или ещё моложе. Помимо всего прочего, стоит отметить, на мой взгляд, две главные особенности Кокона: наличие IoC контейнера и концепцию «каналов» (pipelines). У него есть много других примечательных особенностей, но именно эти две мне понадобились при доработке Apache Lenya. Что такое Inversion of Control, думаю, описывать не стоит, а вот про «каналы» стоит сказать пару слов.
    «Каналы» — это своеобразная имплементация MVC паттерна. XML-rонфигурация выглядит примерно так:
    <?xml version="1.0" encoding="iso-8859-1"?>
    <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">

      <!-- define the Cocoon processing pipelines -->
      <map:pipelines>
        <map:pipeline>
          <!-- respond to *.html requests with
             our docs processed by doc2html.xsl -->
          <map:match pattern="*.html">
            <map:generate src="{1}.xml"/>
            <map:transform src="doc2html.xsl"/>
            <map:serialize type="html"/>
          </map:match>

          <!-- later, respond to *.pdf requests with
             our docs processed by doc2pdf.xsl -->
          <map:match pattern="*.pdf">
            <map:generate src="{1}.xml"/>
            <map:transform src="doc2pdf.xsl"/>
            <map:serialize type="fo2pdf"/>
          </map:match>
        </map:pipeline>
      </map:pipelines>
    </map:sitemap>

    * This source code was highlighted with Source Code Highlighter.

    Как видно, в мэппинге есть три основных этапа создания страниц:
    1. Генерация
    2. Трансформация
    3. Сериализация

    В фигурных скобках передаются параметры для генератора.
    Таким образом достигается гибкость и высокий уровень повторного использования компонентов: с помощью одного и того же генератора и разных трансформаций и сериализаций можно получать широкий спектр форматов выходных данных от банального html до pdf или csv.

    Для реализации IoC-контейнера Apache Cocoon использует уже закрытый на данный момент фреймворк Apache Avalon. Вся конфигурация находится в файле cocoon.xconf. Здесь собрано почти всё: компоненты, источники данных, объявление модулей (Cocoon имеет гибкую систему подключаемых модулей) и прочее.
    Документации по всему это в Интернете не так много, поэтому чуть более подробно о компонентах.
    Концепция компонентов выглядит примерно так: несколько компонентов (component) объединяются по признаку роли (role), объявляется имплементация роли по умолчанию, а в Java-классе уже можно использовать роль и конкретную её имплементацию. Роли являются интерфейсами, а компоненты — это конкретные классы. Конкретные листинги файлов приводить не буду, они очень большие. Детали работы Apache Cocoon и Avalon требуют отдельной статьи.

    Установка Apache Lenya


    После скачивания apache-lenya-2.0.3-src.zip и его распаковки, которая может занять продолжительное время из-за большего числа файлов, его необходимо скомпилировать. Тут начинаются самые большие «танцы с бубном».
    Версию 2.0.2 мне удалось сбилдить, исполнив в корне:
    >build build-cocoon
    >build build-cocoon
    >build

    Это не описка, первую команду надо выполнить два раза.
    Для версии 2.0.3 всё оказалось намного сложнее.
    Во-первых, в директории externals\cocoon_2_1_x\lib\optional надо обновить xalan-2.7.1.jar, чтобы он содержал package org.apache.xpath, и добавить serializer.jar из дистрибутива xalan-j_2_7_1-bin.zip. Кстати, после обновления xalan-2.7.1.jar могут возникнуть ошибки при компиляции, тогда надо искать другой xalan-2.7.1.jar. Я брал его из репозитория maven, а сериалайзер из дистрибутива Xalan.
    Далее пытаемся сбилдить Cocoon. Для этого выполняем в корне:
    build.bat build-cocoon -lib externals/cocoon_2_1_x/lib/optional

    Раза с 3-го или даже с 4-го билд должен пройти успешно.
    Параметр -lib externals/cocoon_2_1_x/lib/optional обязателен, потому что некоторые библиотеки с ant tasks лежат там, а некоторые библиотеки необходимы для компиляции.
    Затем для пользователей Windows необходимо поставить GnuWin32 (можно взять отсюда), добавить в PATH из переменных окружения директорию, куда установился GnuWin32. Это необходимо, чтобы по ходу сборки была выполнена команда patch
    В итоге, команда
    build -lib externals/cocoon_2_1_x/lib/optional

    должна закончиться волшебным сообщением BUILD SUCCESSFUL.
    Если что-то не получилось, то можно дополнительно спросить меня или поискать ответы в почтовом архиве

    Запуск Apache Lenya


    Запуск у меня тоже не прошёл плавно. Сначала мне пришлось скопировать jms.jar (javax.jms package) и jta-1.1.jar (javax.transaction package) в build\lenya\webapp\WEB-INF\lib\ (надо это будет поправить в основной ant'овской сборке), и только после этого Apache Lenya успешно стартовал:
    Lenya Homepage

    Запускается Lenya с помощью файла lenya.bat или lenya.sh
    По умолчанию используется контейнер сервлетов Jetty.
    Также возможен запуск под Tomcat (лично протестировано). Более подробно об этом можно прочитать на официальном сайте.
    Apache Lenya частично переведён на русский язык. Не локализованные надписи можно перевести, дописав нужные данные в файлах интернационализации: $LENYA_HOME$\src\webapp\lenya\resources\i18n

    Создание новой публикации Apache Lenya


    Для создания своей публикации необходимо выполнить следующее.
    На главной странице нажимаем 'Create publication', вводим идентификатор (будущий контекст) и имя публикации:
    Create publication

    После создания нажимаем на ссылку на публикацию и попадаем на страницу со свойствами публикации:
    Publication homepage

    Выбираем 'Login for authoring' (позволяет редактировать содержимое сайта и конфигурацию сайта)
    Логинимся как lenya (пароль levi)
    Выбираем что сделать: экспортировать страницы по умолчанию или не создавать никаких страниц:
    Import pages

    Дальше пользователем lenya можно создавать страницы, их редактировать и отправлять на утверждение. В меню «Редактировать» можно создавать страницы, а в меню «Техпроцесс» управлять состоянием страниц:
    Edit Menu
    Workflow Menu

    Пользователь alice (пароль levi) имеет роль рецензиста и имеет права на публикацию страниц. После публикации страницы появляеются на Live View (или закладка «Опубликовано»)
    К справке, данные о пользователях, группах и ролях хранятся в \build\lenya\webapp\lenya\pubs\default\config\access-control\passwd\ Конечно же, их можно менять через веб-интерфейс, закладка 'Admin'.

    Выводы


    Apache Lenya — гибкая CMS на Java, имеющая в основе Apache Cocoon, а следовательно и все его возможности, и распространяемая под лицензией Apache License. Данная CMS обладает широкими возможностями, как говорится, «прямо из коробки», а функциональность может быть легко расширена написанием дополнительных модулей. Документации и руководств в Интернете немного, но есть небольшое активное сообщество. При определённых условиях Lenya можно рекомендовать к использованию.
    В данной статье рассмотрены лишь основы и часть возможностей Apache Lenya. Если у кого-то будет интерес к этой теме, я могу продолжить описание этой необычной CMS.

    Список ресурсов
    1. Официальный сайт Apache Lenya http://lenya.apache.org/
    2. Официальный сайт Apache Cocoon http://cocoon.apache.org/
    3. Почтовый архив Apache Lenya http://mail-archives.apache.org/mod_mbox/lenya-user/
    4. GnuWin32 http://gnuwin32.sourceforge.net/packages/patch.htm
    5. Список CMS на Java в Википедии
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 37
    • +1
      Про доработку интересно было бы почитать.
      • +6
        Тогда буду готовить следующую статью.
      • 0
        Никогда не пишите- ЕЩЕ ОДНА! кому нужна еще одна если уже есть такие же? За такую фразу дипломные работы валятся, даже если они хорошие, а тут opensource проект.
        Пишите- что то вроде- НОВАЯ MCS, ОТЛИЧАЮЩАЯСЯ ОТ ПРОЧЕМ ТЕМ, ЧТО она там супер пупер в чем-то.
        • +2
          Спасибо за совет, поправил.
          • –1
            Мысли вслух. Дипломы валятся??? Почему я не учился в таком вузе.
          • +10
            Во всех обзорах CMS есть один существенный недостаток, который достаточно важен для конечного потребителя, но очень гемморойный для описания. Это нагрузочное тестирование в боевых условиях в сравнении с другими решениями.
            По сути, описание ничем не отличается от других CMS на других платформах, основной критерий «Java EE звучит убедительно» это, кончено, супер, но…

            Хотелось бы увидеть одинаковые «Enterprise» приложения, выполненные на основных платформах, например Java/C#/Python/Ruby/PHP/Perl, и сравнение между ними на одном и том же сервере по нагрузке. Вот это был бы реальный пример. Плюс табличка с реальным временем написания приложения и затраты на написание (2 раба писали 20 часов на хлебе и воде или же пять «сеньйоров» ваяли 40 дней в сауне), плюс размер кода, плюс загрузка памяти и прочая шелуха.

            Ясное дело, что никто этим заниматься не будет, потому грустно читать все эти обзоры. По типу как «Вот новая модель Хонды, тут мы допили новую ручку под капотом, типа фича. А Хонда звучит убедительно для заказчика, это вам не ВАЗ». Вроде как CMS в вакууме, ну да, есть какие-то фичи, да, есть какие-то возможности. Но как оно в боевых условиях — никто не знает. И есть ли профит от этой джавы в данном случае — а хрен его знает.

            P.S. Это не лично к автору обзора, это скорее мысли вслух. Всяко полезно узнать новое название «на всякий случай», всё же авось пригодится.
            • 0
              Это был бы очень полезный обзор, но весьма и весьма трудоёмкий.
              Пару слов на тему производительности Apache Lenya. Так как используется XSLT трансформации во многих местах, то производительность будет невысока. Если к тому же учесть экзотические фреймворки типа Apache Avalon, по которым сложно найти толковую документацию, то и затраты на написание, по крайней мере на изучение, будут высоки.
              Но вот концепция, когда при редактировании (в режиме Authoring) сразу видно структуру сайта, мне близка. Я считаю, что обычным пользователям она будет проще для освоения и понимания, чем, скажем, Секции-Категории в Joomla. Ведь часто наполнением сайта занимаются далеко не технические специалисты. Удобство использования для обычных пользователей тоже надо учитывать.
              • +1
                > Это был бы очень полезный обзор, но весьма и весьма трудоёмкий.
                Ага, я именно об этом :) Ежемесячно кто-либо отписывается на хабре о какой-нибудь «очередной» CMS. Но все эти описания просто бесполезны.

                > Но вот концепция, когда при редактировании сразу видно структуру сайта
                Здесь стоит уточнить, для каких именно пользователей. Ведь те, кто уже поработал с CMS, те уже «привыкли» к каким-то устоявшимся механизмам.

                В любом случае, без основательного сравнения дискутировать бессмысленно :) Ведь кому-то и джумла на пне 4 сойдёт, а кто-то нагородит десяток серверов а-ля «энтерпрайз» ради сотни клиентов.

                Кстати, интересно, как апачевские проекты находят применение. Иногда, глядя на них, складывается впечатление, что кто-то пишет тонны кода «в стол» в своё удовольствие, из которого только 10-15% идёт в мир. Хотя это возможно обманчивое мнение.
                • –2
                  ето уже не впечатление! Ето уже тенденция смахивающая на Эпидемию! Вот эта Сравнилка «охватила»
                  1147 (!!!!) ЦеЭмЕcов! И похоже еше не вечер. А впечатление в ето случае — проще написат свой, чем понятb как работает готовый.

                  • 0
                    У Апачевских проектов очень хорошая лицензия, да и много проектов используется, например в нашей компании из больших wicket, из маленьких не перечесть… всех не помню :)
                • +1
                  Хотя бы логи SQL профайлера для одной странички. )))
                  • 0
                    Честное сравнительное тестирование практически невозможно.
                    1) сравнительные тесты производительности может не позволять лицензия;
                    2) специалист, ковырявшийся в системе «последние 5 лет», как правило может быстро допилить ее до качественно иных показателей, нежели дефолтная поставка.
                    • 0
                      А всё сравнивать и не нужно. Зачастую, когда мы видим «очередную» CMS, то мы не думаем о «спеце с опытом 5 лет» либо о лицензиях, наоборот, нам нужно увидеть реальные преимущества, что бы потом уже нанимать спеца и платить лицензии.

                      Можно на выборочных CMS построить идентичное приложение, как я и написал выше, да хоть тот же форум/блог/доску/хабр/etc, и заливать всё это на один и тот же сервак, и проверять нагрузку, загрузку проца-памяти и т.д., SQL запросы (профайлер, количество, etc). В целом протестировать основные факторы. Как лицензия может не позволить запустить «ab ...»? Спеца отбрасывает, принимаем за фактю. что у на специалист общего профиля, без знаний в текущей CMS. Вот и будет адекватное сравнение.

                      А потом мы уже будем посмотреть, что даже если какая-то CMS обладает ну супер фишками, но не выдерживает и 10 запросов в секунду либо заваливает MySQL бесполезными запросами, то грош цена такой CMS.
                      • 0
                        Сравнение демо-версий — это лишь сравнение демо-версий. Сравнение примеров из коробки — это сравнение лишь примеров из коробки. И это совсем не то же самое, что реальные проекты, которые надо еще пару месяцев разрабатывать, прежде чем мы увидим рабочий сайт.

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

                        Например, Битрикс в дефолтной поставке из коробки, при прочих равных, реально жрет ресурсов и может не выдержать 10 запросов в секунду. Но разработчики реально умудряются строить крупные проекты на нем под достаточно высокой нагрузкой. Не фанат этой системы, но вот такой расклад, что его выбирают… по другим критериям.

                        Прожорливость системы вообще может стоять на последнем месте.

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

                        Все таки считаю, что мысль о сложности или часто невозможности адекватно сравнить CMS заслуживает внимания.
                        • 0
                          Давайте рассмотрим простые примеры. Например, машины. Все они выполняют функции «ездить», плюс имеют некоторые дополнительные плюшки. И все эксперты умудряются их сравнивать, выработаны критерии, всё отлично. Причем эти критерии общие! При сравнениях не учитывают такие вещи, как «а у меня нет денег на лицензии» либо «у меня тут мастер есть, который копейки с детства собирает». Сравниваются всегда четкие характеристики самой системы, а не внешние факторы. Это уже клиент сам выберет. Но он должен видеть чёткость и сравнение, чем этот горшок лучше соседнего. Так же с промышленным оборудованием, кораблями, садовыми горшками и всем остальным.

                          У CMS есть четкая цель — управление контентом, и вполне реально составить список из двух десятков критериев, по которым и сравнить. Например, те же корабли сравниваются на верфи по внешним параметрам и характеристикам оборудования, после чего их прогоняют в море на стандартных тестах, типа ускорения, несколько выстрелов, торможение, манёвренность. Это далеко не боевые условия, но всё же позволяют дать адекватную оценку работе систем.

                          Так же точно можно сделать и с CMS. Это средство, инструмент, а любой инструмент имеет предназначение и соответствующие характеристики, по которым можно успешно сравнивать и делать выводы. Кроме того, проект средней сложности реально покажет поведение CMS под нагрузкой, это как базовые испытания. И сразу станет видно. Указанный пример с Битрикс не показатель, например автор в статье указал критерий «java ee выглядит солидно», что для CMS далеко не критерий, это внешний фактор конкретного клиента, а не заслуга системы. Любая CMS конфигурируется, но тут есть нюанс. Это конфигурация самой CMS либо это конфигурация apache/mysql/memcached, которые как раз и не нужно трогать, а оставлять дефолтными, что бы проверить реальную работу самой CMS.

                          При таких раскладах вполне реально получить адекватную оценку и сравнение.
                  • +1
                    До хабраката вставь картинку с логотипов с выравниванием влево / вправо, и переноси в блог CMS завтра, где-то в районе «после обеда» чтобы он на главную попал. в конце можно привести список ресурсов по аналогии с вики, оф сайт, сообщества и т. п. Все консольные команды тоже лучше либо провести через что-то подсвечивающее либо завернуть в code + blockquote.
                    • +1
                      Спасибо, поправил и перенёс в блог CMS
                    • 0
                      Ревизии есть, если не ошибаюсь, в поздних версиях вордпресса. Во всяком случае, неоднократно попадались советы, как их отключать.
                      Не ревизии, но близкое к тому — черновики (автоматически сохраняемые) — встречал ещё в нескольких движках, а также в публичных блог-сервисах (жж, дайри).

                      Журналирование, естественно, много где есть.

                      Это так, отвлечённо.
                      • +1
                        «Поздние версии вордпресс», ха! Неимоверное достижение…

                        В Друпале и ревизии, и несколько состояний документа (если больше двух — плагином), и много чего еще было всегда (по крайней мере в шестой версии)
                        • +1
                          Я и не выдаю за достижение. Я поясняю, что это в принципе встречается.
                          • 0
                            Ну, начнем с того, что каким-нибудь «плагином» всегда можно что угодно и к чему угодно прицепить, причем любой степени простоты/громоздкости. Вопрос в том, нужно ли это все в таком объеме и если нужно, то часто ли. Лишний наворот — усложнение системы, в том числе для пользователя.
                        • 0
                          Спасибо, познавательно. Не забудьте обещанную статью про доработку. :)
                          • 0
                            Насчет версий интересный у всех подход.

                            А почему, кстати, именно версия документа, а не куска системы или целиком системы?

                            Вот был раньше cvs, лепивший версии на файлы отдельно, потом появился svn, сохранявший версию для всего репозитория.

                            Просто интересно, почему отдельных документов версии? Кто что думает?
                            • 0
                              Документы обычно более независимы, чем исходники программ, поэтому откатывать всё одновременно смысла нет имхо.
                            • +3
                              ЦМС Апач Лёня.
                              • +2
                                теперь ждем ЦМС Чероки Вася.
                              • 0
                                по своему небольшому опыту хочеться добавить, что Апачи Леня нечеловечески сложна. Пока во всех концептах разберешься, пока рабочую версию соберешь, пока все настроишь, и все конечному пользователю объяснишь — все желание с ней работать пропадает. Для своих нужд нашел более удачную CMS, называется Магнолия (http://www.magnolia-cms.com/home.html) имеет коммерческую и открытую лицензию (GPL). Очень проста (по сравнению с Леней), большое сообщество, используется на довольно большом количестве сайтов.
                                • +1
                                  По своему опыты подтвержу, что Леня очень сложна. Может и не «нечеловечески», но копать иногда приходилось долго. Плюс экзотические фреймворки. Но проект мы тогда сдали, кучу изменений сделали, клиент остался вполне доволен.
                                • –1
                                  Можно попридираюсь?

                                  2 «Java EE» звучит для уха бизнесмена серьёзнее и надёжнее, чем, скажем, PHP

                                  Фиговый тот бизнесмен, который вникает в нюансы платформы для создания интернет-представительства своей компании. «Подбираю специалистов и не боюсь делегировать им часть своих полномочий». Вот признак настоящего бизнесмена. Вот правило для умного руководителя. Если бы Java EE звучало для IT-директора — о да, я бы поверил. Но в музыку для ух предпринимателя :(
                                  • 0
                                    Мы в компании несколько раз подряд пытались ее интегрировать в работу.

                                    Резюме: это рак мозга. CMS ради CMS, разработка ради разработки, продукт на радость его авторам, чесалка самомнения.

                                    Для использования в реальной жизни она, может, и пригодна, но она чудовищно, запредельно дорога во внедрении. Значит, ее имеет смысл ставить на сайты огромных масштабов, И ТО: нужно сначала доказать, что это целесообразно.
                                    • 0
                                      CMS на Java это жесть… чтоб писать плагины людям придется нанимать людей за несколько тысяч долларов в месяц, вместо студента который знает пехапэ.
                                      • +1
                                        Что касается мелких заказчиков, то да, им лучше нанять студентов, а вот что касается крупных корпоративных пользователей, то они склонны доверять компаниям, лучше тоже крупным. То, что в компании могут работать студенты, это уже другое дело. Корпорациям нужны гарантии, а что может дать бедный студент?
                                        • 0
                                          А если компания накроется? Искать потом крутых ява-программистов чтоб разбирались? С PHP это намного проще…
                                      • 0
                                        OpenCMS попробуйте — довольно взрослое и простое решение.
                                        • 0
                                          А российский Mozart CMF/CMS не рассматривали?
                                          • 0
                                            Это как-то связано с популярным apache, или у авторов просто не нашлось достаточно креативности?
                                            • 0
                                              Нет, это просто делалось под эгидой Apache Software Foundation

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое