Build an in-house MAVEN server and publish public projects using Android Studio

Since Android Studio uses the Gradle build tool, the library relies on the process of relying on the library as a module introduced (with a full library copy), The Eclipse ADT is a direct link to the library as a dependency of external projects, each with its own advantages and disadvantages. The advantage of Android Studio is that it keeps the integrity of the project at all times, and each project contains everything that is needed for the project, and when you share the project with someone else, you will not be able to open your project because of a library. The disadvantage is that multiple projects are dependent on the same library, each project has its own copy of the library code, when the library code needs to be updated, each project of the library code needs to be updated again. And Eclipse's library relies on, just do a library link, multiple projects can be linked to the same library, the advantage is that the library needs to modify the time only need to modify a code, Disadvantage when sharing items with others may fall behind the library forgot to share.

Generally a long-term development of a company to accumulate, will be summed up a set of their own SDK or tools for their products to use. If you use Android Studio development, you will inevitably encounter the previous problem once your SDK needs to be updated. Fortunately, Android Studio, in addition to the library module, relies on this approach, providing local repositories or (server) remote warehouse dependencies, and automatically retrieving and managing the library required for the project from the warehouse through the Gradle tool. Gradle supports the MAVEN repository, which was used directly by the MAVEN central repository in earlier Android studio, although the official version was switched to Jcenter, but the custom Maven repositories could still be mixed.

The overall approach to the solution is divided into three steps:

The first is to build a MAVEN repository on the server inside your own company.

Second, publish your company's public class library to the MAVEN repository on your company's internal servers

Third, configure the company's internal server Maven warehouse address in other company projects, and reference the required library,gradle automatically from the server Maven repository

1. Build Maven warehouse on your company's internal server

The MAVEN repository on the server can be built using the Sonatype Nexus Oss. Sonatype Nexus Oss is a MAVEN Warehouse management tool and provides a Web console that is easy to deploy and use.

1.1 Downloads Sonatype Nexus Oss

Download the Sonatype Nexus OSS to your company's internal server: Http://www.sonatype.org/nexus/go

1.2 Installing and running Sonatype Nexus OSS

First, verify that the Jdk,nexus OSS is installed on the server and that the operation requires JDK7 or JDK8. If you do not have a JDK installed, install the JDK first.

The downloaded Nexus OSS is a zip or tar.gz compressed package that needs to be decompressed. You can unzip it to any location and the Nexus OSS operation has no special requirements for its location. After decompression will see two folders, one is Nexus-x.xx.x-xx, a sonatype-work. Where Nexus-x.xx.x-xx is the Nexus OSS home directory, all running programs and configuration files are inside. Sonatype-work is the Nexus-oss data Catalog, and the MAVEN warehouse data for the Nexus-oss run process is in this area. Enter the Nexus-x.xx.-x-xx/bin directory and the Windows Platform server runs the Nexus.bat script directly. The following details the installation and operation of the Linux platform.

Nexus OSS is officially recommended to install NEXUS-X.XX.X-XX into the/usr/local directory and make a/usr/local/nexus link to the NEXUS-X.XX.X-XX directory for later Nexus OSS version upgrades. Methods are as follows

$ sudo cp nexus-x.xx.x-xx-bundle.tar.gz/usr/local$ cd/usr/local$ sudo tar xvzf nexus-x.xx.x-xx-bundle.tar.gz$ sudo ln-s NEXUS-X.XX.X-XX Nexus

If you are downloading a zip archive, use the sudo unzip nexus-x.xx.x-xx-bundle.zip command to extract it.

To facilitate later use, you can add $nexus_home environment variables to point to/usr/local/nexus. In addition, the default configuration Sonatype-work directory and nexus-x.xx.x-xx in the same directory, if you want to say sonatype-work migration to other specified path, you can modify nexus-x.xx.x-xx/conf/ The value of the nexus-work variable in the nexus.properties configuration file.

Once completed, running the Nexus OSS requires only running the Nexus-x.xx.x-xx/bin/nexus script, which can be either console or start. The console prints the run log in the console. If you have configured the NEXUS_HOME environment variable, you can execute the following statement anywhere:

$NEXUS _home/bin/nexus Start

1.3 Configuring Sonatype Nexus OSS

After successful operation, open the http://server address in the browser 8081/nexus can see the Nexus OSS Control Panel.

Click Login in the top right corner and the default account password is admin/admin123. You can see the following interface when you log in:

On the left is the function panel, you can view all the Maven repositories in the repositories, user management (change password, etc.). Click Repositories to view the MAVEN repository:

You can see that the Nexus OSS has built several warehouses by default, and each warehouse has its own properties.

The first important property is the type warehouse. There are mainly group, hosted, proxy, virtual four types. Different types of warehouses have no role and working mode, generally only need to focus on group, hosted, proxy three types. Since the Nexus OSS can have multiple maven repositories above, the Maven tool requires the three parameters of groupId:artifactId:version to uniquely identify a project, so the Nexus OSS uses a group-type warehouse to prioritize the various Maven repositories on the Nexus OSS to resolve conflicts where different Maven has the same project. The proxy type of warehouse is actually just an agent that is used to proxy maven repositories on other servers. The hosted type is the MAVEN repository that is local to the Nexus Oss's own server, and is the type of warehouse we are mainly using this time.

Repository path is the address of the warehouse, which is required to publish your project to MAVEN and reference the project in the Maven repository.

After selecting a warehouse, you can see the details of this warehouse in the following window, where the Configuration tab can be set up for the warehouse.

Our goal is to publish our own projects to our own servers, so we have to choose the hosted type of warehouse, so as to avoid internal code outside the company leaked out (of course, the server must also be the intranet server, the public network can access the server, published code also has a certain risk). For the hosted type of warehouse we want to use, the focus is on the Repository policy Warehouse storage protocol, with release and snapshot two, release for release, snapshot for snapshot version. There is also a deployment policy deployment protocol with allow redeploy (allows deployment), Disable redeploy (no deployment allowed), and read only (read-only) three modes. Only in allow redeploy mode can we have permission to publish our project to this project. Nexus OSS has set up the releases and snapshots two hosted warehouses by default, we check the configuration can be directly used, of course, you can also build a hosted warehouse.

2. Publish public class library to server Maven warehouse

Edit the Build.gradle script for the module of the public class library you want to publish, and at the end add the following configuration:

Apply plugin: ' maven ' def isreleasebuild () {return version_name.contains ("SNAPSHOT") = = False}def Getrepositoryusername () {return hasproperty (' Nexus_username ')? Nexus_username: ""}def Getrepositorypassword () {return hasproperty (' Nexus_password ')?                Nexus_password: ""}afterevaluate {project, uploadarchives {repositories {mavendeployer {                Pom.groupid = GROUP Pom.artifactid = pom_artifact_id pom.version = version_name Repository (Url:release_repository_url) {Authentication (username:getrepositoryusername                    (), Password:getrepositorypassword ())} snapshotrepository (Url:snapshot_repository_url) {            Authentication (Username:getrepositoryusername (), Password:getrepositorypassword ())}        }}} Task Androidjavadocs (type:javadoc) {Source = Android.sourceSets.main.java.srcDirs ClAsspath + = Project.files (Android.getbootclasspath (). Join (File.pathseparator))} task Androidjavadocsjar (Type:jar, D Ependson:androidjavadocs) {classifier = ' Javadoc ' from androidjavadocs.destinationdir} task Android Sourcesjar (type:jar) {classifier = ' sources ' from android.sourceSets.main.java.sourceFiles} ARTIFAC TS {Archives Androidsourcesjar Archives Androidjavadocsjar}}

Also add the Gradle.properties file under this module, the file content is as follows:

group= corresponds to the GroupID value of Maven, if the name contains snapshot characters, the project will be published to the snapshots Warehouse, and no release to the releases warehouse version_name= corresponding to MAVEN's version value Pom_ The artifact_id= corresponds to the Artifactid value of Maven snapshot_repository_url= the Snapshots warehouse address configured earlier release_repository_url= Previously configured releases warehouse address nexus_username= login Nexus OSS username nexus_password= login Nexus oss Password

After the modification, find the corresponding module in the Gradle panel on the right side of Android studio and you can see the uploadarchive task under this module:

Double-click to run this task, the project will be published to the Nexus OSS corresponding to the MAVEN repository, in the log can see similar information:

Seeing that build successful is successful, looking back at the warehouse on the Nexus OSS panel and finding the warehouse you are publishing, you should be able to find your project, such as My project:

3, in other projects with reference to our published class library

The method is simple, find the Dependencies object in the Build.gradle file that needs to add the dependent module, add the URL address of our own MAVEN server, and then follow the Gradleid in the configuration file when we published the project earlier: Archiveid:version, such as my own warehouses and projects:

After adding refresh synchronization under Gradle, project dependencies are automatically processed. public class libraries are modified, just modify the public class library and modify the version number, and then publish the code once to maven. Other projects only need to modify the version number in the next Gradle script, and the code will be updated automatically.

Build an in-house MAVEN server and publish public projects using Android Studio