Советы по ускорению разработки инфраструктуры PAX (тестирование OSGI) - PullRequest
0 голосов
/ 26 августа 2011

Я знаю, что PAX делает много вещей, и что создание контейнера и копирование всех этих jar-файлов не дешево, но есть какие-то общие советы по улучшению производительности. У меня есть тесты, которые выполняются вне контейнера за доли секунды, а внутри они занимают гораздо больше времени. Я использую PAX в первую очередь для проверки точности моих манифестов и возможности развертывания пакета без каких-либо отсутствующих зависимостей. Я пробовал Knopflerfish, Equinox, Felix, и, в общем, есть небольшая разница, они относительно медленны для бега без контейнеров.

Ответы [ 2 ]

1 голос
/ 31 декабря 2011

Использование Native Container выполняется быстрее, чем Pax Runner Container, что экономит накладные расходы на запуск внешнего процесса.

Использование EagerSingleStagedReactorFactory экономит накладные расходы на перезапуск инфраструктуры для каждого теста.

Чтобы избежать копированияJAR, предпочитайте mvn: URLs или mavenBundle () общим URL-адресам, тогда пакеты будут извлечены из вашего локального репозитория Maven, как только они будут загружены.

Новая функция в Pax Exam 2.3.0 является эталоном: протокол, который позволяет вам предоставлять пакеты на месте, без копирования - это работает даже для разорванных пакетов (то есть, в разархивированной структуре каталогов).

1 голос
/ 21 сентября 2011

Как вы поняли, основной контейнер не имеет большого значения.

Если вы хотите, чтобы минимальные пакеты создавались на лету, вы можете попробовать Pax Tinybundles : если это применимо к вашему случаю, вы можете создать набор свернутых пакетов только с тем содержимым, которое вам действительно нужно для тестирования. Например, вы можете просто упаковать свой манифест. Я сам не тестировал его для этой конкретной цели, но это стоит попробовать.

Как примечание, учтите, что в Pax Exam 2.3 появилась поддержка (см. здесь ) для @Before и @After, что поможет вам более гибко настраивать / разрушать нагрузку.

...