maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Haszlakiewicz, Eric" <>
Subject RE: Company-wide settings
Date Mon, 04 Oct 2010 19:05:54 GMT
>-----Original Message-----
>From: Phillip Hellewell []
>On Mon, Oct 4, 2010 at 12:30 PM, Anders Hammar <>
>> Philip, with all due respect, but reading your posts I get the
>> you're doing your best not to follow Maven best practice. Maven is
>> convention and best practice patterns. Please acknowledge that our
>> based on actual experience and going your own path will surely get
>> trouble! It's not really a matter of what you think, but rather what
>> 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.


(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:
For additional commands, e-mail:

View raw message