Maven relies on optimization

# Sharing author

Nickname:arige

The background,

1. The overall project structure is shown in the figure above. All service packages depend on all modules in the infrastructure

2. Different businesses depend on different service layers

3. Users may use one or more business modules in the business layer

Second, the target

Maven optimizations allow developers to rely directly on the required business packages when they are plugged in, and we use optimizations to help developers automatically import the required service packages and infrastructure packages

Third, problems to be solved

1. Determine which packages each business layer needs to rely on and which packages need to be given to developers. Ensure that developers can automatically import the packages that the business layer depends on after integrating them

2. Which packages do we need in our own development process but do not bring in order to avoid conflicts with developers? How to remove these packages?

Four, implementation principle

When relying on Maven repositories in Android projects, there is an iterative traversal process

Gradle dependencies on the repository path for build.gradle and the default path for repositories in the project

2. There will be a POM file download in the previous step. This is a very important file, and all subsequent operations are his operations

In the POM file of the previous step, there is a very important node called Dependencies. If the node has dependencies, data is downloaded based on the dependency configuration

Fifth, concrete implementation

1, the dependency module into the POM file

  <dependencies>
        <dependency>
            <! -- dependent group ID -->
            <groupId>org.apache.maven</groupId>
            <! -- Dependent artifact ID -->
            <artifactId>maven-artifact</artifactId>
            <! -- Version number of the dependency. In Maven 2, you can also configure a range of version numbers. -->
            <version>3.8.1</version>
            <! The default type is JAR. It usually represents the extension of the dependent file, but there are exceptions. A type can be mapped to another extension or classifier. Types often correspond to the packaging method used, although there are exceptions. Examples of some types: JAR, WAR, EJB-client, and test-jar. New types can be defined in plugin if extensions are set to true. So the previous type example is incomplete. -->
            <type>jar</type>
            <! -- Dependent classifiers. Classifiers can distinguish components that belong to the same POM but are built differently. The classifier name is appended to the version number of the file name. For example, if you want to build two separate JAR artifacts, one using the Java 1.4 compiler and the other using the Java 6 compiler, you can use the classifier to generate two separate JAR artifacts. -->
            <classifier></classifier>
            <! -- Dependent scope. During a project release, help determine which artifacts are included. Refer to dependency mechanisms for more information. -compile: default scope, used for compile. -provided: similar to compile, but supports what you would expect from the JDK or container, similar to classpath runtime: -test is required for execution: -system is used for test tasks: The corresponding elements need to be provided externally. Obtain the value from systemPath. - systemPath: Applies only to system. - optional: Indicates whether dependencies are passed when the project itself is dependent. For continuous dependencies -->
            <scope>test</scope>
            <! -- For system scope only. Note that use of this element is discouraged and may be overwritten in new versions. This element specifies the path on the file system for dependencies. You need an absolute path, not a relative path. It is recommended to use attributes to match absolute paths, such as ${java.home}. -->
            <systemPath></systemPath>
            <! From the list of dependencies, list the set of dependencies that are excluded when calculating transfer dependencies. This tells Maven that you only depend on the specified project, not the project's dependencies. This element is used to resolve version conflicts -->
            <exclusions>
                <exclusion>
                    <artifactId>spring-core</artifactId>
                    <groupId>org.springframework</groupId>
                </exclusion>
            </exclusions>
            <! Optional dependencies. If you declare C dependencies as optional in project B, you need to explicitly reference C dependencies in projects that depend on B (e.g., project A). Optional dependencies block transitivity of dependencies. -->
            <optional>true</optional>
        </dependency>
    </dependencies>
Copy the code

Of particular interest to us this time is the **scope ** node

According to business requirements, our packages need to meet the needs of developers in various scenarios, so we need to set the value of our scope to compile, and how to set the corresponding value of our build.gradle?

So implementation means dependency, just dependency, not packaged in.

The API stands for packaging, that is, not only dependencies but also packages in so that the upper layer does not have to rely on them again.

So, when we package, we’re going to provide the dependencies that go out and use the API to do that

2, will be required locally at runtime, but does not need to provide developer package removal.

In the gradle packaging process, the Publications plugin has a function to remove the corresponding dependency packages

The red box is where the dependencies are actually removed, and we can modify this part of the code to suit our business needs

Sixth, the end

So far the whole modification is complete

In summary, it’s about handling project dependencies and figuring out what needs to be passed along and what needs to be removed when it comes time to actually package.