On 11 December 2010 06:26, Brian Topping <[email protected]> wrote:
> > 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. > > My issue with using orofiles for adding modules is that you can end up with version numbers out of sync.... of course that's why I created versions-maven-plugin, but that is just a band-aid. Using profiles to pull in modules can just as easily result in broken builds... what I ended up doing is using profiles to turn off the system specific parts of a build when on a system without those system specific components (e.g. missing flashplayer, rpmbuild), but also to fail a release if the system specific components are missing. > 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: [email protected] > For additional commands, e-mail: [email protected] > >
