1, in the Setting.xml in the servers to join
<server> <id>snapshots</id> <username>deployment</username> < password>123456</password> </server> <server> <id>releases</id> < username>deployment</username> <password>123456</password> </server>
2.then add it to the project's Pom.xml, where the ID matches the ID in the server
<distributionmanagement><snapshotrepository><id>snapshots</id><name>internal snapshots</name><url>http://192.168.38.64/nexus/content/repositories/snapshots/</url></ Snapshotrepository></distributionmanagement>
3. Use the command line tool to switch to project directory 4, use the command mvn deploy to publish the widget to the snapshot library
If a configuration error is reported at the time of publishing the following error, one is to configure the user name password in servers, the other is to pay attention to the user name and password
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (Default-deploy) on project Util-core: Failed to deploy ARTIFAC ts:could not transfer artifact Com.tiamaes.util:util-core:jar:1.0.1-20141017.060700-2 from/to s Napshots (http://192.168.38.64/nexus/content/repositories/snapshots/): Failed to transfer file:http://192.168.38.64 /nexus/content/repositories/snapshots/com/tiamaes/util/util-core/1.0.1-snapshot/ Util-core-1.0.1-20141017.060700-2.jar. Return code is:401, reasonphrase:unauthorized. , [Help 1] [ERROR] [ERROR] to see the full stack trace of the errors, re-run Maven with THE-E switch. [ERROR] Re-run Maven using The-x switch to enable full debug logging. [ERROR] [ERROR] For more information on the errors and possible solutions, please read the following articles: [ERROR] [help 1]/HTTP// Cwiki.apache.org/confluence/display/maven/mojoexecutionexception
Maven3 Real-Combat warehouse (snapshot version)
----------
This paragraph is from the network, if the similarity is purely coincidental, please forgive me
In the world of MAVEN, any project or artifact must have its own version. The value of the version may be 1.0.0,1.3-alpha-4,2.0,2.1-snapshot or 2.1-20091214.221414-13. Of these, 1.0, 1.3-alpha-4, and 2.0 are stable release versions, while 2.1-snapshot and 2.1-20091214.221414-13 are unstable snapshot versions.
Why does maven differentiate between release and snapshot versions? Simple 1.0.0, 1.2, 2.1 and so on is enough? Why the 2.1-snapshot, even the long 2.1-20091214.221414-13? Imagine this situation, Xiao Zhang in the development of module a 2.1 version, this version has not been formally released, and module a developed with Module B, which was developed by the colleague of the small Zhang, B's function depends on a. In the process of development, Xiao Zhang needs to constantly put his latest build output, to the season mm, for her development and integration debugging, the question is, how does this work?
What if you keep updating versions 2.1.1, 2.1.2, 2.1.3 ...? First, both the Xiao Zhang and the season mm both need to change the Pom frequently, if more modules rely on module A, will involve more pom changes, and secondly, a large number of versions actually contain only small differences, which will also cause the version number of abuse.
The snapshot version mechanism of MAVEN is designed to address these issues. In this example, the mini-sheet simply sets the version of module A to 2.1-snapshot and then publishes it to a single, and in the process of publishing, Maven automatically timestamps the widget. For example: 2.1-20091214.221414-13 represents the 13th snapshot of December 14, 2009 22:14 14 seconds. With this timestamp, MAVEN can always find the latest file in the 2.1-snapshot version of the widget in the repository. At this point, the season mm configuration is dependent on the 2.1-snapshot version of module A, and when she builds module B, Maven automatically checks the latest widget of module A's 2.1-snapshot from the warehouse and downloads it when updates are found. By default, MAVEN checks for updates every day (Updatepolicy control configured by the warehouse), and users can force Maven to check for updates using the command line-u parameter, such as: mvn clean install-u.
Based on the snapshot version mechanism, the widget can be deployed to the warehouse after the build succeeds, and the quarter mm does not take into account the build of module A at all, and she ensures that the latest available snapshot widget for module A is ready at any time, without the need for additional manual action.
MVN Publishing local jar to Nexus deploy third-party artifacts:
A component might be a JDBC driver for a private database, such as Oracle, or you rely on another jar, which is neither open source nor freely available. In such cases, you will need to manually bring the artifacts and post them to your own warehouse. Nexus provides the host's "Third-party" warehouse for this purpose.
Use the following command to publish the file to the Nexus:
Java code
Deploy local artifacts to the Nexus
