巴扎黑2017-04-18 10:44:31
1 It is trouble-free and convenient, and it must be like this in some cases, such as the storm I used. But as your project gets bigger and there are more jar packages, you will inevitably encounter jar package conflicts, telling you that the version is wrong or a certain class cannot be found. At this time, you will be confused. Didn't maven help me solve it? At this time, you have to complete one jar package after another to solve the problem, and finally modify the pom file. In addition, others have also said that method 2 only needs to update individual jar packages when updating. It is still advantageous for slow network deployment when deployed remotely. Another advantage is that you can be more familiar with the dependencies of the project, which is easier to solve problems. In short: Maven can resolve compile-time conflicts (through pom.xml), but it cannot resolve run-time dependencies and conflicts.
高洛峰2017-04-18 10:44:31
1 Well, it saves trouble. When creating a jar, it is just compressed. When springboot is deployed, it is just created into a jar.
黄舟2017-04-18 10:44:31
Easy to deploy and run, I personally think that’s it.
No need to repackage when updating individual dependent libraries; the upload size is smaller when updating the application itself. Routine maintenance is more focused on this method.
阿神2017-04-18 10:44:31
Personally, I think the first method is better. It only generates one file, which is very clean and convenient for operation and maintenance deployment. Just like a web project is packaged into a war package, and all the jars it depends on are in the war package. Many companies I have experienced also adopt the first method.
Attached is also a blog of mine: http://xxgblog.com/2015/08/07... It introduces how to use the Maven packaging plug-in for the two packages you mentioned.
