>-----Original Message----- >From: Phillip Hellewell [mailto:[email protected]] > >On Mon, Oct 4, 2010 at 12:30 PM, Anders Hammar <[email protected]> wrote: >> Philip, with all due respect, but reading your posts I get the impression >> you're doing your best not to follow Maven best practice. Maven is all >about >> convention and best practice patterns. Please acknowledge that our advice >is >> based on actual experience and going your own path will surely get you >into >> trouble! It's not really a matter of what you think, but rather what >Maven >> thinks. :-) > >Ok, slow down everyone. No worries. I just did a test and have found >that this approach fails miserably. It apparently wants the parent >pom to be available whenever I depend on this project, so obviously >this doesn't work. > >So no worries, I'm fully convinced that I want to use settings.xml to >specify repositories. But I'm still trying to find the best way to >specify a distributionManagement in each of my poms without >duplicating the <url>.
fwiw, I'm using a (globally installed) settings.xml here to specify where to retrieve artifacts from (a local nexus proxy). Most of the projects I work with use a parent pom that specifies a distributionManagement section, and it seems to work ok for the most part, but there are some drawbacks. Specifically, you'll run into issues when you need to change the distribution urls. To do that I need to either deploy a new release of the parent pom and change *all* of the other project poms to refer to the new release, or go manually remove the parent pom from nexus and deploy a changed one (which has all sorts of other problems). bleh. eric (btw, you'll hear a lot of people with a very fixed mindset regarding the supposed "one true maven way", but don't think that everyone agrees with that. I, for one, think the tools you use should guide you to a good methodology, but should have at least a little bit of flexibility to allow for the inevitable differences that pop up in real world projects without throwing up tons of roadblocks) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
