Преобразование файла сборки Gradle в Maven POM
В этом руководстве мы рассмотрим, как преобразовать файл сборки Gradle в файл Maven POM. Мы также рассмотрим несколько доступных вариантов настройки.
2. Файл сборки Gradle
Начнем со стандартного Java-проекта Gradle, gradle-to-maven , ` со следующим файлом build.gradle` :
repositories mavenCentral() > group = 'com.foreach' version = '0.0.1-SNAPSHOT' apply plugin: 'java' dependencies compile('org.slf4j:slf4j-api') testCompile('junit:junit') > 3. Плагин Maven
Gradle поставляется с подключаемым модулем Maven , который добавляет поддержку преобразования файла Gradle в файл Maven POM. Он также может развертывать артефакты в репозиториях Maven.
Чтобы использовать это, давайте добавим плагин Maven в наш файл build.gradle :
apply plugin: 'maven' Плагин использует группу и версию , представленные в файле Gradle, и добавляет их в файл POM. Кроме того, он автоматически берет артефакт из имени каталога.
Плагин также автоматически добавляет задачу установки . Итак, чтобы преобразовать, давайте запустим следующее:
gradle install Выполнение приведенной выше команды создает каталог сборки с тремя подкаталогами:
- libs — содержит банку с именем $-$.jar
- poms — содержащий преобразованный файл POM с именем pom-default.xml
- tmp/jar — содержащий манифест
Сгенерированный файл POM будет выглядеть так:
project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> modelVersion>4.0.0modelVersion> groupId>com.foreachgroupId> artifactId>gradle-to-mavenartifactId> version>0.0.1-SNAPSHOTversion> dependencies> dependency> groupId>org.slf4jgroupId> artifactId>slf4j-apiartifactId> scope>compilescope> dependency> dependency> groupId>junitgroupId> artifactId>junitartifactId> scope>testscope> dependency> dependencies> project> Задача установки также загружает сгенерированный файл POM и JAR в локальный репозиторий Maven.
4. Настройка плагина Maven
В некоторых случаях может быть полезно настроить информацию о проекте в сгенерированном файле POM. Давайте взглянем.
4.1. идентификатор группы, идентификатор артефакта и версия
Изменение groupId , артефакта и версии POM можно выполнить в блоке установки :
install repositories mavenInstaller pom.version = '0.0.1-maven-SNAPSHOT' pom.groupId = 'com.foreach.sample' pom.artifactId = 'gradle-maven-converter' > > > Запуск задачи установки теперь создает файл POM с приведенной выше информацией:
groupId>com.foreach.samplegroupId> artifactId>gradle-maven-converterartifactId> version>0.0.1-maven-SNAPSHOTversion> 4.2. Каталог и имя POM
Иногда нам может понадобиться скопировать файл POM в другой каталог и с другим именем . Поэтому добавим в блок install следующее:
pom.writeTo("$mavenPomDir>/$project.group>/$project.name>/pom.xml") Плагин предоставляет атрибут mavenPomDir , который указывает на build/poms . Мы также можем указать абсолютный путь к любому каталогу, в который мы хотим скопировать файл POM.
После запуска задачи установки мы можем увидеть pom.xml внутри build/poms/com.foreach/gradle-to-maven .
4.3. Автоматически сгенерированный контент
Плагин Maven также упрощает изменение любого из сгенерированных элементов POM. Например, чтобы сделать зависимость необязательной, мы можем добавить следующее замыкание в pom.whenConfigured:
pom.whenConfigured pom -> pom.dependencies.find dep -> dep.groupId == 'junit' && dep.artifactId == 'junit' >.optional = true > Это создаст необязательный атрибут, добавленный к зависимости :
dependency> groupId>junitgroupId> artifactId>junitartifactId> scope>testscope> optional>trueoptional> dependency> 4.4. Дополнительная информация
Наконец, если мы хотим добавить дополнительную информацию, мы можем включить любой поддерживаемый Maven элемент в построитель pom.project .
Добавим немного информации о лицензии:
pom.project inceptionYear '2020' licenses license name 'My License' url 'http://www.mycompany.com/licenses/license.txt' distribution 'repo' > > > Теперь мы можем видеть информацию о лицензии, добавленную в POM:
inceptionYear>2020inceptionYear> licenses> license> name>My Licensename> url>http://www.mycompany.com/licenses/license.txturl> distribution>repodistribution> license> licenses> 5. Вывод
В этом кратком руководстве мы узнали, как преобразовать файл сборки Gradle в Maven POM.
Как всегда, исходный код из этой статьи можно найти на GitHub .
- 1. Введение
- 2. Файл сборки Gradle
- 3. Плагин Maven
- 4. Настройка плагина Maven
- 4.1. идентификатор группы, идентификатор артефакта и версия
- 4.2. Каталог и имя POM
- 4.3. Автоматически сгенерированный контент
- 4.4. Дополнительная информация
gradle to maven
To convert Gradle to Maven, first, Maven plugin need to be added in the build.gradle file.
Добавьте мавен плагин в grandle file.
Будет примерно также как посылке
Then, simply run Gradle install in the directory.
Lastly, simply run gradle install and the directory containing build.gradle will do the job. It will create pom-default.xml in the build/poms subfolder.
Затем сделайте инсталл. Он создаст pom-default.xml в папке the build/poms
Migrating Builds From Apache Maven
Apache Maven is a build tool for Java and other JVM-based projects. It is typical to migrate an existing Maven build to Gradle.
This guide will help with such a migration by explaining the differences and similarities between the two tools and providing steps that you can follow to ease the process.
Converting a build can be scary, but you don’t have to do it alone. You can search our documentation, post on our community forums, or reach out on our Slack channel if you get stuck.
Making a case for migration
The primary differences between Gradle and Maven are flexibility, performance, user experience, and dependency management.
A visual overview of these aspects is available in the Maven vs Gradle feature comparison.
Since Gradle 3.0, Gradle has invested heavily in making Gradle builds much faster, with features such as build caching, compile avoidance, and an improved incremental Java compiler. Gradle is now 2-10x faster than Maven for the vast majority of projects, even without using a build cache. In-depth performance comparison and business cases for switching from Maven to Gradle can be found here.
General guidelines
Gradle and Maven have fundamentally different views on how to build a project. Gradle provides a flexible and extensible build model that delegates the actual work to the execution of a graph of tasks. Maven uses a model of fixed, linear phases to which you can attach goals (the things that do the work). This may make migrating between the two seem intimidating, but migrations can be surprisingly easy because Gradle follows many of the same conventions as Maven — such as the standard project structure — and its dependency management works in a similar way.
Here we lay out a series of steps for you to follow that will help facilitate the migration of any Maven build to Gradle:
Keep the old Maven build and new Gradle build side by side. You know the Maven build works, so you should keep it until you are confident that the Gradle build produces all the same artifacts. This also means that users can try the Gradle build without creating a new copy of the source tree. A build scan will make it easier to visualize what’s happening in your existing Maven build. For Maven builds, you will be able to see the project structure, what plugins are being used, a timeline of the build steps, and more. Keep this handy so you can compare it to the Gradle build scans while converting the project.
This is a vitally important step to ensure that your deployments and tests don’t break. Even small changes, such as the contents of a manifest file in a JAR, can cause problems. If your Gradle build produces the same output as the Maven build, this will give you confidence in switching over and make it easier to implement the changes that will provide the greatest benefits.
This doesn’t mean that you need to verify every artifact at every stage, although doing so can help you quickly identify the source of a problem. You should focus on the critical output such as final reports and the artifacts that are published or deployed.
You will need to factor in some inherent differences in the build output that Gradle produces compared to Maven. Generated POMs will contain only the information needed for consumption and they will use
and scopes correctly for that scenario. You might also see differences in the order of files in archives and of files on classpaths. Most differences will be minor, but it’s worth identifying them and verifying that they are acceptable. This will create all the Gradle build files you need, even for multi-module builds. For simpler Maven projects, the Gradle build will be ready to run!
A build scan will make it easier to visualize what’s happening in the build. For Gradle builds, you’ll be able to see the project structure, the dependencies (regular and inter-project ones), what plugins are being used and the console output of the build.
Your build may fail at this point, but that’s ok; the scan will still run. Compare the build scan for the Gradle build to the one for the Maven build and continue down this list to troubleshoot the failures.
We recommend that you regularly generate build scans during the migration to help you identify and troubleshoot problems. If you want, you can also use a Gradle build scan to identify opportunities to improve the performance of the build.
Many tests can simply be migrated by configuring an extra source set. If you are using a third-party library, such as FitNesse, look to see whether there is a suitable community plugin available on the Gradle Plugin Portal.
In the case of popular plugins, Gradle often has an equivalent plugin that you can use. You might also find that you can replace a plugin with built-in Gradle functionality. As a last resort, you may need to reimplement a Maven plugin via your own custom plugins and task types.
The rest of this chapter looks in more detail at specific aspects of migrating a build from Maven to Gradle.
Understanding the build lifecycle
Maven builds are based around the concept of build lifecycles that consist of a set of fixed phases. This can be a challenge for users migrating to Gradle because the build lifecycle is a new concept. Although it’s important to understand how Gradle builds fit into the structure of initialization, configuration, and execution phases, Gradle provides a helper feature that can mimic Maven’s phases: lifecycle tasks.
This feature allow you to define your own «lifecycles» by creating no-action tasks that simply depend on the tasks you’re interested in. And to make the transition to Gradle easier for Maven users, the Base Plugin — applied by all the JVM language plugins like the Java Library Plugin — provides a set of lifecycle tasks that correspond to the main Maven phases.
Here is a list of some of the main Maven phases and the Gradle tasks that they map to:
Use the clean task provided by the Base Plugin.
Use the classes task provided by the Java Plugin and other JVM language plugins. This compiles all classes for all source files of all languages and also performs resource filtering via the processResources task.
Use the test task provided by the Java Plugin. It runs the unit tests, and more specifically, the tests that make up the test source set.
Use the assemble task provided by the Base Plugin. This builds whatever is the appropriate package for the project; for example, a JAR for Java libraries or a WAR for traditional Java webapps.
Use the check task provided by the Base Plugin. This runs all verification tasks that are attached to it, which typically includes the unit tests, any static analysis tasks — such as Checkstyle — and others. If you want to include integration tests, you will have to configure these manually.
Use the publishToMavenLocal task provided by the Maven Publish Plugin.
Note that Gradle builds don’t require you to «install» artifacts as you have access to more appropriate features like inter-project dependencies and composite builds. You should only use publishToMavenLocal for interoperating with Maven builds.
Gradle also allows you to resolve dependencies against the local Maven cache, as described in the Declaring repositories section.
Use the publish task provided by the Maven Publish Plugin — making sure you switch from the older Maven Plugin (ID: maven ) if your build is using that one. This will publish your package to all configured publication repositories. There are also tasks that allow you to publish to a single repository even when multiple ones are defined.
Note that the Maven Publish Plugin does not publish source and Javadoc JARs by default, but this can easily be activated as explained in the guide for building java projects.
Performing an automatic conversion
Gradle’s init task is typically used to create a new skeleton project, but you can also use it to convert an existing Maven build to Gradle automatically. Once Gradle is installed on your system, all you have to do is run the command
> gradle init
from the root project directory. This consists of parsing the existing POMs and generating the corresponding Gradle build scripts. Gradle will also create a settings script if you’re migrating a multi-project build.
You’ll find that the new Gradle build includes the following:
- All the custom repositories that are specified in the POM
- Your external and inter-project dependencies
- The appropriate plugins to build the project (limited to one or more of the Maven Publish, Java and War Plugins)
See the Build Init Plugin chapter for a complete list of the automatic conversion features.
One thing to keep in mind is that assemblies are not automatically converted. This additional conversion will required some manual work. Options include:
- Using the Distribution Plugin
- Using the Java Library Distribution Plugin
- Using the Application Plugin
- Creating custom archive tasks
- Using a suitable community plugin from the Gradle Plugin Portal
If your Maven build does not have many plugins or custom steps, you can simply run
> gradle build
once the migration has completed. This will run the tests and produce the required artifacts automatically.
Migrating dependencies
Gradle’s dependency management system is more flexible than Maven’s, but it still supports the same concepts of repositories, declared dependencies, scopes (dependency configurations in Gradle), and transitive dependencies. In fact, Gradle works with Maven-compatible repositories which makes it easy to migrate your dependencies.
One notable difference between the two tools is in how they manage version conflicts. Maven uses a «closest» match algorithm, whereas Gradle picks the newest. Don’t worry though, you have a lot of control over which versions are selected, as documented in Managing Transitive Dependencies. Over the following sections, we will show you how to migrate the most common elements of a Maven build’s dependency management information.
Declaring dependencies
Gradle uses the same dependency identifier components as Maven: group ID, artifact ID and version. It also supports classifiers. All you need to do is substitute the identifier information for a dependency into Gradle’s syntax, which is described in the Declaring Dependencies chapter.
For example, consider this Maven-style dependency on Log4J:
log4j log4j 1.2.12 This dependency would look like the following in a Gradle build script:
Как подключать сторонние библиотеки в Java
Узнайте, как легко подключать сторонние библиотеки в Java с использованием Maven и Gradle для ускорения разработки!
Алексей Кодов
Автор статьи
7 июня 2023 в 16:12В мире Java существует огромное количество сторонних библиотек, которые могут облегчить жизнь разработчика и ускорить процесс создания приложения. В этой статье мы рассмотрим, как подключать такие библиотеки к вашему проекту на примере двух популярных инструментов: Maven и Gradle.
Maven
Maven — это инструмент для управления проектами на Java, который автоматически подключает и обновляет сторонние библиотеки, используя файл pom.xml . Для подключения библиотеки, вам необходимо добавить соответствующую зависимость в секцию файла pom.xml .
Пример подключения библиотеки Gson для работы с JSON:
<dependencies> <!-- Другие зависимости --> <dependency> <groupId>com.google.code.gson</groupId> <artifactId>gson</artifactId> <version>2.8.9</version> </dependency> </dependencies>
После добавления зависимости Maven автоматически скачает и подключит библиотеку к вашему проекту.
Java-разработчик: новая работа через 11 месяцев
Получится, даже если у вас нет опыта в IT
Gradle
Gradle — это еще один инструмент для управления проектами на Java, который также позволяет автоматически подключать сторонние библиотеки. Для этого вам необходимо добавить соответствующую зависимость в файл build.gradle .
Пример подключения библиотеки Gson для работы с JSON:
dependencies < // Другие зависимости implementation 'com.google.code.gson:gson:2.8.9' >
После добавления зависимости Gradle автоматически скачает и подключит библиотеку к вашему проекту.
Использование подключенных библиотек
После подключения сторонних библиотек вы можете использовать их в своем коде, импортируя соответствующие классы. Например, для работы с Gson вы можете сделать следующее:
import com.google.gson.Gson; public class Main < public static void main(String[] args) < Gson gson = new Gson(); String json = gson.toJson(new Person("John", 30)); System.out.println(json); >> class Person < private String name; private int age; public Person(String name, int age) < this.name = name; this.age = age; >>В этом примере мы используем Gson для преобразования объекта Person в JSON-строку.
Теперь вы знаете, как подключать сторонние библиотеки в Java с использованием Maven и Gradle. Это упрощает процесс разработки и позволяет использовать множество готовых решений для решения различных задач. ��