Many project in java

7.3. Multi-project Java build

Example 7.10. Multi-project build — hierarchical layout Build layout multiproject/ api/ services/webservice/ shared/ Note: The code for this example can be found at samples/java/multiproject which is in both the binary and source distributions of Gradle. Here we have three projects. Project api produces a JAR file which is shipped to the client to provide them a Java client for your XML webservice. Project webservice is a webapp which returns XML. Project shared contains code used both by api and webservice . 7.3.1. Defining a multi-project build To define a multi-project build, you need to create a settings file . The settings file lives in the root directory of the source tree, and specifies which projects to include in the build. It must be called se . For this example, we are using a simple hierarchical layout. Here is the corresponding settings file: Example 7.11. Multi-project build — settings.gradle file settings.gradle include «shared» , «api» , «services:webservice» , «services:shared» You can find out more about the settings file in Chapter 49, Multi-project Builds . 7.3.2. Common configuration For most multi-project builds, there is some configuration which is common to all projects. In our sample, we will define this common configuration in the root project, using a technique called configuration injection . Here, the root project is like a container and the subprojects method iterates over the elements of this container — the projects in this instance — and injects the specified configuration. This way we can easily define the manifest content for all archives, and some common dependencies:

Example 7.12. Multi-project build — common configuration build.gradle subprojects < apply plugin: 'java' apply plugin: 'eclipse-wtp' repositories < mavenCentral() >dependencies < testCompile 'junit:junit:4.8.2' >version = ‘1.0’ jar < manifest.attributes provider: 'gradle' >> Notice that our sample applies the Java plugin to each subproject. This means the tasks and configuration properties we have seen in the previous section are available in each subproject. So, you can compile, test, and JAR all the projects by running gradle build from the root project directory. 7.3.3. Dependencies between projects You can add dependencies between projects in the same build, so that, for example, the JAR file of one project is used to compile another project. In the api build file we will add a dependency on the JAR produced by the shared project. Due to this dependency, Gradle will ensure that project s always gets built before project api . Example 7.13. Multi-project build — dependencies between projects api/build.gradle dependencies < compile project( ':shared' ) >See Section 49.7.1, “Disabling the build of dependency project s”for how to disable this functionality. 7.3.4. Creating a distribution We also add a distribution, that gets shipped to the client:

7.4. Where to next?

In this chapter, you have seen how to do some of the things you commonly need to build a Java based project. This chapter is not exhaustive, and there are many other things you can do with Java projects in Gradle. You can find out more about the Java plugin in Chapter 23, The Jav a Plugin , and you can find more sample Java projects in the samples/java directory in the Gradle distribution. Otherwise, continue on to Chapter 8, Dependency Management Basics .

Источник

Русские Блоги

Используйте Gradle для создания многомодульных проектов Java

Начинающие пользователи Java, готовые написать проект, чтобы закрепить знания. При создании нового проекта я не знаю, что выбрать в качестве инструмента сборки. Maven, должно быть, использовался раньше, и он только используется, и нет системы для изучения. Я использовал Gradle для создания проектов, когда занимался разработкой Android, и не изучал его подробно. Позже, когда я познакомился с проектом Java, созданным с помощью Gradle в компании, я узнал о нем больше, описав, что Gradle — это инструмент сборки следующего поколения и очень гибкий. Я лично считаю, что эта гибкость отражается в конфигурации.Я читал много блогов об использовании Gradle для создания многомодульных проектов, и конфигурации разные. В любом случае, Gradle имеет много преимуществ.Если вы хотите знать Baidu, существует множество руководств по Gradle.

Основная цель написания этого блога — запомнить, углубить впечатление и дать вам способ мышления. Боюсь, не распыляйте ничего плохого!

1. Структура проекта

Кратко объясните структуру проекта, где родительский проект — корневой проект, ядро ​​проекта и приложение проекта — подмодули, а приложение проекта зависит от модуля ядра проекта. IDEA использует ULTIMATE версии 2018.1, а gradle — gradle- Версия 4.4.

2. Создайте новый корневой проект project-parent.

Чтобы создать новый проект с помощью IDEA, выберите инструмент Gradle на левой панели меню и снимите флажок в дополнительных библиотеках и фреймворках справа, потому что нам нужны только два файла, setting.gradle и build.gradle, для корневого проекта. Затем перейдите к следующему шагу. Я не буду предоставлять скриншоты операции. Если вы все еще не знаете, как создать новый проект Gradle, обратитесь в Baidu. Есть много руководств.

Новый проект завершен, и вы видите два файла: setting.gradle и build.gradle.

3. Новый подпроект project-core

Выберите корневой проект, затем щелкните правой кнопкой мыши, появится рабочее меню, а затем выполните операцию new-> Module, появится такое же всплывающее окно операции, что и для нового корневого проекта.

Затем следуйте новому проекту и переходите непосредственно к следующему шагу, пока не закончите. Буду выкладывать скриншоты каждого шага

Затем нажмите Finish для завершения, получите следующую структуру проекта:

4. Новый подпроект проект-приложение

Процесс нового строительства такой же, как и на третьем этапе. Я больше не буду публиковать конкретные скриншоты, а только структурную схему нового проекта:

5. Измените конфигурацию build.gradle корневого каталога:

Setting.gradle упоминаться не будет, можно сказать, что это конфигурация скрипта, которая содержит все модули проекта, и вы можете проверить это самостоятельно.

В основном поговорим о настройке build.gradle, разделенной на три части, а именно buildscript, allprojects, subprojects

buildscript < ext < springBootVersion = '2.0.0.RELEASE' >repositories < mavenCentral() jcenter() >dependencies < classpath("org.springframework.boot:spring-boot-gradle-plugin:$") > > allprojects < group 'com.gradle.project' version '1.0-SNAPSHOT' >subprojects < apply plugin: 'java' apply plugin: 'idea' apply plugin: "io.spring.dependency-management" sourceCompatibility = 1.8 targetCompatibility = 1.8 repositories < mavenLocal() mavenCentral() jcenter() >dependencies < // Если здесь настроена зависимость пакета jar, все подпроекты являются общими, и используется функция переноса зависимостей gradle. testCompile group: 'junit', name: 'junit', version: '4.12' >>

6. Build.gradle конфигурация ядра проекта:

В gradle.project здесь ничего не написано. Сценарий build.gradle корневого проекта предоставил базовую конфигурацию для всех модулей. Сценарий build.gradle каждого модуля может предоставлять разные конфигурации в соответствии с различными службами.

7. Конфигурация модуля Project-app build.gradle:

Модуль приложения использует платформу SpringBoot для быстрой публикации тестового приложения и зависит от модуля ядра проекта. Конкретная конфигурация выглядит следующим образом:

apply plugin: 'org.springframework.boot' dependencies

8. Класс выпуска модуля Project-core:

Создайте новый класс в этом модуле для вызова модуля приложения:

9. Опубликуйте модуль проект-приложение:

Через конфигурацию SpringBoot напишите тестовый интерфейс, используйте код модуля ядра проекта для предоставления ответного сообщения, а затем опубликуйте этот модуль как приложение для внешнего доступа:

Затем запустите приложение, вы можете проверить статус запуска по журналу консоли, здесь запуск успешен, а интерфейс запроса успешно освобожден:

Порт по умолчанию — 8080, теперь мы можем получить доступ к интерфейсу тестирования запроса через браузер и успешно вернуть данные:

10. Резюме

В процессе изучения Gradle я обнаружил, что мне нужно потратить на это немного энергии, и мне нужно быть знакомым с базовой грамматикой Groovy, а затем я могу глубоко изучить использование инструментов Gradle. Я чувствую силу Gradle в этом процессе. , Есть еще много действительно мощных функций. У меня есть время прочитать книгу «Gradle Actual Combat». Я еще не начал ее читать. Судя по структуре каталогов, она кажется очень хорошей. Ее определенно можно использовать в реальной разработке.

Источник

Building Java Applications with libraries Sample

To prepare your software project for growth, you can organize a Gradle project into multiple subprojects to modularize the software you are building. In this guide, you’ll learn how to structure such a project on the example of a Java application. However, the general concepts apply for any software you are building with Gradle. You can follow the guide step-by-step to create a new project from scratch or download the complete sample project using the links above.

What you’ll build

You’ll build a Java application that consists of an application and multiple library projects.

What you’ll need

• A text editor or IDE — for example IntelliJ IDEA
• A Java Development Kit (JDK), version 8 or higher — for example AdoptOpenJDK
• The latest Gradle distribution

Create a project folder

Gradle comes with a built-in task, called init , that initializes a new Gradle project in an empty folder. The init task uses the (also built-in) wrapper task to create a Gradle wrapper script, gradlew .

The first step is to create a folder for the new project and change directory into it.

Run the init task

From inside the new project directory, run the init task using the following command in a terminal: gradle init . When prompted, select the 2: application project type and 3: Java as implementation language. Afterwards, select 2: Add library projects . Next you can choose the DSL for writing buildscripts — 1 : Groovy or 2: Kotlin . For the other questions, press enter to use the default values.

The output will look like this:

$ gradle init Select type of project to generate: 1: basic 2: application 3: library 4: Gradle plugin Enter selection (default: basic) [1..4] 2 Split functionality across multiple subprojects?: 1: no - only one application project 2: yes - application and library projects Enter selection (default: no - only one application project) [1..2] 2 Select implementation language: 1: C++ 2: Groovy 3: Java 4: Kotlin 5: Scala 6: Swift Enter selection (default: Java) [1..6] 3 Select build script DSL: 1: Groovy 2: Kotlin Enter selection (default: Groovy) [1..2] 1 Select test framework: 1: JUnit 4 2: TestNG 3: Spock 4: JUnit Jupiter Enter selection (default: JUnit 4) [1..4] Project name (default: demo): Source package (default: demo): BUILD SUCCESSFUL 2 actionable tasks: 2 executed

The init task generates the new project with the following structure:

├── gradle (1) │ └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew (2) ├── gradlew.bat (2) ├── settings.gradle.kts (3) ├── buildSrc │ ├── build.gradle.kts (4) │ └── src │ └── main │ └── kotlin (5) │ ├── demo.java-application-conventions.gradle.kts │ ├── demo.java-common-conventions.gradle.kts │ └── demo.java-library-conventions.gradle.kts ├── app │ ├── build.gradle.kts (6) │ └── src │ ├── main (7) │ │ └── java │ │ └── demo │ │ └── app │ │ ├── App.java │ │ └── MessageUtils.java │ └── test (8) │ └── java │ └── demo │ └── app │ └── MessageUtilsTest.java ├── list │ ├── build.gradle.kts (6) │ └── src │ ├── main (7) │ │ └── java │ │ └── demo │ │ └── list │ │ └── LinkedList.java │ └── test (8) │ └── java │ └── demo │ └── list │ └── LinkedListTest.java └── utilities ├── build.gradle.kts (6) └── src └── main (7) └── java └── demo └── utilities ├── JoinUtils.java ├── SplitUtils.java └── StringUtils.java

├── gradle (1) │ └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew (2) ├── gradlew.bat (2) ├── settings.gradle (3) ├── buildSrc │ ├── build.gradle (4) │ └── src │ └── main │ └── groovy (5) │ ├── demo.java-application-conventions.gradle │ ├── demo.java-common-conventions.gradle │ └── demo.java-library-conventions.gradle ├── app │ ├── build.gradle (6) │ └── src │ ├── main (7) │ │ └── java │ │ └── demo │ │ └── app │ │ ├── App.java │ │ └── MessageUtils.java │ └── test (8) │ └── java │ └── demo │ └── app │ └── MessageUtilsTest.java ├── list │ ├── build.gradle (6) │ └── src │ ├── main (7) │ │ └── java │ │ └── demo │ │ └── list │ │ └── LinkedList.java │ └── test (8) │ └── java │ └── demo │ └── list │ └── LinkedListTest.java └── utilities ├── build.gradle (6) └── src └── main (7) └── java └── demo └── utilities ├── JoinUtils.java ├── SplitUtils.java └── StringUtils.java

1	Generated folder for wrapper files
2	Gradle wrapper start scripts
3	Settings file to define build name and subprojects
4	Build script of buildSrc to configure dependencies of the build logic
5	Source folder for convention plugins written in Groovy or Kotlin DSL
6	Build script of the three subprojects — app , list and utilities
7	Java source folders in each of the subprojects
8	Java test source folders in the subprojects

You now have the project setup to build a Java application which is modularized into multiple subprojects.

Источник