Springboot2.0+dubbo-spring-boot-starter Aggregation project hit the executable jar package

Springboot2.0+dubbo Aggregation project hit the executable jar package

Springboot2.0+dubbo-spring-boot-starter Project Server packaging is not the same as the previous version of Dubbo Packaging, do not need to put Dubbo configuration files in the Spring folder under Meta-inf, Similar to regular Springboot project packaging.

General Dubbo projects are aggregated form, the following look at the Springboot+dubbo-spring-boot-starter aggregation hit the executable jar:

One, Spring-boot-maven-plugin packaged jar is not dependent

Column as I have a parent project, type is POM, the following two spring-boot works as its module, respectively, Modulea and Moduleb. If Modulea relies on Moduleb. If you use Spring-boot-maven-plugin's default configuration build in Moduleb, or use Spring-boot-maven-plugin's default configuration build in root. Unfortunately, when you clean the package, you will find that Modulea cannot find the class in Moduleb. The reason is that the default packaged jar is not dependent.

Solution:

1. Adjust your code to remove the Spring-boot from the Moduleb, but it is impossible to do so.

2, the official told us, if you do not want to move the code, OK, I will give you a solution, to give you two jar package, one for direct execution, one to rely on. Therefore, you need to specify a property classifier, which is the name suffix of the executable jar package. For example, I set up exec, the original project named Vehicle-business. Then I'm going to get two Jar:vehicle-business.jar and a vehicle-bussiness-exec.jar.

Official document location: 84.5 use a Spring Boot application as a dependency

Summary: Back to aggregation maven, if you use Spring-boot-maven-plugin as Builder in the parent project, then your dependent module must be set with the solution. Otherwise you do not use Spring-boot-maven-plugin as the builder in the root project, but on the module that needs to be packaged.

Second, jdk8 must specify

If you do not specify the words in the development tool run no problem, if you do not use the JAVA8 feature packaging is not a problem. Once you have used the JAVA8 feature, and use Spring-boot-maven-plugin as the builder, be sure to specify the JDK version. Otherwise you will receive a similar unrecognized lambda, please use Resource8 such as error.

<properties>    <java.version>1.8</java.version>    <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties>

Three, Boot-inf traps

The problem is disgusting. At this point you have been packaged successfully, and you will find that when running the jar, the error is file not found and does not tell you what it is. You open the jar to see, find the required lib, configuration file, class is not missing.

In fact, here to say a concept, spring-boot after packaging, the file will be copied to boot-inf/classes, this time your original definition of the scan package path will be invalidated. The official document of this problem is not speaking at all, or I do not see.

This trap waits for you when you use packages to define the scan path. Or get the project file. To get the file, you can add classes before the original path, of course, you have to distinguish between the development environment or production environment, you can use the profile or conditional to solve. If it is a scan package path is disgusting, because you add classes after, do not report file not found. Instead of an error, just warn you that you can't find some XML for hibernate. But you're probably not using hibernate at all.

My solution now is to use the Register method instead of the packages method, but the problem is that if you have a lot of classes, it will be a painful thing. Fortunately, I only need to configure two public classes based on Jersey.

By the way. The official documents did not mention the packages method at the time of configuration jersey, and the Boot-inf trap was ignored by nature. The official configuration section for Jersey is 27.2 Jax-rs and Jersey

Suppose the engineering structure is as follows:

parent  moduleA  moduleB  moduleC

Where Moduleb is Modulea dependent, a uses Jersey,modulea and Modulec needs to be packaged as an executable jar
Then we have two ways of aggregating

Mode one specifies Spring-boot-maven-plugin in the parent

Builder in the parent's pom.xml

<Build><Plugins><Plugin><Groupid>org.springframework.boot</Groupid><Artifactid>spring-boot-maven-plugin</Artifactid><Configuration><source>1.8</Source><target>1.8</target> </configuration> <executions> < execution> <goals> <goal>repackage</ goal> </goals> </execution> </executions> </plugin> </ plugins> </BUILD>   

Builder in the pom.xml of Moduleb

 <Build><Plugins><plugin> <groupId> Org.springframework.boot</groupid> <artifactid>spring-boot-maven-plugin </artifactid> < configuration> <classifier> Exec</classifier> </configuration> </plugin> </plugins></ BUILD>             

No builder required for the rest of the project

Method Two pom.xml of parent does not provide builder

Builder in the pom.xml of Modulea and Modulec

<Build><Plugins><Plugin><Groupid>org.springframework.boot</Groupid><Artifactid>spring-boot-maven-plugin</Artifactid><Configuration><source>1.8</Source><target>1.8</target> </configuration> <executions> < execution> <goals> <goal>repackage</ goal> </goals> </execution> </executions> </plugin> </ plugins> </BUILD>   

Finally, both methods need to replace the packages method in the jersey configuration file with the Register method

public class JerseyConfig extends ResourceConfig{ public JerseyConfig() { register(RequestContextFilter.class); //配置restful package. //packages("com.zs.vehicle.rpc"); //packages("classes/com/zs/vehicle/rpc"); register(Base.class); register(Route.class); }}

Run the MAVEN command:

package

Springboot2.0+dubbo-spring-boot-starter Aggregation project hit the executable jar package