Enhancement request: split multi-module and single-module defaults

[hgschmie]

For a single module build, requiring management of dependencies and plugins adds some overhead that is not immediately beneficial. So for these projects, the <dependencies> and <plugins> settings should probably be false.

For a multi-module project, both of those settings should probably be true.

It would be nice if it were possible to capture these different default settings in a single base pom, e.g.

<requireManagement>
  <single-module>
    <dependencies>...</dependencies>
    <plugins>...</plugins>
  </single-module>
  <multi-module>
    <dependencies>...</dependencies>
    <plugins>...</plugins>
  </multi-module>
</requireManagement>

Would a patch for that be accepted?

[jhaber]

Hmm, thinking about the way we use the plugin, we have a lot of libraries that sit in their own github repos as single-module maven builds and we want them treated the same as multi-module projects. For us, it's mainly about enforcing consistency with our base pom and whether it's part of a multimodule project or not is tangential.

Also, wouldn't what you're suggesting create a situation where you have different behavior when building a module as part of a reactor build vs. moving to the module directory and building it invididually?

What if we added exclusions or separate configuration based on the parent coordinates. That way we could have a more lenient configuration that activates if you inherit directly from org.basepom:basepom-standard-oss. If there's an intermediate parent (either due to a multimodule project or a company-specific base pom) then there could be a default configuration with more strict validations. Does that make sense?

[hgschmie]

All good arguments, especially the "step into a module of a multi-module build". I was thinking from a perspective of supplying different defaults for multi-module / single-module projects. I have no strong feeling around whether this should exist or not; right now for basepom the defaults are to not enforce dependencies or plugins to make single-module projects not unhappy.