Android Gradle Localization Deployment maven

Android Gradle Localization deployment maven 1. Gradle Script

In Android Studio, we often refer to AAR files and resources in the MAVEN library. In general, we compile ‘package:library_name:version‘ refer to the packages in the MAVEN library in the same way. Instead, compile(name: ‘xxx‘, ext: ‘aar‘) the method refers to the AAR package generated by the local build or other project (see details).

2. Gradle Citation Method

There are some problems in the way that the local direct reference to the AAR file, such as:
-Resource file preview and so on there will be some bugs;
-Frequent copy synchronization can be cumbersome when a new AAR is created and shared across multiple projects.

So we try to deploy our project locally, and then we can refer to it directly in other projects. First, we know that when the Build script runs compile package:library_name:version , it will go to the following directories to look for:

• https://jcenter.bintray.com/package/library_name/version/
• File:/android_home/extras/android/m2repository/package/library_name/version
• File:/android_home/extras/google/m2repository/package/library_name/version

If you have customized the local directory in Build.gradle, you will find it in this directory, for example, in Build.gradle:

Then the query directory will be four additional:
-File:/project_path/commonlibs/library_name.jar
-File:/project_path/commonlibs/library_name-version.jar
–file:/project_path/module_name/libs/library_name.jar
-File:/project_path/module_name/libs/library_name-version.jar

When no dependencies are found in these directories, an error is run and the build fails.

3. Deploy AAR locally

Once we know the Gradle reference lookup principle, we can deploy our projects locally on demand. We are generally configured in ANDROID_HOME/extras/android/m2repository this directory, so that all other projects can be easily accessed, synchronization updates only one place to update.

First, we set up in the system environment variable- ANDROID_HOME -point to the installation directory of the Android SDK to ensure that the appropriate directory is found on the local deployment.

Then, Module write the Build.gradle script for the desired deployment as follows:

As we can see, there are the following steps:
- apply plugin: ‘maven‘ : Refer to the MAVEN plugin for deployment;
-Add uploadArchives Task to deploy Module;
- mavenDeployer write the appropriate configuration in, including the deployment path, version, GroupId, Artifactid, and so on;

As we can see, we set the deployment target path to: file://localhost/ANDROID_HOME/extras/android/m2repository/ after deployment, the corresponding AAR, POS, jar, and so on will be found in this directory.

4. Perform the deployment

Deployment is simple, and we can perform this task at the command line gradle uploadArchives . Alternatively Gradle Projects , you can find the deployment task for this Module in the window and double-click the task to execute it:

After execution, we can find the deployed files in the corresponding target directory:

Once the deployment is complete, we can refer to it directly in other projects compile ‘package:library_name:version‘ . Gradle automatically finds this dependency and the corresponding library file, which is introduced into the project to be assembled.

5. Multi-Module Deployment

In larger projects, we often have multiple module in one project, and there are references to each other in these module. Like what:

For example, in this example, Project has two Module, and Moduleb references the Modulea within the project, at this time, when deploying Moduleb, the files generated for Moduleb pom are problematic:

As we can see, Moduleb's pom references the Modulea, but Module A does not correspond to each other, groupId so that version when a third party references Moduleb, a dependency error occurs. At this point, the solution is to add and Modulea the project.group build.gradle project.version , so that when generating the Moduleb Pom, the two values are automatically populated.

The build.gradle of Modulea are as follows:

If filled out project.group and project.version after, there is no need to fill in the Mavendeployer pom.groupId and pom.version , Gradle will automatically use project.group and project.version fill in. This way, there is no problem deploying for Modulea and Moduleb.

6. Reference

• Describes how to write Build.gradle and how to deploy
• Resolves a problem with groupId and version errors when multi-Module deployment

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Android Gradle Localization Deployment maven