Hi, just a long term Maven user here, but I'd like to chime, as I don't think renaming module to subproject is that big an improvement. In fact, it may actually lead to *more* confusion. Here's why:
Maven has two *orthogonal* ways how to projects can relate to each other: aggregation and inheritance. As they are frequently used together, terminology is unfortunately often used in a somewhat sloppy fashion, even within the official documentation (example below). As they are distinct concepts, however, I think it is important to be precise. When explaining Maven aggregation and inheritance to a co-worker, I hence use the following glossary (my own, not in any way official): - *project*: Anything that has a POM (whose root element is /project) - *aggregator* (project): A POM with non-empty /project/modules element (always has /project /packaging = "pom") - *module*: A POM referenced by an aggregator project (note that the same POM may be referenced by multiple aggregators, e.g., to select different "slices" of projects to build) - *child* (project): A POM with /project/parent element - *parent* (project): A POM referenced by a child project (always has /project/packaging = "pom") Subject to the constraint that some projects must have packaging "pom", you can combine these, so you may have a child module, i.e., a project that is both a child project and a module (albeit not necessarily with the same project as parent and aggregator, respectively). But as I said, even the official documentation is not always that precise. An example from the maven-site-plugin's FAQ [1]:
Why don't the links between parent and child modules work when I run "mvn site"? What "mvn site" will do for you, in a multi-project build, is to run "mvn site" for the parent and all its modules individually. The links between parent and child will not work here.
It really should be "*aggregator* and all its modules". Also, there may be both links from an aggregator to its modules (/site/body/menu/@ref = "modules") *and* from a child to its parent (/site/body/menu/@ref = "parent"). Coming back from this tangent to Martin's proposal, I don't think using the term "Maven sub-project" improves things. In fact, it makes it even easier to mistake a module (aggregation) for a child project (inheritance), as the difference between sub-project and child project is very subtle. I would hence restrict the use of "sub-something" to inheritance (think "sub-class") and never use it to discussion aggregation. In particular, "submodule" is really redundant, as a module is always below an aggregator by definition.) What I would have rather like to see is the following: 1. Some kind of glossary (maybe as part of the POM Reference [2], which ATM discussion these terms in only passing) 2. More rigor when talking about modules vs. children in the official documentation. (Would be willing to create PRs once an official glossary exists that the PRs can follow.) IMHO, this would avoid a lot more confusion than a hypothetical mixup of Maven modules with JPMS modules. (FWIW, my past Maven projects have build JPMS modules, OSGi bundles, NetBeans modules, Eclipse plug-ins and more without much confusion.) Just my 2 cents. Best wishes, Andreas [1] <https://maven.apache.org/plugins/maven-site-plugin/faq.html#Why_dont_the_links_between_parent_and_child_modules_work_when_I_run_mvn_site> [2] <https://maven.apache.org/pom.html#Inheritance> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
