Hello, For ensuring that artifacts not go away (like recently some older JBoss public repos) for enforcing licensing and security restrictions, for caching the internet, and of course for having a single aggregated repository view we run a single company server (with a filtered central and other repos mirror). Then this is the only repo configured. (We do that in the Parent for most internal projects but it js much better to set that up in settings.xml).
Btw, We also used to use this server for exchanging snapshots, however the use of them between different people and builds have been greatly reduced lately with focusing on release builds. I think you cant run a reliable and repeatable software production without. Gruss Bernd -- http://bernd.eckenfels.net >From Win 10 Mobile Von: Tamás Cservenák Gesendet: Dienstag, 18. Oktober 2016 09:17 An: Maven Users List Betreff: Re: Comparing specifying repositories in pom vs. settings.xml? "The best way is to sync your stuff to the Central Repository" -- true, but again, there are cases where this is _not possible_. What then? I feel we keep repeating this mantra, but leaving out some cornerstones... On Tue, Oct 18, 2016 at 12:04 AM Manfred Moser <manf...@simpligility.com> wrote: > The best way is to sync your stuff to the Central Repository imho. > > Otherwise you are probably best off with using repositories in the POM or > a checked in settings file and build.sh reference command build like mvn -s > ... > > manfred > > Curtis Rueden wrote on 2016-10-17 15:00: > > > Hi everyone, > > > > I have an OSS project with "mixed" dependencies—some in central, and some > > in our public Maven repo (because they are still in incubation or > > beta). Every time this discussion arises, I find myself wondering the > same > > thing: how can you achieve an "out-of-the-box" build for such a project, > > without specifying <repositories>? All the alternatives I see people > > suggest (e.g., checking in settings.xml to the repository) would require > > each and every new developer to perform some one-time bootstrap before > the > > project will build. This will turn away many new & inexperienced > developers > > if they try to import the project into their favorite IDE and it fails to > > build. > > > > Regards, > > Curtis > > > > -- > > Curtis Rueden > > LOCI software architect - http://loci.wisc.edu/software > > ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden > > > > > > On Mon, Oct 17, 2016 at 4:48 PM, Manfred Moser <manf...@simpligility.com > > > > wrote: > > > >> If you really feel you need to control the source of where you download > >> components from within the source control system > >> I would still NOT use the repositories definition in the POM since that > is > >> them transferred to the target repo on deployment (unless you use > flatten). > >> > >> Instead I would check in a specific settings.xml as part of the > project... > >> or even multiple ones for different build scenarios.. > >> > >> Manfred > >> > >> KARR, DAVID wrote on 2016-10-17 14:42: > >> > >> >> -----Original Message----- > >> >> From: Manfred Moser [mailto:manf...@simpligility.com] > >> >> Sent: Monday, October 17, 2016 1:35 PM > >> >> To: users@maven.apache.org > >> >> Subject: Re: Comparing specifying repositories in pom vs. > settings.xml? > >> >> > >> >> > http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms- > >> >> is-a-bad-idea/ > >> > > >> > The point about open-source projects is well-taken. I would never > >> specify > >> > repositories in a POM for a public project. > >> > > >> > The section about "Enterprise" just seems odd to me. It seems very > >> focused on > >> > "central", when that might not be the case at all. We use many > >> open-source > >> > projects, but those aren't very volatile. We use dozens of internal > >> artifacts, > >> > and there isn't a lot of doubt about what repos to get particular > kinds > >> of > >> > artifacts from. I find build repeatability more important (specifying > >> all > >> > requirements in the build script). The requirement about "generally > >> will want > >> > all your developers using the same set of repositories" is pretty > >> important to > >> > me, but the recommended solution just seems counterproductive. > >> Specifying it > >> > in the POM for the project seems to be the most direct way to ensure > >> that. > >> > > >> >> KARR, DAVID wrote on 2016-10-17 13:03: > >> >> > >> >> > One thing I run into when jumping between different projects is > >> >> > different expectations for what maven repos I need to be using. In > >> >> > the past, I had to have multiple copies of "~/.m2/settings.xml" > lying > >> >> > around, and I would hack the specified repos when I needed to. > >> >> > > >> >> > Recently, I saw a situation where the required repositories were > >> >> > simply defined in the top-level pom for the project. If this is > done > >> >> > consistently, there's no longer any need to hack the settings.xml > >> >> file. > >> >> > > >> >> > I seem to remember seeing some advice that specifying repositories > in > >> >> > the POM is a bad practice. If I'm remembering this correctly, this > >> >> > seems odd. Forcing the correct repos to be defined in the > >> >> > settings.xml works against "repeatable builds". > >> >> > > >> >> > What is the recommended advice here? > >> >> > > >> >> > > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> >> > For additional commands, e-mail: users-h...@maven.apache.org > >> >> > > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> >> For additional commands, e-mail: users-h...@maven.apache.org > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: users-h...@maven.apache.org > >> > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
