There is a custom for naming a starter. The official starter is usually spring-boot-starter-XXX, while our custom starter is usually XXX-spring-boot-starter.

First of all, we need to understand that our custom bean can be automatically assembled, and how our third-party custom starter can be scanned by componentScan. There is a convention that creates a meta-INF directory under Resources. Create a spring.Factories file in that directory and use it to specify which classes are your beans. org.springframework.boot.autoconfigure.EnableAutoConfiguration

Create a normal SpringBoot project

I’m going to call it hzy-spring-boot-starter, and once you’ve created it, you can delete the starter class, because my dependencies are usually introduced by other projects, so it doesn’t matter, and then you need to introduce two dependencies

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

Once introduced, we can define a Service in which our business code can be written.

public class HzyService { public String getHelloWorld() { return "hello world"; }}Copy the code

Then we define a configuration class, here called AutoConfig, to inject our service into the IoC container

@Configuration public class AutoConfig { @Bean public HzyService hzyService() { return new HzyService(); }}Copy the code

Then the most important step is to make our configuration class scannable. In Spring, conventions are bigger than configurations. The convention is to create a meta-INF directory under Resources, and then write a Spring. factories file to it.

org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.hzy.AutoConfig

The final step is to package the project into our local Maven repository by executing the following command.

mvn clean install -Dmaven.test.skip=true

Finally, you can import this dependency just like any other dependency, the HzyService, which creates objects directly through autowiring.

@Autowired
private HzyService hzyService;
Copy the code

That’s the end of custom starter, isn’t it easy, if only the world were that simple…

The configuration file

When we write some official configuration, we may find that when we write a prefix, there will be some prompt after, the important thing is that our configuration works. How does this work?

It’s actually done through an @ConfigurationProperties annotation, which can scan your configuration by configuring the prefix.

@ConfigurationProperties(prefix = "hzy") public class HzyProperties { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; }}Copy the code

This simple configuration can be configured in the project where the JAR is introduced. If not, the name attribute is null.

At this point we modify our Service class to import this configuration.

public class HzyService { @Autowired private HzyProperties hzyProperties; public String getHelloWorld() { return "hello world: " + hzyProperties.getName(); }}Copy the code

In addition, we need to modify our auteur class to pre-inject it into the IoC container via the @import annotation.

@Configuration @Import(HzyProperties.class) public class AutoConfig { @Bean public HzyService hzyService() { return new HzyService(); }}Copy the code

After we have introduced the dependency, we will be prompted to configure name and run it again

As you can see, the configuration has taken effect, and that’s all for today’s sharing.