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 [] 
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 -- 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" <> 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 <> 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
> >
> >

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

Reply via email to