Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 422366

Summary: use target file to specify repositories and exact version of non-platform prereqs
Product: [Eclipse Project] Platform Reporter: David Williams <david_williams>
Component: RelengAssignee: David Williams <david_williams>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, irbull, jan.sievers, krzysztof.daniel, l.kirchev, Lars.Vogel, pascal.rapicault, pwebster, t-oberlies, thanh.ha, tjwatson
Version: 4.3.1   
Target Milestone: 4.3.2   
Hardware: PC   
OS: Linux   
Whiteboard:
Bug Depends on: 422302    
Bug Blocks: 372792, 393922    

Description David Williams CLA 2013-11-22 14:12:13 EST 
+++ This bug was initially created as a clone of Bug #400518 +++

Now that the "Orbit case" has been fixed, in bug 400518, it should be easy enough to specify other "prereq repositories" in a similar way .... in rough order of importance ... ECF, Jetty, EMF, AscpectJ, and EGit.

But, its also a little lower priorities, since for those we use specific, non-composite repos. It would seldom be technically necessary (as it is with Orbit ... where we definitely do not always want "the latest" version) ... but is still worth doing, since 1) it serves as a "guard" against another project changing something without us knowing about it, and maybe more important, 2) an easy way for developers/committers to "load up" the latest (or hypothetical) prereqs as PDE runtime target to do early checks and tests for the few times prereqs change. 

Ideally we'd do this for both Luna and Kepler, since if anyone wants long term, post "Kepler SR2" support, that is one of the most important times to have prereqs firmly specified. 

Its also interesting to note that specifying "whole repositories" and letting Tycho resolve as it likes, sometimes hides other bugs or hidden assumptions, such as 4 discovered while doing the Orbit work: bug 422103, bug 422102, bug 422101 and perhaps bug 422302.

Not to mention ... specifying the exact versions reminds me of map files. :)
Comment 1 David Williams CLA 2013-11-29 14:41:17 EST 
I have now committed "exact prereq" target for master (Luna 4.4 builds) and also Kepler (4.3 SR2). 

The main commit for the maintenance stream was 

http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_3_maintenance&id=a1070a5f2cf95fff3df7cd7ebb093f66a68a7588

You can search for commits related to "Bug 422366" on either stream, to find all commits related to this change. 

http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/log/?qt=grep&q=Bug+422366

To cross-reference, bug 422631 was caused by some of these changes, so required a change to the file we use to save "maven properties", but we were not really using those for anything (and the target file itself gives "the exact" URLs used, so no need to "save" those. 

Just to be fully document it here, there is/was one complication for the EMF repo URL -- it is actually used for two purposes, so it is left as a variable. To quote the comment in parent pom: 

    <!-- 
      NOTE: this EMF URL must "match" exactly what is in the eclipse-sdk-prereqs.target file. 
      We use it (the EMF repo) not only for resolving pre-reqs during the build, but also in 'repository' POM for mirroring
      a copy of the EMF features into our own repository. This is required since we merely "require" EMF (not "include" it).
      And, of course, in the PDE target file, the URL is expected to be the actual URL, not a variable. 
    -->
    <emf-repo.url>http://download.eclipse.org/modeling/emf/emf/updates/2.10milestones/base/S201310280429/</emf-repo.url>
Comment 2 David Williams CLA 2013-11-29 14:48:55 EST 
Also, just to document it, committers need to be aware that if they add a "prereq" (such as from Orbit) then the file eclipse-sdk-prereqs.target will need to be updated to specify the IU (and version). A bug should be open in releng when pre-reqs change. 

(And, it should be edited with text editor, since there are some comments in the file that we should try to maintain, at least for now) as well as we specify both "bundle IUs" and "feature IUs" and not sure the "target editor" can do both. 

[For routine cases, such as when we move to a new build of Orbit, release engineers will update the target file ... both the URL and the exact versions of pre-reqs ... if/when they change.]. 

In addition to providing better re-producible builds, the target file in the aggregator,  eclipse-sdk-prereqs.target, can be used by developers directly in the IDE to "get" the pre-req bundles needed. This should be helpful in a number of use cases.