Во-первых, idea тут не при чём, собирать нужно в командной строке самим maven'ом примерно так:
Во-вторых, mainClass должен быть в пакете, и с пакетом же должен быть указан в теге <mainClass>
В-третьих, все версии нужно выносить в секцию properties, а в самих зависимостях - на них ссылаться, иначе не будет работать чрезвычайно удобный maven-version plugin
В-четвёртых, groupID обычно именуется так же как пакеты - от сайтов с перестановкой домена первого и второго уровня, а такой groupId - TestITPhoneClient - я бы сказал, весьма диковат...
В-пятых, почитай про принцип "Convention Over Configuration", то что по умолчанию итак работает - писать не надо. В частности, тег packaging итак по умолчанию имеет значение jar в super-POM'е - так что не нужно его указывать вообще, это - тавтология. То же самое относится к maven'овским plugin'ам. Если значение groupId
| Код | <groupId>org.apache.maven.plugins</groupId> |
, то его так же можно не писать.
В-шестых, всё по тому же принипу CoC, ты не указал версию Java'ы, так что (для maven-plugin'а 3.8.1) получишь Java'у то ли 1.6, то ли 1.7 - тебя это точно устроит? Может, лучше указать явно?
В-седьмых, ты не используешь никакого BOM'а, да и по ходу на чистой Java'е собрался писать - без Lombok'а и Manifold'а, не используешь библиотеку Vavr, а для тестов - морально-устаревший JUnit 4 без assertJ - на голом Hamcrest'е и без mock'ов... ну смотри, по-моему так писать - сплошное мучение...
В-восьмых, зависимость
| Код | <dependency>
<groupId>com.sikulix</groupId>
<artifactId>sikulixapi</artifactId>
<version>1.1.2</version>
</dependency> |
имеет проблемы - транзитивно она тянет за собой зависимость
| Код | <dependency>
<groupId>com.github.vidstige</groupId>
<artifactId>jadb</artifactId>
<version>-v1.0-g94ebf38-23</version>
</dependency> |
, которой нет в maven.central'е, который в Maven'е используется по умолчанию как источник jar'ников. На https://mvnrepository.com/artifact/com.github.vidstige/jadb/-v1.0-g94ebf38-23 очень кстати есть приписка:
| Цитата | | Note: this artifact it located at Mulesoft repository (https://repository.mulesoft.org/nexus/content/repositories/public/) |
она означает, что для того, что бы воспользоваться этой зависимостью, следует прописать этот репозиторий так же в своём pom'нике (лучше - непосредственно перед блоком dependencies):
| Код | <repositories>
<repository>
<id>Mulesoft</id>
<url>https://repository.mulesoft.org/nexus/content/repositories/public/</url>
</repository>
</repositories> |
Кроме того, версия этой зависимости явно кривая и, видимо, после обнаружения сего факта, её тупо удалили из этого репозитория, что и привело к проблеме (её там нет). По-этому на той же странице можем видеть, что
| Цитата | | Note: There is a new version for this artifact |
и ниже видим, что версия эта - "94ebf38"
Соответственно, в таких случаях я обычно ДОПУСКАЮ, что автор библиотеки не поломал обратную совместимость и делаю операцию по замене старой транзитивной зависимости на новую явную. В принципе, для этого можно было бы просто подсунуть более новую и положиться на то, что Maven сам выберет ту, которая более новая, но Maven в этом плане может затупить, если ему не хватит метаданных, так что полагаться на этот механизм в общем случае я бы не стал. Лучше исключить транзитивную зависимость явно и уже вместо этого явно подтянуть ей на замену свою зависимость со своей версией.
Короче говоря, выглядеть pom'ник c этой зависимостью и 11-й Java'ой у тебя по итогу должен примерно вот так:| Код | <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>TestITPhoneClient</groupId>
<artifactId>demo-project</artifactId>
<version>1.0</version>
<name>TestITPhoneClient</name>
<url>http://maven.apache.org</url>
<properties>
<!--region General-->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>11</java.version>
<!--endregion-->
<!--region Libs -->
<selenium-java.version>3.141.59</selenium-java.version>
<sikulixapi.version>1.1.2</sikulixapi.version>
<jadb.version>94ebf38</jadb.version>
<junit.version>4.13-beta-1</junit.version>
<!--endregion-->
<!--region Plugins-->
<maven-compiler-plugin.version>3.8.1</maven-compiler-plugin.version>
<maven.compiler.release>${java.version}</maven.compiler.release><!-- for compiler plugin version >= 3.8 -->
<maven.compiler.parameters>true</maven.compiler.parameters>
<maven-jar-plugin.version>3.1.2</maven-jar-plugin.version>
<!--endregion-->
</properties>
<repositories>
<repository>
<id>Mulesoft</id>
<url>https://repository.mulesoft.org/nexus/content/repositories/public</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium-java.version}</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
</dependency>
<dependency><!-- https://mvnrepository.com/artifact/com.sikulix/sikulixapi -->
<groupId>com.sikulix</groupId>
<artifactId>sikulixapi</artifactId>
<version>${sikulixapi.version}</version>
<exclusions>
<exclusion>
<groupId>com.github.vidstige</groupId>
<artifactId>jadb</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.github.vidstige</groupId>
<artifactId>jadb</artifactId>
<version>${jadb.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven-compiler-plugin.version}</version>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>${maven-jar-plugin.version}</version>
<configuration>
<archive>
<manifest>
<mainClass>mypackage.TestClass</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
</project>
|
|
