Community
Participate
Working Groups
Right? It'd be nice to get this updated for M3. Currently for M2, it still has /releases/indigo, /eclipse/updates/4.1, and /e4/updates/0.11 We are currently planning to "remove" (never copy) feature update sites to the common repo. See bug 358415. Hence EPP package will need to "add their own" and users will have to add any specific ones they want (the thinking is, it is better than having 40 or 80 there, by default). To "balance" the picture, in my humble opinion, the Eclipse SDK and Platform "product" should (also) only have one repo, /releases/juno ... even though technically speaking it is a "product" similar to an EPP package. Its just that so many users start off with Eclipse SDK, that, to me, it seems odd and source of other project's discontent, that "Eclipse gets to add some update sites but no other project gets to do so". Also, I should point out, having /releases/juno and /eclipse/updates/4.2 is redundant, since juno will point to 4.2 repo, so that just adds "clutter" for no new functionality, IMHO. I know other view points are possible, but that's mine. If there are better solutions, I'm open to suggestions.
(In reply to comment #0) > Right? Yes! We should certainly updated to Juno, and stop including a link to the e4 incubator repository. > To "balance" the picture, in my humble opinion, the Eclipse SDK and Platform > "product" should (also) only have one repo, /releases/juno ... even though > technically speaking it is a "product" similar to an EPP package. Its just that > so many users start off with Eclipse SDK, that, to me, it seems odd and source > of other project's discontent, that "Eclipse gets to add some update sites but > no other project gets to do so". Also, I should point out, having > /releases/juno and /eclipse/updates/4.2 is redundant, since juno will point to > 4.2 repo, so that just adds "clutter" for no new functionality, IMHO. Is this a new change in Juno, that /releases/juno points to /eclipse/updates/4.2? I don't think we did that in past years (at least I can't see such a link in the indigo repository). I can agree that the platform runtime binary project does not need /eclipse/updates/4.2. The updates for this product are all found in the Juno repository. For the Eclipse SDK product, I'm not so sure. This product is no longer downloaded by a majority of the community thanks to EPP packages. In theory the audience for the Eclipse SDK "product" is people developing or contributing to the SDK. These developers may need extras such as the PDE execution environment descriptors, releng tools, etc. Now in practice many such developers will actually be using milestone or even integration build repositories, so in the end it doesn't make a big difference.
(In reply to comment #1) > (In reply to comment #0) > > Is this a new change in Juno, that /releases/juno points to > /eclipse/updates/4.2? I don't think we did that in past years (at least I can't > see such a link in the indigo repository). > Well, I guess it is only "partial" ... there is only one "content.jar", combining content metadata from repos at time of aggregation. Then, for artifacts, the platform is treated as a "trusted repository" (to avoid duplicating the massive amount of jars produced by the Eclipse Project). So, for example, for Indigo SR2, the composite artifacts jar/xml has <children size='2'> <child location='http://download.eclipse.org/eclipse/updates/3.7/R-3.7.1-201109091335'/> <child location='aggregate'/> So, it is not quite as general as I stated ... but, the idea is that, if someone installed, say, Platform only, they could still get PDE, JDT, etc. from the /releases/indigo repo (or, soon juno) without adding any further software sites beyond the /releases/indigo site. But, true, if the Eclipse Project added something new, off cycle, it would not automatically show up, since not in the common content.jar. (Just like other projects will be, without their own software sites in the list of software site).
Times about up for M3 ... sorry for the late reminder ... any chance this can be slipped in? To use /releases/juno at least? If other issues are controversial, they could be worked out and fined tuned later ... but, to have "indigo" in there doesn't help anyone. Thanks.
Created attachment 206128 [details] patch patch for 3.8 builds
Created attachment 206130 [details] patch for 4.2 stream builds
This bug slipped through the cracks. John, do you think this changes warrants a rebuild for 4.2/3.8 M3? I would think that if another team needed a rebuild, this change could be included.
We had a rebuild so this is fixed in 4.2 stream builds.
Closing.
