I also happen to know that there are/used to be "features" in Nexus groups that leave orphan checksum files hanging around. As well as metadata files *I think*...
/Anders On Wed, Jun 5, 2013 at 2:34 PM, Stephen Connolly < [email protected]> wrote: > What Anders is saying is that Nexus should not be proxying proxies, but > rather proxying the original source. > > i.e. you have something like > > http://your-nexus/content/groups/public > > which is an aggregate view of > > http://my-nexus/content/groups/public > http://his-nexus/content/groups/public > > What you really should be doing is have it as an aggregate view of > > http://my-nexus/content/repositories/foo > http://my-nexus/content/repositories/bar > http://his-nexus/content/repositories/manchu > http://his-nexus/content/repositories/barfoo > http://repo1.maven.org/maven2 > > That would allow you to set the priorities for each appropriately and > ensure that you have e.g. central hosted artifacts resolved from central. > > By aggregating the aggregates you have duplicate artifacts and conflicts > and start to rely on the priority rules, plus you cannot move and > reprioritise content as easily. > > > > > On 5 June 2013 13:26, Henri Tremblay <[email protected]> wrote: > > > Why? Maven allows a mirror to be a mirror of many repositories. So why > > should I avoid it? > > > > Knowing that, unless I'm mistaken, doing this grouping prevent maven to > > look into many repositories for each download. > > > > > > On 5 June 2013 14:15, Anders Hammar <[email protected]> wrote: > > > > > You shouldn't be proxying a Nexus group, but rather the specific > repo(s) > > > that you need. > > > > > > /Anders > > > > > > > > > On Wed, Jun 5, 2013 at 1:46 PM, Henri Tremblay < > [email protected] > > > >wrote: > > > > > > > I digged a bit and, helped by your thought, seem to have found the > > cause. > > > > > > > > We use Nexus to be a mirror of many repositories. All these public > > > > repositories are in a group which is defined to be the mirror in our > > > > settings.xml. > > > > > > > > On of these public repositories is JBoss ( > > > > > > > > > > > > > > https://repository.jboss.org/nexus/content/groups/public/org/jvnet/staxex/stax-ex/ > > > > ). > > > > And if you have a look at the url, for version 1.2 there is only a > md5 > > > and > > > > a sha1. No actual maven-metadata.xml file. My guess is that it's what > > > keeps > > > > the download to happen. > > > > > > > > I tried to put maven central first in the group hoping it will solve > > the > > > > issue. It didn't. > > > > > > > > Someone have a workaround apart from removing JBoss from there? (or > > > using a > > > > higher version of stax-ex which I will need to test) > > > > > > > > Thanks, > > > > Henri > > > > > > > > > > > > > > > > On 5 June 2013 12:19, Martin Gainty <[email protected]> wrote: > > > > > > > > > it is possible the remote repositories cannot be reached so a > > metadata > > > > > stub is put into your local repository indicating the attributes of > > the > > > > > plugin maven is looking for..here is an example > > > > > > > > > > <?xml version="1.0" encoding="UTF-8"?> > > > > > <metadata> > > > > > <groupId>com.opensymphony</groupId> > > > > > <artifactId>xwork</artifactId> > > > > > <version>2.1.6-SNAPSHOT</version> > > > > > <versioning> > > > > > <snapshot> > > > > > <timestamp>20090909.201054</timestamp> > > > > > <buildNumber>1</buildNumber> > > > > > </snapshot> > > > > > <lastUpdated>20090909201054</lastUpdated> > > > > > </versioning> > > > > > </metadata> > > > > > > > > > > personally I always install all necessary plugins to my > > > local-repository > > > > > and then operate off of my local repository to avoid any guesswork > on > > > > which > > > > > repository is online or offline > > > > > mvn -o $COMMAND > > > > > > > > > > can you send us your pom.xml and the exact command syntax with a > list > > > of > > > > > all the repositories you are referencing > > > > > from $M2_HOME/conf/settings.xml so we can replicate this issue > > > > > > > > > > Bon Chance, > > > > > Martin > > > > > ______________________________________________ > > > > > Note de déni et de confidentialité > > > > > > > > > > Ce message est confidentiel et peut être privilégié. Si vous n'êtes > > pas > > > > le > > > > > destinataire prévu, nous te demandons avec bonté que pour > satisfaire > > > > > informez l'expéditeur. N'importe quelle diffusion non autorisée ou > la > > > > copie > > > > > de ceci est interdite. Ce message sert à l'information seulement et > > > > n'aura > > > > > pas n'importe quel effet légalement obligatoire. Étant donné que > les > > > > email > > > > > peuvent facilement être sujets à la manipulation, nous ne pouvons > > > > accepter > > > > > aucune responsabilité pour le contenu fourni. > > > > > > > > > > > > > > > > From: [email protected] > > > > > > Date: Wed, 5 Jun 2013 11:48:27 +0200 > > > > > > Subject: Re: Release dependencies keep getting downloaded > > > > > > To: [email protected] > > > > > > > > > > > > Ok. I managed to check. > > > > > > > > > > > > So no, there is no range like in your example from what I see. > The > > > > > > dependency tree tells me that com.sun.xml.ws:jaxws-rt:jar:2.1.7 > is > > > > > > referencing version 1.2 and that's it. > > > > > > > > > > > > I just realized that the problem occurs when I'm using the -U > > option. > > > > The > > > > > > help is telling that it "Forces a check for updated releases and > > > > > snapshots > > > > > > on remote". It's a bit weird that rekeases are checked but why > not. > > > BUT > > > > > why > > > > > > is staxex maven-metadata.xml file the only one the keeps being > > > > > downloaded? > > > > > > (with groovy-eclipse-batch that also is)??? Some timestamp issue? > > > > > > > > > > > > > > > > > > > > > > > > On 29 May 2013 15:40, Stephen Connolly < > > > > [email protected] > > > > > >wrote: > > > > > > > > > > > > > it would look something like <version>[1.7.3,)</version> but > most > > > > > likely it > > > > > > > will be a transitive dependency that some dependency of yours > is > > > > > pulling > > > > > > > in. > > > > > > > > > > > > > > have a look at the output of dependency:tree > > > > > > > > > > > > > > > > > > > > > On 29 May 2013 14:35, Henri Tremblay <[email protected] > > > > > > wrote: > > > > > > > > > > > > > > > A version range? > > > > > > > > > > > > > > > > How can I have a version range in a dependency tree? Aren't > > > > > dependencies > > > > > > > > always fixed values? > > > > > > > > > > > > > > > > How can I check that? > > > > > > > > > > > > > > > > > > > > > > > > On 29 May 2013 14:34, Stephen Connolly < > > > > > [email protected] > > > > > > > > >wrote: > > > > > > > > > > > > > > > > > I would guess you might have a version range in your > > dependency > > > > > tree > > > > > > > > > > > > > > > > > > > > > > > > > > > On 29 May 2013 13:30, Henri Tremblay < > > [email protected] > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Some of metadata.xml files are downloaded for every build > > > done > > > > > from > > > > > > > > > > Jenkins. > > > > > > > > > > > > > > > > > > > > I don't know why. One example is > > > org.jvnet.staxex:stax-ex:1.7.1 > > > > > > > > > > > > > > > > > > > > -X doesn't tell me anything > > > > > > > > > > > > > > > > > > > > How can I find out? (including where to put a breakpoint > in > > > the > > > > > maven > > > > > > > > > > source code) > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Henri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
