Как написать свой стартер спринг

Время на прочтение
5 мин

Количество просмотров 47K

Большинство java-разработчиков уже познакомились с проектом Spring Boot, позволяющим быстро написать приложение, использующее различные компоненты Spring Framework (Spring MVC, Spring Data и многие другие).

Всё удобство Spring Boot основано на использовании так называемых Starter, которые позволяют получить набор сконфигурированных бинов, готовых к использованию и доступных для конфигурации через properties-файлы. Но что делать, если для нужной технологии еще не написано стартера?

В этой статье мне бы хотелось рассказать о том, как создаются стартеры на примере стартера для Spring-social-vkontakte. Spring Social это один из модулей Spring Framework, используемый для интеграции с социальными сетями. В проект Spring Boot включены стартеры для таких социальных сетей как Facebook (spring-boot-starter-social-facebook), Twitter (spring-boot-starter-social-twitter) и LinkedIn (spring-boot-starter-social-twitter), основанные на использовании соответствующих Social-модулей. Большинство разработчиков из СНГ интересует в первую очередь социальная сеть Вконтакте, для которой существует сторонний модуль spring-social-vkontakte. Соответственно, стартера для этого модуля еще нет. Написанием этого стартера мы и займемся в этой статье.

Краеугольным камнем инфраструктуры Spring Boot являются AutoConfiguration-классы, которые Spring Boot находит при запуске приложения и использует для автоматического создания и конфигурирования бинов.

Создадим такой класс для нашего стартера:

@Configuration
@ConditionalOnClass({SocialConfigurerAdapter.class, VKontakteConnectionFactory.class})
@ConditionalOnProperty(prefix= "ru.shadam.social-vkontakte", name = { "client-id", "client-secret"})
@AutoConfigureBefore(SocialWebAutoConfiguration.class)
@AutoConfigureAfter(WebMvcAutoConfiguration.class)
public class VKontakteAutoConfiguration {
}

Мы используем аннотации, чтобы указать SpringBoot, что наш класс является конфигурацией (@Configuration), аннотации, чтобы задать условия, при которых наш AutoConfiguration будет использоваться для создания бинов, а также аннотации, чтобы указать каково место нашей автоконфигурации в процедуре инициализации приложения.

Таким образом:

@ConditionalOnClass({SocialConfigurerAdapter.class, VKontakteConnectionFactory.class})

означает, что бины будут создаваться при наличии в classpath SocialConfigurerAdapter(входит в модуль Spring-Social) и VKontakteConnectionFactory (входит в модуль Spring-Social-Vkontakte). Таким образом, без нужных для нашего стартера зависимостей бины создаваться не будут.

@ConditionalOnProperty(prefix= "ru.shadam.social-vkontakte", name = { "client-id", "client-secret"})

означает, что бины будут создаваться только при наличии property ru.shadam.social-vkontakte.client-id и ru.shadam.social-vkontakte.client-secret.

@AutoConfigureBefore(SocialWebAutoConfiguration.class)
@AutoConfigureAfter(WebMvcAutoConfiguration.class)

означает, что наш бин будет инициализироваться после WebMvc и до SocialWeb. Это нужно, чтобы к моменту инициализации SocialWeb наши бины уже были зарегистрированы.

Теперь перейдем к тому, какие бины мы сконфигурируем в нашем AutoConfiguration.

@Configuration
@ConditionalOnClass({SocialConfigurerAdapter.class, VKontakteConnectionFactory.class})
@ConditionalOnProperty(prefix= "ru.shadam.social-vkontakte", name = { "client-id", "client-secret"})
@AutoConfigureBefore(SocialWebAutoConfiguration.class)
@AutoConfigureAfter(WebMvcAutoConfiguration.class)
public class VKontakteAutoConfiguration {

    @Configuration
    @EnableSocial
    @EnableConfigurationProperties(VKontakteProperties.class)
    @ConditionalOnWebApplication
    protected static class VKontakteConfigurationAdapter extends SocialConfigurerAdapter {

        @Autowired
        private VKontakteProperties properties;

        @Bean
        @ConditionalOnMissingBean
        @Scope(value = "request", proxyMode = ScopedProxyMode.INTERFACES)
        public VKontakte vkontakte(ConnectionRepository repository) {
            Connection<VKontakte> connection = repository.findPrimaryConnection(VKontakte.class);
            if (connection != null) {
                return connection.getApi();
            }
            return new VKontakteTemplate(this.properties.getClientId(), this.properties.getClientSecret());
        }

        private ConnectionFactory<?> createConnectionFactory() {
            return new VKontakteConnectionFactory(this.properties.getClientId(), this.properties.getClientSecret());
        }

        @Override
        public void addConnectionFactories(ConnectionFactoryConfigurer connectionFactoryConfigurer, Environment environment) {
            connectionFactoryConfigurer.addConnectionFactory(createConnectionFactory());
        }
    }
}

Расширяем SocialConfigurationAdapter, который нужен для того чтобы зарегистрировать нашу ConnectionFactory. Для этого в SocialConfigurerAdapter есть callback-метод:

addConnectionFactories(ConnectionFactoryConfigurer, Environment)

Его мы и переопределим, добавляя нашу ConnectionFactory.

Также зарегистрируем request-scoped бин Vkontakte, которые представляет собой интерфейс для доступа к API Вконтакте. При этом, если пользователь авторизуется через приложение, то операции взаимодействия с API будет выполнено с использованием auth_token.

Рассмотрим также класс VkontakteProperties, который используется для получения конфигурации из properties-файлов приложения

@ConfigurationProperties(prefix = "ru.shadam.social-vkontakte")
public class VKontakteProperties  {
    private String clientId;
    private String clientSecret;

    public String getClientId() {
        return clientId;
    }

    public void setClientId(String clientId) {
        this.clientId = clientId;
    }

    public String getClientSecret() {
        return clientSecret;
    }

    public void setClientSecret(String clientSecret) {
        this.clientSecret = clientSecret;
    }
}

За получение значений из properties файлов отвечает аннотация:

@ConfigurationProperties(prefix = "ru.shadam.social-vkontakte")

Она сообщает SpringBoot, что нужно попытаться все проперти, начинающиеся с префикса ru.shadam.social-vkontakte поместить в соответствующие поля класса.

Последним нашим шагом будет создание файла, позволяющего SpringBoot найти наш AutoConfiguration класс. Для этого существует специальный файл spring.factories, который нужно поместить в META-INF папку получающегося jar-файла.

В этом файле нам надо указать наш AutoConfiguration-класс.

org.springframework.boot.autoconfigure.EnableAutoConfiguration=ru.shadam.spring.boot.vkontakte.VKontakteAutoConfiguration

Теперь, подключив получившийся jar к нашему Spring Boot проекту и задав в конфигурации ru.shadam.social-vkontakte.client-id и ru.shadam.social-vkontakte.client-secret, мы получим в нашем приложении сконфигруированные пути /connect/vkontakte и бин Vkontakte, который мы можем использовать для доступа к API Вконтакте.

Использованные материалы:

1. docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html
2. Ссылка на проект на github: github.com/saladinkzn/social-vkontakte-spring-boot-starter

Современный Spring, а если быть точнее — специальный фреймворк Spring Boot, позволяют с минимальными усилиями подключать ту или иную технологию. Необходимость создавать десятки служебных бинов ушла в прошлое.

Для этого имеются всевозможные starter-ы — специальные Maven/Gradle зависимости, которые необходимо только подключить в проект.

Например, подключив в проект всего одну зависимость:

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jdbc</artifactId>
    </dependency>


мы имеем уже созданный в контексте DataSource, созданный по свойствам в application.properties и другими классами, вроде NamedParameterJdbcTemplate.
Подобные starter основаны на двух специальных функциональностях Spring Boot — AutoConfigurations и Conditional. Покажем, как использовать данные функциональности на примере создания собственного Spring Boot Starter.
Для начала представим, что мы работаем в компании “Марсианская Почта” (com.martianpost). В нашей компании написано множество приложений, для простоты, ровно два — консольное app-example и веб-приложение web-app-example.
Создадим эти приложения с помощью Spring Initializr. 
Исходные коды их можно найти вот здесь.



  


                       
  




Т. к. мы “Марсианская Почта”, то нам очень важно в каждом приложении знать точное марсианское время (а точнее MSD — Mars Sol Date) для всех приложений.
Выпустим Spring Boot Starter, решающий эту задачу. В соответствии с документацией выдадим следующие Maven-координаты:
    <project ...>
        <groupId>com.martianpost</groupId>
        <artifactId>martian-time-spring-boot-starter</artifactId>
        <version>1.0.0</version>

        ...
    </project>


Для больших проектов и технологий, можно вынести отдельно, как саму технологию — martian-time, так и автоконфигурацию — martian-time-autoconfigure и сам стартер — martian-time-spring-boot-starter. Но для педагогических целей мы просто всё напишем в starter-е.
Из зависимостей мы оставим нам необходим только spring-boot-starter, правда, добавим его с optional-параметром — наш starter не является starter-ом уровнем всего приложения (как, например, spring-boot-starter-web), поэтому spring-boot-starter starter уже будет добавлен в приложение. 
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <optional>true</optional>
    </dependency>


Ну и реализуем наш сервис:
    package com.martianpost.martiantime.service;

    import org.springframework.stereotype.Service;

    import java.time.Duration;
    import java.time.ZonedDateTime;

    @Service
    public class MartianTimeService {

        private static final ZonedDateTime MID_DAY
            = ZonedDateTime.parse("2000-01-06T00:00:00Z");

        public double toMarsSolDate(ZonedDateTime zonedDateTime) {
            double secondsFromMidDay
                = (double) Duration.between(MID_DAY, zonedDateTime).getSeconds();
            return secondsFromMidDay / 88775.244 + 44795.9998;
        }
    }


Не забудем про тест:
    package com.martianpost.martiantime.service;

    ...

    @DisplayName("Сервис MartianTimeService")
    class MartianTimeServiceTest {

        private final MartianTimeService service = new MartianTimeService();

        @DisplayName("должен конвертировать совпадение полночей в 06.01.2000")
        @Test
        void shouldConvertZeroDay() {
            ZonedDateTime zeroDayUtc = ZonedDateTime.parse("2000-01-06T00:00:00Z");
            double result = service.toMarsSolDate(zeroDayUtc);
            assertEquals(44_795.9998, result, 1e-3);
        }

        @DisplayName("Должен конвертировать пример с http://jtauber.github.io/mars-clock/")
        @Test
        void shouldConvertExampleFromGithub() {
            ZonedDateTime time = ZonedDateTime.parse("2020-05-01T09:44:43Z");
            double result = service.toMarsSolDate(time);
            assertEquals(52_018.84093, result, 1e-3);
        }
    }


Обратим внимание, что если мы подключим данную библиотеку, то сервис не создастcя автоматически (хотя аннотация @Service) — для этого как раз и нужны автоконфигурации.
Создадим автоконфигурацию для нашего модуля:
    package com.martianpost.martiantime;

    ...

    @Configuration
    @ComponentScan
    public class MartianTimeAutoConfiguration {
    }


Данный класс ничем не отличается от обычного класса конфигурации. Его главная задача — найти класс, помеченный @Service и создать его бин.
Но кто найдёт этот класс автоконфигурации? Никто, и нужно дополнительно указать эту автоконфигурацию, чтобы Spring Boot нашёл её:



  


                       
  




    # resources/META_INF/spring.factories
    org.springframework.boot.autoconfigure.EnableAutoConfiguration=
    com.martianpost.martiantime.MartianTimeAutoConfiguration


Да, теперь можно попробовать подключить данный модуль в наше консольное приложение:
    <dependency>
        <groupId>com.martianpost</groupId>
        <artifactId>martian-time-spring-boot-starter</artifactId>
        <version>1.0.0</version>
    </dependency>


и больше ничего!
    @Autowired
    private MartianTimeService martianTimeService;

    @PostConstruct
    public void printCurrentTime() {
        double currentMarsSolDate = martianTimeService.toMarsSolDate(ZonedDateTime.now());
        System.out.println("MSD: " + currentMarsSolDate);
    }


И получаем:

Допустим, нам в каждом веб-приложении необходимо сделать, чтобы это время возвращалось RestController-ом. Но проблема в том, что наш стартер может использоваться как в консольных приложениях, так и в веб-приложениях.
ОК, мы это можем сделать с помощью @Conditional. Сначала изменим зависимости нашего starter-а:
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <optional>true</optional>
    </dependency>


Добавим контроллер, который будет создаваться только в веб-приложениях:
    package com.martianpost.martiantime.rest;

    ...
    import org.springframework.boot.autoconfigure.condition.ConditionalOnWebApplication;

    @ConditionalOnWebApplication
    @RestController
    public class MartianTimeController {

        private final MartianTimeService martianTimeService;

        public MartianTimeController(MartianTimeService martianTimeService) {
            this.martianTimeService = martianTimeService;
        }

        @GetMapping("/mds/current")
        public double getMds() {
            return martianTimeService.toMarsSolDate(ZonedDateTime.now());
        }
    }


Обратите внимание, что за магию включения/выключения бина отвечает аннотация @ConditionalOnWebApplication. Помимо неё существует множество других @Conditional аннотаций — ссылка.
Проверим, что наше консольное приложение работает:

Если вывести список зависимостей консольного приложения, то увидим, что spring-mvc там и не присутствует.
А вот подключив в веб-приложение:



  


                       
  




    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>com.martianpost</groupId>
        <artifactId>martian-time-spring-boot-starter</artifactId>
        <version>1.0.0</version>
    </dependency>


И запустив, мы получим:
    GET http://localhost:8080/msd/current
    52018.90259483771


Магия    Но доступная каждому   
Целиком пример Вы можете посмотреть на GitHub.

Полная версия Spring Boot для библиотеки может содержать следующие компоненты:

• Модуль autoconfigure, который содержит код автоконфигурации.
• Модуль starter, который обеспечивает зависимость для модуля автоматической настройки, а также библиотеки и любые дополнительные зависимости, которые обычно полезны. Короче говоря, добавление стартера должно обеспечить все необходимое для начала использования этой библиотеки.

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

Именование

Вы должны убедиться, что предоставили правильное пространство имен для своего стартера. Не начинайте имена модулей со spring-boot, даже если вы используете другой Maven groupId. В будущем возможна официальная поддержка для вещи, которую вы автоматически настраиваете.

Как правило, вы должны назвать комбинированный модуль как стартер. Например, предположим, что вы создаете стартер для «acme» назовите модуль автоконфигурации acme-spring-boot-autoconfigure, а стартер acme-spring-boot-starter. Если у вас есть только один модуль, который объединяет оба, назовите его acme-spring-boot-starter.

Конфигурационные ключи

Если ваш стартер предоставляет конфигурационные ключи, используйте для них уникальное пространство имен. В частности, не включайте ваши ключи в пространства имен, которые использует Spring Boot (например, server, management, spring и т. д.). Если вы используете пространства имен Spring Boot, возможно изменение этих пространств имен в будущем таким образом, что это будет нарушать работу ваших модулей. Как правило, перед всеми вашими ключами добавьте пространство имен, которым вы владеете (например, acme).

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

@ConfigurationProperties("acme")
public class AcmeProperties {

    /**
     * Нужно ли проверять расположение ресурсов acme.
     */
    private boolean checkLocation = true;

    /**
     * Таймаут для установления соединения с сервером acme.
     */
    private Duration loginTimeout = Duration.ofSeconds(3);

    // getters & setters

}

Вы должны использовать только простой текст с полем @ConfigurationProperties Javadoc, поскольку они не обрабатываются перед добавлением в JSON.

Вот некоторые правила, которым следуют в Spring, чтобы убедиться, что описания соответствуют:

• Не начинайте описание с «The» или «A» (артиклей в английском языке, при описании на английском).
• Для логических типов начните описание с «Whether» или «Enable».
• Для основанных на коллекции типов, начните описание с «Comma-separated list»
• Используйте java.time.Duration вместо long и опишите модуль по умолчанию, если он отличается от миллисекунд, например «Если суффикс продолжительности не указан, будут использованы секунды».
• Не указывайте значение по умолчанию в описании, если оно не должно быть определено во время выполнения.

Обязательно запустите генерацию метаданных, чтобы помощь IDE была доступна и для ваших ключей. Вы можете просмотреть сгенерированные метаданные (META-INF/spring-configuration-metadata.json), чтобы убедиться, что ваши ключи правильно документированы. Использование собственного стартера в совместимой IDE также является хорошей идеей для проверки качества метаданных.

Модуль autoconfigure

Модуль autoconfigure содержит все необходимое для начала работы с библиотекой. Он также может содержать определения ключей конфигурации (например, @ConfigurationProperties) и любой интерфейс обратного вызова, который можно использовать для дальнейшей настройки инициализации компонентов.

Вы должны пометить зависимости от библиотеки как optional, чтобы вы могли легче включить модуль autoconfigure в свои проекты.

Spring Boot использует процессор аннотаций для сбора условий автоконфигурирования в файле метаданных (META-INF/spring-autoconfigure-metadata.properties). Если этот файл присутствует, он используется для активной фильтрации автоконфигураций, которые не совпадают, что улучшит время запуска. Рекомендуется добавить следующую зависимость в модуль, который содержит автоконфигурации:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-autoconfigure-processor</artifactId>
    <optional>true</optional>
</dependency>

В Gradle 4.5 и более ранних версиях зависимость должна быть объявлена ​​в конфигурации compileOnly, как показано в следующем примере:

dependencies {
    compileOnly "org.springframework.boot:spring-boot-autoconfigure-processor"
}

В Gradle 4.6 и более поздних версиях зависимость должна быть объявлена ​​в конфигурации annotationProcessor, как показано в следующем примере:

dependencies {
    annotationProcessor "org.springframework.boot:spring-boot-autoconfigure-processor"
}

Модуль Starter

Стартер на самом деле пустой jar. Его единственная цель — предоставить необходимые зависимости для работы с библиотекой. Вы можете думать об этом как о рекомендуемом взгляде на то, что требуется, чтобы начать.

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

В любом случае, ваш стартер должен прямо или косвенно ссылаться на основной стартер Spring Boot (spring-boot-starter) (то есть нет необходимости добавлять его, если ваш стартер использует другой стартер). Если проект создается только с вашим пользовательским стартером, основные функции Spring Boot будут учитываться наличием основного стартера.

Читайте также:

• Spring Boot: создание собственной автоконфигурации
• Spring Boot: создание собственной автоконфигурации, аннотации условий
• Spring Boot: создание собственной автоконфигурации, тестирование собственной автоконфигурации

Автор оригинала: baeldung.

1. Обзор

Разработчики core Spring Boot предоставляют стартеры для большинства популярных проектов с открытым исходным кодом, но мы не ограничиваемся ими.

Мы также можем написать ваши собственные стартеры . Если у нас есть внутренняя библиотека для использования в нашей организации, было бы хорошей практикой также написать для нее стартер, если она будет использоваться в контексте весенней загрузки.

Эти стартеры позволяют разработчикам избежать длительной настройки и быстро начать разработку. Однако, когда многое происходит в фоновом режиме, иногда становится трудно понять, как аннотация или просто включение зависимости в pom.xml включает так много функций.

В этой статье мы демистифицируем магию весенней загрузки, чтобы увидеть, что происходит за кулисами. Затем мы будем использовать эти концепции для создания стартера для нашей собственной пользовательской библиотеки.

2.1. Классы автоматической настройки

При запуске Spring Boot он ищет файл с именем spring.factories в пути к классу. Этот файл находится в каталоге META-INF . Давайте посмотрим на фрагмент этого файла из проекта spring-boot-autoconfigure :

# Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,
org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration,
org.springframework.boot.autoconfigure.mongo.MongoAutoConfiguration,
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration

Этот файл сопоставляет имя с различными классами конфигурации, которые попытается запустить Spring Boot. Итак, согласно этому фрагменту, Spring Boot попытается запустить все классы конфигурации для RabbitMQ, Cassandra, MongoDB и Hibernate.

Будут ли эти классы фактически выполняться, будет зависеть от наличия зависимых классов в пути к классам. Например, если классы для MongoDB находятся на пути к классам, mongautoconfiguration будет запущен, и все связанные с mongo компоненты будут инициализированы.

Эта условная инициализация включена аннотацией @ConditionalOnClass . Давайте посмотрим на фрагмент кода из mongautoconfiguration class, чтобы увидеть его использование:

@Configuration
@ConditionalOnClass(MongoClient.class)
@EnableConfigurationProperties(MongoProperties.class)
@ConditionalOnMissingBean(type = "org.springframework.data.mongodb.MongoDbFactory")
public class MongoAutoConfiguration {
    // configuration code
}

Теперь, как – если MongoClient доступен в пути к классу – этот класс конфигурации будет работать, заполняя фабрику Spring bean с MongoClient , инициализированной настройками конфигурации по умолчанию.

2.2. Пользовательские свойства из файла application.properties

Spring Boot инициализирует компоненты, используя некоторые предварительно настроенные значения по умолчанию. Чтобы переопределить эти значения по умолчанию, мы обычно объявляем их в файле application.properties с определенным именем. Эти свойства автоматически подхватываются загрузочным контейнером Spring.

Давайте посмотрим, как это работает.

В фрагменте кода для mongautoconfiguration , @EnableConfigurationProperties аннотация объявляется с классом MongoProperties , который действует как контейнер для пользовательских свойств:

@ConfigurationProperties(prefix = "spring.data.mongodb")
public class MongoProperties {

    private String host;

    // other fields with standard getters and setters
}

Префикс плюс имя поля составляют имена свойств в файле application.properties . Итак, чтобы установить host для MongoDB, нам нужно только написать следующее в файле свойств:

spring.data.mongodb.host = localhost

Аналогично, значения для других полей в классе можно задать с помощью файла свойств.

3. Создание пользовательского стартера

Основываясь на концепциях, приведенных в разделе 2, для создания пользовательского стартера нам необходимо написать следующие компоненты:

1. Класс автоматической настройки для нашей библиотеки вместе с классом свойств для пользовательской конфигурации.
2. Стартер pot для включения зависимостей библиотеки и проекта автоматической настройки.

Для демонстрации мы создали простую библиотеку приветствий , которая будет принимать поздравительное сообщение в разное время суток в качестве параметров конфигурации и выводить поздравительное сообщение. Мы также создадим пример приложения Spring Boot, чтобы продемонстрировать использование наших модулей автоматической настройки и запуска.

3.1. Модуль Автоконфигурации

Мы назовем наш модуль автоматической настройки greeter-spring-boot-autoconfigure . Этот модуль будет иметь два основных класса, т. е. Большие свойства , которые позволят устанавливать пользовательские свойства через application.properties file и GreeterAutoConfiguartion , которые создадут компоненты для greeter library.

Давайте посмотрим на код для обоих классов:

@ConfigurationProperties(prefix = "baeldung.greeter")
public class GreeterProperties {

    private String userName;
    private String morningMessage;
    private String afternoonMessage;
    private String eveningMessage;
    private String nightMessage;

    // standard getters and setters

}

@Configuration
@ConditionalOnClass(Greeter.class)
@EnableConfigurationProperties(GreeterProperties.class)
public class GreeterAutoConfiguration {

    @Autowired
    private GreeterProperties greeterProperties;

    @Bean
    @ConditionalOnMissingBean
    public GreetingConfig greeterConfig() {

        String userName = greeterProperties.getUserName() == null
          ? System.getProperty("user.name") 
          : greeterProperties.getUserName();
        
        // ..

        GreetingConfig greetingConfig = new GreetingConfig();
        greetingConfig.put(USER_NAME, userName);
        // ...
        return greetingConfig;
    }

    @Bean
    @ConditionalOnMissingBean
    public Greeter greeter(GreetingConfig greetingConfig) {
        return new Greeter(greetingConfig);
    }
}

Нам также необходимо добавить файл spring.factories в каталог src/main/resources/META-INF со следующим содержимым:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=
  com.baeldung.greeter.autoconfigure.GreeterAutoConfiguration

При запуске приложения класс Greeter Auto Configuration будет запущен, если класс Greeter присутствует в пути к классу. При успешном запуске он заполнит контекст приложения Spring с помощью Greeter Config и Greeter beans, прочитав свойства через GreeterProperties class.

Аннотация @ConditionalOnMissingBean гарантирует, что эти компоненты будут созданы только в том случае, если они еще не существуют. Это позволяет разработчикам полностью переопределить автоматически настроенные компоненты, определив их собственные в одном из классов @Configuration .

3.2. Создание pom.xml

Теперь давайте создадим starter pom , который введет зависимости для модуля автоматической настройки и библиотеки приветствия.

Согласно соглашению об именовании, все стартеры, которые не управляются основной командой загрузки Spring, должны начинаться с имени библиотеки, за которым следует суффикс -spring-boot-starter . Поэтому мы будем называть наш стартер как greater-spring-boot-starter:

    4.0.0

    com.baeldung
    greeter-spring-boot-starter
    0.0.1-SNAPSHOT

    
        UTF-8
        0.0.1-SNAPSHOT
        2.2.6.RELEASE
    

    

        
            org.springframework.boot
            spring-boot-starter
            ${spring-boot.version}
        

        
            com.baeldung
            greeter-spring-boot-autoconfigure
            ${project.version}
        

        
            com.baeldung
            greeter
            ${greeter.version}
        

    

3.3. Использование стартера

Давайте создадим greater-spring-boot-sample-app , который будет использовать стартер. В pom.xml нам нужно добавить его в качестве зависимости:

    com.baeldung
    greeter-spring-boot-starter
    ${greeter-starter.version}

Spring Boot автоматически настроит все, и у нас будет Больший боб, готовый к вводу и использованию.

Давайте также изменим некоторые значения по умолчанию для Больших свойств , определив их в файле application.properties с префиксом baeldung.greeter :

baeldung.greeter.userName=Baeldung
baeldung.greeter.afternoonMessage=Woha Afternoon

Наконец, давайте использовать Greater bean в нашем приложении:

@SpringBootApplication
public class GreeterSampleApplication implements CommandLineRunner {

    @Autowired
    private Greeter greeter;

    public static void main(String[] args) {
        SpringApplication.run(GreeterSampleApplication.class, args);
    }

    @Override
    public void run(String... args) throws Exception {
        String message = greeter.greet();
        System.out.println(message);
    }
}

4. Заключение

В этом кратком руководстве мы сосредоточились на развертывании пользовательского стартера загрузки Spring и на том, как эти стартеры вместе с механизмом автоматической настройки работают в фоновом режиме, чтобы исключить много ручной настройки.

Полный исходный код для всех модулей, которые мы создали в этой статье, можно найти на GitHub .

Before Spring Boot was introduced, Spring Developers used to spend a lot of time on Dependency management. Spring Boot Starters were introduced to solve this problem so that the developers can spend more time on actual code than Dependencies. Spring Boot Starters are dependency descriptors that can be added under the <dependencies> section in pom.xml. There are around 50+ Spring Boot Starters for different Spring and related technologies. These starters give all the dependencies under a single name. For example, if you want to use Spring Data JPA for database access, you can include spring-boot-starter-data-jpa dependency. 

The advantages of using Starters are as follows:

• Increase productivity by decreasing the Configuration time for developers.
• Managing the POM is easier since the number of dependencies to be added is decreased.
• Tested, Production-ready, and supported dependency configurations.
• No need to remember the name and version of the dependencies.

Spring Boot Starter Data JPA is illustrated below: 

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>
</dependencies>

This gives all the required dependencies and can be seen under the Maven tab in IntelliJ IDEA.

In earlier days, developers used to include all those dependencies. Now Spring Boot Starters provides all those with just a single dependency. The official starters follow a naming convention spring-boot-starter-*, where * denotes application type. For example, if we want to build web including RESTful applications using Spring MVC we have to use spring-boot-starter-web dependency.

Third-Party Starters

If you want to make your own starter or other third-party starters name should not start with spring-boot as it reserved for official Spring Boot Starters. It can start with the name of the project. For example, if the name of the project is gfg-code-template, then the name of the starter can be gfg-code-template-spring-boot-starter. 

Here out we will be discussing all 3 starters and the following starters are provided by the Spring Boot under org.springframework.boot group. They are namely and covered as follows:

1. Application Starters
2. Production Starters
3. Technical Starters 

Let us elaborate these starters in the same sequential order which is as follows:

(A) Spring Boot Application Starters

(B) Spring Boot Production Starters

(C) Spring Boot Technical Starters