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
