Hi Andreas, it took me some years to find relevant articles and documentation on the maven site. And still it is not easy to find documentation in the depth needed.
I would regret if "module" was changed. It is, as it is now, the best description and semantics of what it is. Maybe we should provide a couple of UML-Diagrams to make those roles better visible. > Am 16.08.2024 um 09:51 schrieb Andreas Sewe <andreas_s...@buildingblobs.com>: > > 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 > Best Regards Kemal Kemal Soysall
