As I've said previously, I do not believe that repository info has *any* place in a POM -- at any level of the hierarchy. A POM should be thought of as a recipe. And with any recipe, the recipe itself does not prescribe where to shop for the ingredients!!
This is especially important for projects, because one cannot tell the different points in the product cycle to use the same repos. E.g. where I work, there is a build team that wants to explicitly build all packages headed into integration testing and finally on into Production. They will never point at any repos that development uses. Conversely, Dev has it's own repos -- for interim packages, for SNAPSHOTS, etc. One can think of the Production repo as a subset of the Dev repo, etc. IMO, repo info should *always* come from external settings.xml -- and that, if anything, settings.xml should allow an inherited hierarchy (with overrides) -- just like build.properties did in maven1. This is a powerful idiom. I was sorry to see it gone in m2. Yes, I get that arbitrary properties in build.properties can lead to POM recipes that cannot be generally satisfied -- i.e. some prop is required but undefined in the POM and comes from build.properties, and thus, what value should it have?? The recipe is incomple. But settings.xml is not arbitrary. It is limited to it's DTD. My $.02, -- Chris On 9/30/05, Stephen Duncan <[EMAIL PROTECTED]> wrote: > What is truly the preferred/best solution to the chicken & the egg > problem with parent POM's? (Where your parent POM might define the > internal repository to use, but a project defines it's parent as this > POM, which is stored in the internal repository, and therefore how do > you get it the first time?) > > Brett Porter said in one mailing list entry: > > for information common to all projects, we recommend using an > organisation-wide parent POM that declares all the information. Of > course, this is a chicken and egg probem - you need the repository to > define the repository. The advantages to this are still: > - if you want to change the repository location you only need to > update that pom, not individual users computers (they get the new pom > from the old repository, and that is used for the new definition) > - you can share standard settings - organisation information, plugin > configuration, source layout, among all projects > > > Kenney Westerhof said in another mailing list entry: > > This can cause a problem though: you usually define the artifact > repository in the root pom; if you check out a submodule, m2 might not > find the root pom in the correct repository; kinf of a chicken and egg > problem. A solution is to specify a company wide (or project > local) repository in your settings.xml. > > > I had started going down the route of always specifying the internal > repository in every POM I have, so that they could all be built > without requiring the user to know the details of the repository and > setting that up in settings.xml. When I changed to > password-protecting this internal repository, I've now required the > person checking out a project to at least define the password in the > sites section of settings.xml, so that benefit seems decreased. > > Is the proper compromise to specify the team-wide repository in the > Parent POM, and then specify the repository to get that POM in > settings.xml? > > -- > Stephen Duncan Jr > www.stephenduncanjr.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
