Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #356561 +++ There is a relatively new feature of p2 (introduced in Juno, I believe), that allows one to mark a composite repo as "atomic", so that if one of the children can not be loaded, then the whole repository is considered "can not be loaded". From my reading of bug 356561 our common repo fits the use case where we want the whole composite repo to "act as one". In practice, this would seldom make any difference at all in how the repo behaves, since our composites meta data do not come from "other servers" that might be down, off-line, unreachable, etc., but in theory it could have some impact. For example, when Juno site was recently partially disabled for a week for EPP updates (due to a bug in meta data, that hurt Mac updates) it _might_ have had the effect of disabling the whole Juno repository site, depending on exactly how the "disabling" was done. In that example, if Markus had disabled SR1 EPP updates simply by renaming the child directory, it would have disabled the whole repo. If he had disabled it by actually removing the child from his composite site files, they would have still been valid, and whole site would have still been valid. I believe. So, just saying, such things will have to be considered in future and possibly coordinated. Another interesting case to keep in mind, sometimes (rarely, I think) the webmasters auto redirect (silently) requests for metadata to other servers. Pretty sure this would not cause any problems with this atomic property ... I'm just saying I'm not sure. And, if it did, this might be the type of effect where the whole repo would appear "disabled" if part of it was not reachable, which would be the intended (good) behavior this change is trying to accomplish. So, my plan/proposal is to try this for Kepler composite now, and for next milestone or two, and if no odd problems seen, then apply the same improvement to Juno SR2. I should note, for the casual reader, this property should not be blindly applied to all composite repos, since some projects use repos where they basically know that not all children are necessarily (still) available, but they know there have been more recent replacements for those children. So, be sure to read bug 356561 if you are considering for your own projects. Let us know if any concerns, questions, clarifications for use in the main, common repo.
I've now made the change to compositeContent.jar/xml in .../releases/kepler It has 3 children at the moment. 2 of them are subdirectories which are simple repositories (not composites). The third is http://download.eclipse.org/technology/epp/packages/kepler/ So ... that'd be up to Markus to fix/change.
Regarding the referenced EPP repository... since the last two weeks I am very confident again that it is the right decision *not* to include the EPP repository content into the main simultaneous release repository. The separation enables us to react to problems like we had with the Juno SR1 update. Back to the main topic: Up to Indigo the EPP repository at /technology/epp/packages/... had been a composite repository, but we changed this in Juno for (p2) performance reasons. Since Juno /technology/epp/packages/juno (and .../kepler) is *not* a composite repository any more. The directory contains separate entries for the milestone and release candidate builds, but the release is done by mirroring only the relevant repositories into one. So my short answer is: I don't think we need to change anything in EPP because we do not use composite repositories for the releases any more.
(In reply to comment #0) > In that example, if Markus had disabled SR1 EPP updates simply by renaming the > child directory, it would have disabled the whole repo. If he had disabled it by > actually removing the child from his composite site files, they would have still > been valid, and whole site would have still been valid. I believe. This is correct. To remove a child, remove the entry from the compositeContent.xml
I have added this property to Juno's compositeContent.jar/xml file. (And, the way I do these composites for releases, it will just be carried over next month for the official Juno SR2. But, it's in there now, also). <property name='p2.atomic.composite.loading' value='true'/> As always, let me know if problems.
