Use inheritance-aggregator model#2589
Conversation
| </dependencies> | ||
| </dependencyManagement> | ||
|
|
||
| <modules> |
There was a problem hiding this comment.
Use inheritance over multi-module for a simpler module management.
As the number of child SDKs grow, each of them is independent, with the only commonality being the parent pom. The parent pom isn't aware of the children either so child projects can change without modifying this section.
This file serves as the universal parent for dependencies, plugins, etc. The only time to modify this file is when we decide to upgrade a dependency version or alter a build process.
| <description>This package bundles all the SDKs in a multi-module for build/CI purposes.</description> | ||
| <url>https://github.com/Azure/azure-sdk-for-java</url> | ||
|
|
||
| <modules> |
There was a problem hiding this comment.
This file serves as an aggregator for all the projects. To build all of child modules, run
mvn -f pom.client.build.xml compileThis file will not be consumed by any human. This file can be modified at any time without notifying any group, or testing any existing libraries. When a new SDK is added, it will be added to this list for it to be included in the build process.
There can be many pom files like this one for all kinds of purposes.
|
Build output: |
| <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/maven-v4_0_0.xsd"> | ||
| <modelVersion>4.0.0</modelVersion> | ||
| <parent> |
There was a problem hiding this comment.
This section is needed so that when you build this pom file Maven will know where to look for the parent. Without this section, Maven will not look for child module's parent poms.
|
What is the benefit of moving the |
|
This way we keep This PR, though looks redundant and introduces complexities, actually changes the project structure from a multi-module model to a inheritance-aggregator model. Multi-module projects are designed for big projects that are split apart for easier management. The components (almost always) share the same version, release cycle, and has strong inter-component dependencies. I don't think our data plane libraries across services make for such a case. |
3 participants
No description provided.