On Dec 10, 2010, at 10:03 PM, Ron Wheeler wrote: > On 10/12/2010 9:19 PM, Bryan Loofbourrow wrote: >>>> What is the semantic difference between multiple POMs and a single POM >>>> containing the different module lists in profiles? It seems like the >>>> former is harder to support because a change outside the module sets >>>> requires changing every POM.<< >> Well, one difference is a separation of developer concerns from the concerns >> of the consumers of your artifacts. This is especially applicable if the pom >> containing the profiles is the parent pom of your project, that actually >> gets deployed to a repository and consumed by those who consume your >> software. >> >> More subtly, I'd argue that the profiles are "magic beans," things for which >> you have to introspect your source code to know what's going on, and not >> really knowing, without extensive examination, whether these profiles have >> any effect on any of the projects in the child tree. In contrast, a >> developer-facing pom is a distinct file whose purpose can be made quite >> clear at the file system level, and whose purpose is unambiguously contained >> entirely within the file itself. >> >> Descending down to the final level of abstract mysticism, I'd also say that >> the profiles represent a "last resort" in the context of "The Maven Way," a >> thing you do not use unless you must. Yes, we use them -- for things like >> telling the build to execute integration tests that depend on the presence >> of an active database whose location you have defined in a settings.xml >> file. But for a trivial purpose like this, they are overkill. >> > +1.
I see where you are coming from here and can see how that would be attractive in one perspective. For the benefit of the original poster (I assume you guys know this already), module elements are purely metadata for the reactor in the form of a closure of all the projects that should be built, and don't have anything to do with module dependencies once installed/deployed. As long as dependency elements are not inside profiles, the dependency tree is static, and the process of installing to the local repository "flattens" the tree, converting the hierarchical file directory tree to a directed graph that rarely has any resemblance whatsoever to the original project directory tree. [1] details this with helpful pictures. Once that's done, whether or not profiles are used to expand or contract a module selection, what starts as an empty repository is only going to have a larger or smaller set of artifacts in it in either case (via multiple POMs or profile-based selection of modules to be built). One of the things that I would feel is hard to support with multiple POMs (at least in IDEA) is how to deal with making the selection of what artifacts to build. It's easy at the top level, I just import one POM instead of the other. But what about when there are multiple child POMs that need to make selections, or there are are permutations? In IDEA, four distinct profile names can provide up to fifteen compositional permutations with one POM per project. Getting fifteen builds with separate POMs implies I have fifteen POMs at the root, and some diminishing number > 1 at most child levels. I realize this is a degenerate case, but everything in between is just a matter of degrees. By overloading the profile ID namespace, I can do this with one POM per project in all cases. The other thing that bothers me about multiple POMs is keeping them in sync. In IDEA, if an import is not on the classpath, an inspector speedmenu will ask me if I want to add a dependency to my POM. But if IDEA only knows about one POM, there are others that I have to update manually, and I might forget about them or not know about them. This leads to broken builds that might not be hard to fix, but I'll venture that it's more work to keep all the permutations happy that way than to learn the profiles, keep their use limited, and maintain a single set of POMs. It seems like there is complexity either way. I agree that profiles can be a bit like C++ multiple inheritance and it's easy to abuse them and end up with a train wreck, but I've also seen some impossibly elegant designs with multiple inheritance as well, and the same is true for this kind of use of profiles. In the end, either technique has pros and cons. Makes for a good horse race... :-) Brian [1] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-multi-vs-inherit --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
