Re: [cross-project-issues-dev] Kepler M4 is available! - the joy of usin

[David M Williams <david_williams@xxxxxxxxxx>]

The only rational reason that wouldn't
be a in your control (i.e. a fault in your repo), is if someone (else)
depends on and pulls in some of your artifacts. 

You can sometimes tell if this is happening
by searching the log from the run, in this case

https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runaggregator/254/consoleFull

You'd search for lines that matched
"mirroring artifact.*<your
artifact>" and then search backwards in the log for what prompted
that; 
lines that match Mirroring
artifacts from.*<someone's
repository>". I glanced and didn't see anything obvious. 

This is one reason why, for "builds",
I always recommend people use as specific a repo as they can, preferably
one that has just one version of the artifacts in it. For example, 
in the Platform, while we have a handy
composite URL for users to install things from: 
http://download.eclipse.org/eclipse/updates/4.3milestones/
we use a very specific URL for our aggregation
contribution, that is only M4
http://download.eclipse.org/eclipse/updates/4.3milestones/S-4.3M4-201212140730/
(We employ the same "specific URL"
principle in the input to our own builds too (e.g. from EMF), so we are
a little more assured we get exactly what's expected, and things won't
change without us controlling it). 

I should note, this is just the way p2
in general works (by design) ... its not specific to the aggregator. 

Another possibility, that's very rare,
in my experience, and unlikely to be the issue here ... is that p2 essentially
guarantees it comes up with a solution to all the range constraints, not
necessarily the one best solution. I've read where there's a few cases
it doesn't search exhaustively and will rest when its satisfied its worked
hard enough. But again, very rare from what I can tell (only one suspect
case in the past 3 or 4 years) ... just thought I'd mention it for completeness.


If you have the patience for it, you
can investigate deeper by creating your own (local) project for some aggregation
files, and include subsets of the complete common-repo files, and see what
differences there are having some enabled and some not. 

I'll turn aggregation back on now, so
you could investigate if you using a specific URL makes any difference
... but I'm pretty sure it will fail when I turn it back on, so you may
have to wait till others fix their contributions. 

HTH






From:      
 Greg Watson <g.watson@xxxxxxxxxxxx>
To:      
 Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>, 
Date:      
 12/21/2012 12:37 PM
Subject:    
   Re: [cross-project-issues-dev]
Kepler M4 is available!
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

David,

I just checked the kepler repository and it appears that
some of the PTP features are the M4 versions and some are the M3 versions.
I realize it is too late to do anything now, but I'm wondering how this
can happen? We use a composite repository, so I presume it has something
to do with that. Why would the aggregation pick up different versions like
this?

Greg

On Dec 21, 2012, at 9:02 AM, David M Williams <david_williams@xxxxxxxxxx>
wrote:

Congratulations! 

M4 is ready, well mirrored, and ready to install from .../releases/kepler.

The EPP packages will be available soon (if they are not already) from
http://www.eclipse.org/downloads/index-developer.php

Thanks for everyone's help getting these out and contributing to Eclipse.

Best wishes for your holiday season. 


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev