@[toc] Because some of you recently asked me, I wanted to have a casual conversation about the organization of code in the Maven project.

In fact, it’s not a big problem, but if you don’t understand it, it’s like seeing flowers in a fog. You can’t see it clearly. If you understand it, it’s like a window.

So let’s just talk a little bit.

1. Code organization

Let’s start with code organization.

In general, there are two common forms:

  • tile
  • Father and son structure

Songo has encountered both of these in different projects, so we won’t say which one is better than the other, just these two solutions.

1.1 tile

The tiled code looks like this:

├ ─ ─ the parent │ ├ ─ ─ pom. The XML │ └ ─ ─ the SRC │ ├ ─ ─ the main │ │ ├ ─ ─ Java │ │ └ ─ ─ resources │ └ ─ ─ the test │ └ ─ ─ Java ├ ─ ─ VHR - dao │ ├ ─ ─ Pom. XML │ ├ ─ ─ the SRC │ │ ├ ─ ─ the main │ │ │ ├ ─ ─ Java │ │ │ └ ─ ─ resources │ │ └ ─ ─ the test │ │ └ ─ ─ Java └ ─ ─ VHR - service ├ ─ ─ pom. The XML ├ ─ ─ the SRC │ ├ ─ ─ the main │ │ ├ ─ ─ Java │ │ └ ─ ─ resources │ └ ─ ─ the test │ └ ─ ─ JavaCopy the code

The diagram below:

As you can see, under this structure, the parent project and the child project are all horizontal in terms of code organization, all under the same directory.

However, if you look closely at the POM.xml file, you can clearly see the parent-child relationship between the three modules:

Parent:


      
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.javaboy</groupId>
    <artifactId>parent</artifactId>
    <packaging>pom</packaging>
    <version>1.0 the SNAPSHOT</version>
    <modules>
        <module>../vhr-dao</module>
        <module>../vhr-service</module>
    </modules>

</project>
Copy the code

When specifying a module, the vhr-DAO and vhr-service are not in the same directory as parent’s pom.xml file, so the relative path is used based on the parent’s pom.xml file location.

VHR – dao:


      
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>parent</artifactId>
        <groupId>org.javaboy</groupId>
        <version>1.0 the SNAPSHOT</version>
        <relativePath>../parent/pom.xml</relativePath>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>vhr-dao</artifactId>


</project>
Copy the code

As you can see, the parent’s pom.xml file location is specified using a relativePath that is referenced by the submodule’s pom.xml file.

VHR – service:


      
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>parent</artifactId>
        <groupId>org.javaboy</groupId>
        <version>1.0 the SNAPSHOT</version>
        <relativePath>../parent/pom.xml</relativePath>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>vhr-service</artifactId>


</project>
Copy the code

This is similar to vHR-DAO, so I won’t repeat it.

1.2 Parent-child Structure

The parent-child structure looks like this:

├ ─ ─ maven_parent │ ├ ─ ─ pom. The XML │ ├ ─ ─ VHR - dao │ │ ├ ─ ─ pom. The XML │ │ └ ─ ─ the SRC │ │ ├ ─ ─ the main │ │ │ ├ ─ ─ Java │ │ │ └ ─ ─ the resources │ │ └ ─ ─ the test │ │ └ ─ ─ Java │ └ ─ ─ VHR - service │ ├ ─ ─ pom. The XML │ └ ─ ─ the SRC │ ├ ─ ─ the main │ │ ├ ─ ─ Java │ │ └ ─ ─ resources │ └ ─ ─ The test │ └ ─ ─ JavaCopy the code

The diagram below:

The parent-child structure looks very hierarchical, with parent and modules visible at a glance, and many of the open source projects we download from GitHub, such as Shiro, have this structure.

The hierarchy of folders doesn’t tell you anything, though. It depends on the definitions in pom.xml, so let’s look at the differences and similarities between parent’s pom.xml and the individual modules’ pom.xml.

Maven_parent:


      
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.javaboy</groupId>
    <artifactId>maven_parent</artifactId>
    <packaging>pom</packaging>
    <version>1.0 the SNAPSHOT</version>
    <modules>
        <module>vhr-dao</module>
        <module>vhr-service</module>
    </modules>


</project>
Copy the code

The difference here is that modules doesn’t need a relative path (it’s still a relative path, but it doesn’t need one)../), because each child module is in the same directory as parent’s pom.xml file.

VHR – dao:


      
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>maven_parent</artifactId>
        <groupId>org.javaboy</groupId>
        <version>1.0 the SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>vhr-dao</artifactId>


</project>
Copy the code

There is no need to specify parent’s pom.xml file location through the relativePath node, because parent’s pom.xml is in the same directory as each of the child modules.

VHR – service:


      
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>maven_parent</artifactId>
        <groupId>org.javaboy</groupId>
        <version>1.0 the SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>vhr-service</artifactId>


</project>
Copy the code

2. Packing problems

2.1 inheritance

Sometimes, parent simply wants to unify the dependencies of different projects, rather than an aggregation project.

This is done by removing the modules node and its contents from parent’s pom.xml. This is not an aggregation project, and the submodules can be packaged separately.

2.2 the aggregation

Of course, in many cases we are polymer engineering.

For aggregation projects, Songo recommends that you pack them all from the parent:

This ensures that you are packing up to date code.

Of course, there is another process:

  1. First install the parent into the local repository.
  2. Then the model, DAO, and Service modules are installed into the local repository.
  3. Finally, the Web module can be packaged separately.

When using this workflow, it is important to install each module code update to the local repository in a timely manner, otherwise when the Web module is packaged separately, the other modules used will not be the latest code.

3. Summary

Well, a few small problems in Maven, the window is broken suddenly open ~