Xiao Ming: "The new requirements have been developed, and they will be launched soon. Let's make a package in j-one and test it~!"
After compiling, deploy the test environment, "Nani! The test environment can't get up, my development environment is normal! What's going on!!!"
So Xiao Ming began to find the problem:
Check back the code, no problem;
Environment configuration such as tomcat, jdk, etc., no problem;
I found it. How did the "XXXX-1.0-SNAPSHOT.jar" package get bigger? ? ?
Why does the bag get bigger? It turned out to be a feature of the snapshot package: it is allowed to update the jar with the same version at any time! ! ! The jar package provider in the private server has updated the jar. After Xiaoming re-references it, the problem may be caused by the change of the code content. In this case, the compilation fails, there is a problem with the test environment startup, and in severe cases, online accidents are caused! The code that is officially released online must rely on the release version package to ensure stability!
So what is the correct way to use the private server release library and snapshot library? The following will give you a detailed introduction:
1. Use rules and scenarios of release library (release library):
The release library is a repository for storing stable version packages. All programs published online should refer to the correct version from the release library for use.
The release library repository name has the "releases" logo, including two repositories libs-releases-local and plugins-releases-local. The rules for using the release library in the private server are as follows:
a) The release library does not allow to delete the jar;
b) The release library does not allow jar packages to be updated with the same version (that is, there is only one jar package of the same version);
c) The version number (version) of the jar package uploaded by the release library cannot end with "-SNAPSHOT" (SNAPSHOT in the version number is the only identifier that distinguishes the release version from the snapshot version);
d) Third-party packages (not developed internally by the company) can only refer to the release version
e) If possible, please provide the source code corresponding to the interface for the convenience of the referrer.
Release library usage scenarios:
According to the above release library usage rules, if the referenced library is not the release version during the development process, it is very likely to cause code errors because the reference party does not know after the jar package is updated . Therefore, in the following scenarios, please use the release repository. :
Upload/publish: ① When the jar constructed by the code needs to provide services to other programs ; when the jar package or other type of dependency package provided by a third party is not in the remote central warehouse ; please use the command deploy or Manually upload it to the release repository corresponding to the private server on the web side.
②If it is a jar package provider, please update the corresponding jar package version in the private server in time when the code changes , and contact the administrator to eliminate the jar package offline, so as to avoid reference accidents; and update the release package releasenotes in time (recommended in CF maintenance), so that the reference party can obtain the version update information in time.
Download/dependency: ① When the code needs to use a third-party package, unless the other party's code is still in the development process, please select the official release (release) version of the third-party package .
②If the provider is another system within the company, and the system does not provide a release version package, please take the initiative to request the person in charge of the system to provide a release version package to ensure the stability of the development code version, and pay attention to the version upgrade of the package.
2. Snapshot library (snapshot library) usage rules and scenarios:
The snapshot library is a warehouse for storing intermediate version packages, which means that the programs in the jar package in the library are in an unstable state. When the code needs to be referenced by other programs during the development process, the snapshot version jar package can be provided for debugging and testing. Since the packages of the snapshot library are still in the testing state, the latest package of the same version can be uploaded at any time to replace the old package. Based on this unstable state, maven allows the packages in the snapshot library to be updated with the latest version at any time when they are compiled, which may lead to The same version of the jar will contain different content each time it is packaged and compiled, so the packages in the snapshot library cannot be used for publishing;
The name of the snapshot library warehouse is marked with "snapshots", including two warehouses, libs-snapshots-local and plugins-snapshots-local. The usage rules of snapshot library in private server are as follows:
a) Snapshot library can delete jar;
b) The snapshot library can update the jar package with the same version;
c) Third-party packages (not developed internally by the company) are not allowed to reference snapshot versions
d) The snapshot library can only be used for joint debugging and testing, and is not recommended for online stable releases
e) The version number (version) of the jar package uploaded by the snapshot library must end with "-SNAPSHOT", and after uploading to the private server, the system will automatically replace "-SNAPSHOT" with a timestamp string (the local code still uses "-SNAPSHOT" when referencing ending version number, no need to replace timestamp), there will be at least two versions on a snapshot packet line.
Snapshot library usage scenarios:
According to the above-mentioned usage rules of the snapshot library, the snapshot version of the package is only used for temporary reference in the intermediate process. If it is referenced in the final release process, it is very likely that the jar package is updated or not updated and the reference party does not know it and cause code errors. , so please use the snapshot repository only in the following scenarios:
Upload/Publish: When the jar constructed by the code in development needs to provide services to other programs, please use the command deploy or manually upload the jar of the snapshot version to the snapshot repository corresponding to the private server on the web side.
Download/dependency: When the code needs to use the jar package of other code in the development process, please rely on the snapshot (snapshot) version of the package. Please use the "-U" forced update command to obtain the latest version of the package during the use of the maven type project .
3. Frequently Asked Questions
① After uploading the jar package, it is found that the code is looking for the parent package when compiling, but the private server cannot find the jar, and the parent is not needed in the code
Reason : The problem often occurs when the jar package is uploaded on the web side, and the <parent/> node is automatically generated in the pom.xml file
Solution : When uploading from the web side, please be careful to delete the node configuration by yourself.
② The jar package of the latest snapshot version cannot be downloaded
Reason : The released snapshot version is not released together with the corresponding pom. There is only a jar package and no pom. When Maven compiles, it will directly report an error that the pom cannot be found, or a compilation error will be reported because the jar package has not been updated.
Solution : It can be solved by re-publishing it together with the jar package.
③ More or less jar packages after translation
Reason : The version of the snapshot package referenced by the transitive dependency in the compilation environment is low, and the package of the wrong version is referenced into the code.
Solution : 1. Use the following command to check the dependency tree to determine which package refers to the wrong version: mvn dependency:tree ; 2. Clear the wrong package that has not been updated in the compilation environment, and recompile.