On 10/1/05, Chris Berry <[EMAIL PROTECTED]> wrote: > 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!!
Great analogy :) However, in this case its a recipe that recommends where to find the ingredients, though if you are able to get substitutions you are equally able to specify it. My supermarket gives out recipes listing where to find the ingredients in their preferred brands, though I know their competitor also stocks canned tomatoes :) > 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. I think this is a misunderstanding of the enabled/disabled flag. We've anticipated that repositories might be split into dev and prod (and more). The enabled flags for snapshots/releases is not to say which should be used for the project but rather whether to search that repository when it is requested. It is still what the dependency version is declared as that controls what is retrieved. Changes to which repositories are available should be controlled by profiles/settings which is under the control of the build engineer. > > 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. This option is still available for your own projects. We did have frequent problems with the m1 technique, though, as projects didn't have access to deploy to central repository and wanted to share artifacts with their users. It didn't make sense to check these repositories for all artifacts - just those for the given project. That said, I can see where it might be an issue for a build engineer. I would be happy to keep working through this issue into future releases, and also addressing some of the issues Doug raised about wanting to only share a subset of the information (not something that currently happens, but that we hope should eventuate in the long run). Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
