Я знаком с Tomcat/TomEE и тестирую приложения с помощью Arquillian. Сейчас были переходят на Open Liberty. Я вижу, что есть модуль для Arquillian, использующий встроенную Open Liberty, но, похоже, для этого требуется существующая установка Open Liberty, путь которой указан в конфигурации. Это делает его непереносимым и, следовательно, непригодным для автоматизированного тестирования, поскольку установка должна находиться по тому же пути. Arquillian и TomEE автономны, не требуют установки. Поэтому мой вопрос: почему это невозможно с Open Liberty? И планируется ли это в будущем?
Для справки, вот как вы используете Arquillian с TomEE/Tomcat:
<arquillian xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xmlns = "http://jboss.org/schema/arquillian"
xsi:schemaLocation = "http://jboss.org/schema/arquillian http://www.jboss.org/schema/arquillian/arquillian_1_0.xsd">
<container qualifier = "tomee" default = "true">
<configuration>
<property name = "httpPort">-1</property>
<property name = "stopPort">-1</property>
<property name = "users">user=pass</property>
</configuration>
</container>
</arquillian>
Как видите, нет пути к локальной установке, необходимой для запуска тестов. Единственное, что вам нужно сделать, это добавить пару зависимостей Maven в область test, которые подключаются к TomEE (встроенному). Если бы то же самое сработало для Open Liberty, было бы здорово.





Если вы посмотрите на https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.microprofile.config.1.2_fat_tck/publish/tckRunner/tck/src/test/resources/arquillian.xml вы увидите пример arquillian.xml, который устанавливает $wlpHome
<property name = "wlpHome">${wlp}</property>
из переменной окружения $wlp. («wlp» — сокращение от Websphere Liberty Profile)
Здесь переменная wlpHome используется в управляемом/локальном контейнере: https://github.com/OpenLiberty/liberty-arquillian/blob/42cb523b8ae6596a00f2e1793e460a910d863625/liberty-managed/src/main/java/io/openliberty/arquillian/managed/WLPManagedContainer.java#L224
Примером, который делает это динамически, является настройка системное свойство ${wlp} здесь: https://github.com/OpenLiberty/open-liberty/blob/95c266d4d6aa57cf32b589e7c9d8b39888176e91/dev/fattest.simplicity/src/componenttest/topology/utils/MvnUtils.java#L161
Если у вас есть еще вопросы, пишите их... и надеюсь, вам нравится OpenLiberty — это круто!
Гордон
Идем дальше... итак, вышеизложенное - это то, как мы проводим автоматизированное тестирование. но он по-прежнему использует местоположение.
Я вижу, относительно того, что вообще не нужно указывать какое-либо местоположение, вы говорите: «Единственное, что вам нужно сделать, это добавить пару зависимостей Maven в область тестирования, которые используют TomEE (встроенный). Если то же самое будет работать для Open Liberty, это будет здорово».
Итак, подумав, maven поместит кучу классов в путь к классам из-за TomEE зависимости, а затем тестовый прогон найдет подходящий контейнер для запустить тесты дальше.
Я подниму вопрос https://github.com/OpenLiberty/liberty-arquillian/issues/39 чтобы удовлетворить требования, пожалуйста, не стесняйтесь добавлять комментарии и т. д.
Это было бы прекрасно!
Результат, которого вы, кажется, пытаетесь достичь, - это встроенная среда выполнения для свободы с использованием arquillian. Однако, насколько я вижу, команда openliberty на данный момент предоставляет только адаптер удаленного контейнера и адаптер управляемого контейнера.
Поскольку у нас есть аналогичная потребность, мы хотим запускать автоматические интеграционные тесты, где нам не обязательно иметь сервер Openliberty на месте. Нам удалось обойти это с помощью свобода-maven-плагин.
Тогда процесс сборки/тестирования будет таким:
mvn verify, свобода-maven-плагин сгенерирует указанную openliberty, против которой мы хотим запустить наши тесты. <plugin>
<groupId>net.wasdev.wlp.maven.plugins</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>${version.liberty-maven-plugin}</version> <!-- plugin version -->
<configuration>
<assemblyArtifact> <!-- Liberty server to run test against -->
<groupId>io.openliberty</groupId>
<artifactId>openliberty-runtime</artifactId>
<version>18.0.0.4</version>
<type>zip</type>
</assemblyArtifact>
<configDirectory>src/liberty/${env}/</configDirectory>
<configFile>src/liberty/server.xml</configFile>
<serverName>defaultServer</serverName>
</configuration>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>create-server</goal>
</goals>
</execution>
</executions>
</plugin>
target/<arquillian xmlns = "http://jboss.org/schema/arquillian">
<container qualifier = "liberty-managed" default = "true">
<configuration>
<property name = "wlpHome">target/liberty/wlp</property>
<property name = "serverName">defaultServer</property>
</configuration>
</container>
</arquillian>
Таким образом, мы можем гарантировать, что работоспособный сервер Liberty по нашему вкусу всегда существует в нашей локальной среде или, например. наш сервер Jenkins CI/CD, по сути, получая тот же эффект, что и встроенный контейнер.
Можете ли вы предоставить немного больше информации о встроенном контейнере Open Liberty, о котором вы говорите? Официально мы предлагаем только управляемый и удаленный контейнер: github.com/openliberty/liberty-arquillian Если под «присутствовать по одному и тому же пути» вы подразумеваете, что он должен быть доступен через файловую систему, это правильно в случае управляемого контейнера. Для удаленного контейнера вы можете разместить Liberty в другом месте и подключить/запустить тесты с помощью JMX.