Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Kepler M4 is available! - the joy of using simple repositories

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


Back to the top