Is this similar to what I am experiencing? Perhaps not. My build fails when I change to jdk1.8. Works perfectly in jdk1.7 ... With no changes other than the change to the jdk ...
Build fails ... cannot resolve dependency ... Any suggestions? -----Original Message----- From: Stian Soiland-Reyes [mailto:st...@apache.org] Sent: Tuesday, October 18, 2016 8:00 AM To: Maven Users List Subject: Re: Comparing specifying repositories in pom vs. settings.xml? Yes, some years ago we did exactly this; most academic open source projects then didn't bother with Maven Central and we relied on 8 different open repositories around the world, often with dubious hostnames like rpc268.cs.example.edu:8080 -- this meant that although the build was reproducible for everyone at the time; often just one year down the line those repositories might have gone offline and caused long timeouts - or worse, serve a generic HTML page no matter what you request, giving checksum errors. So now the build of the old tag would fail, but worse, released modules that ultimately had that project pom as parent also started failing as dependency in newer code because those <repositories> are also consulted for transitive dependencies. (Even if that particular repo was not needed, Maven does not generally know which repo for which deps and consults all) So I would say, only add stable long-term repos to the parent pom, e.g. springsource or bintray repositories, while repo-of-the-day should be handled through a proxy Artifactory or Nexus server configured in .settings (enterprise) or top level pom (business open source), the proxy would then keep caches for a rainy day. Anything released open source should be pushed to Central (or at least a single place), even if it was made by someone who didn't bother themselves. On 18 Oct 2016 2:14 pm, "Curtis Rueden" <ctrue...@wisc.edu> wrote: > > I'm trying, without success, to imagine why you do not simply > > accumulate <server> elements as required. > > Wouldn't that cause Maven to ping every server sequentially for every > needed artifact? > > Better to set up a Maven repository manager (Nexus, Artifactory, etc.) > and proxy all the needed sources, no? Then your settings.xml is always > constant, pointing at your master Nexus, which groups all your needed > repositories. Your build is reproducible and remains resilient to > otherwise disruptive remote repository changes -- as long as your > master Nexus does not change. > > > On Tue, Oct 18, 2016 at 8:03 AM, Mark H. Wood <mw...@iupui.edu> wrote: > > > On Mon, Oct 17, 2016 at 08:03:03PM +0000, KARR, DAVID wrote: > > > 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. > > > > I'm trying, without success, to imagine why you do not simply > > accumulate <server> elements as required. Before long you should > > reach a state in which new additions are extremely rare. > > > > -- > > Mark H. Wood > > Lead Technology Analyst > > > > University Library > > Indiana University - Purdue University Indianapolis > > 755 W. Michigan Street > > Indianapolis, IN 46202 > > 317-274-0749 > > www.ulib.iupui.edu > > > ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
