Community
Participate
Working Groups
Since Eclipse 4.2 is going be the primary base for Juno, we've started looking at build changes required in our product. The first blocker is that there is no zipped repository. An online repository does not work for us as we must be able to build in disconnected mode. So we need to be able to download a zip of the repository in order to stash it locally. Such zip is available on 3.x build pages, but not on 4.x build pages. The second blocker is that our build bootstraps creation of target platforms and all-in-one packages using eclipse-platform-[ver] zips, but on 4.x build pages, only the SDK variety of zips is made available. This doesn't work for us as we cannot be including the various extras that are present in the SDK build in our packages. Marking this as sev major as this is effectively preventing us from progressing further in validating viability of our product on 4.2 platform.
I have released changes to zip up the repository instead of leaving it as a folder. ie: http://download.eclipse.org/e4/sdk/drops/I20110816-2000/eclipse-4.2-I20110816-2000-repository.zip instead of http://download.eclipse.org/e4/sdk/drops/I20110816-2000/repository For other platform zips, it would be good if we can avoid creating all these extra zips, especially given bug 355430 . Once the primary SDK build is changed from 3.8 to 4.2, all of those zips will come for free and even then it would be good if we can reduce the number of zips being produced. Given the zipped 4.2 repository, any of the platform zips can be reproduced using p2. To create eclipse-platform-<ver>.zip do: <unzip src="eclipse-4.2-I20110816-2000-repository.zip" dest="${folder}" /> <p2.mirror source="file://${folder}"> <destination location="file://${platformRepo}" name="Platform Repo" format="file://${folder}" /> <iu id="org.eclipse.platform.feature.group" version="" /> <iu id="org.eclipse.equinox.p2.user.ui.feature.group" version="" /> <iu id="org.eclipse.rcp.configuration.feature.group" version="" /> <iu id="org.eclipse.equinox.executable.feature.group" version="" /> <slicingOptions includeOptional="false" includeNonGreedy="false" /> </p2.mirror>
> I have released changes to zip up the repository instead of leaving it as a > folder. Are these changes live in any of the published builds? I am not able to find a valid URL to the archived repository. Tried the following two URLS: http://download.eclipse.org/e4/sdk/drops/I20110816-2000/eclipse-4.2-I20110816-2000-repository.zip http://www.eclipse.org/downloads/download.php?file=/e4/sdk/drops/I20110816-2000/eclipse-4.2-I20110816-2000-repository.zip > For other platform zips, it would be good if we can avoid creating all these > extra zips I would suggest that if there is a desire to keep download artifacts to a minimum that eclipse-platform-<ver> zips are published in addition to the repository. That's because its the minimal starting point that will work for all scenarios. The provided SDK zips do not work for all scenarios. > Once the primary SDK build is changed from 3.8 to 4.2 When is this expected to happen? I will attempt to use the SDK zips as a temporary measure as soon as the repository zip is available. > Given the zipped 4.2 repository, any of the platform zips can be reproduced > using p2. That does not work. You cannot assume that p2 is present already. Our build uses the platform zips to bootstrap and acquire access to p2 in the first place.
(In reply to comment #2) > Are these changes live in any of the published builds? I am not able to find a > valid URL to the archived repository. Tried the following two URLS: The repository zip is available starting with I2011084-1000 > > Given the zipped 4.2 repository, any of the platform zips can be reproduced > > using p2. > > That does not work. You cannot assume that p2 is present already. Our build > uses the platform zips to bootstrap and acquire access to p2 in the first > place. If the problem is bootstrapping the build itself, the builder does not need to be the same version eclipse that you are building for. A common practice is to use org.eclipse.releng.basebuilder (http://wiki.eclipse.org/Platform-releng-basebuilder) which is a base eclipse containing pieces (including p2) needed to build the SDK. Another method would be to use the indigo platform zips. Builds tend to be less stable when running on the latest version of eclipse each week instead of a known good version.
> The repository zip is available starting with I2011084-1000 I do not see this build on the download page. http://download.eclipse.org/e4/sdk/ I did find I20110824-1000 build under e4 0.12 incubator release... http://download.eclipse.org/e4/downloads/drops/I20110824-1000/index.html Perhaps there is a misunderstanding of what is being asked... We aren't trying to consume from the incubator... > If the problem is bootstrapping the build itself, the builder does not need to > be the same version eclipse that you are building for. > > Builds tend to be less stable when running on the latest version of eclipse > each week instead of a known good version. We found the opposite to be true. When we were trying to use older versions of Eclipse during our bootstrap, the build would fail regularly with weird problems. The resolution of which was always "move to a newer bootstrap build, that one isn't compatible to what we are doing now.". :) In any case, the main question here is when is the flip to make 4.2 "primary" expected to happen. We can try to use the SDK zips as a temporary solution for now, but we would need to move to the proper minimal platform base as soon as possible.
(In reply to comment #4) > > The repository zip is available starting with I2011084-1000 > > I do not see this build on the download page. > > http://download.eclipse.org/e4/sdk/ Please try again. That was our old download page, which I have now replaced with a redirect. Let us know where you found that download link so we can update it. > In any case, the main question here is when is the flip to make 4.2 "primary" > expected to happen. We can try to use the SDK zips as a temporary solution for > now, but we would need to move to the proper minimal platform base as soon as > possible. Well, the Juno M1 packages were entirely built on 4.2, so in effect 4.2 is already the primary platform. I guess you're specifically interested in the builder changes. This part we had hoped to complete very early in Juno but the complexity of the Git migration has pushed it back. I dearly hope that is completed by M3, or M4 at the latest (early December '11). We really do want to cut down on the number of zips we produce though, given the bulk this adds to our build (each platform build is 6GB). Downloading the repository and using the ant task described by Andrew to create the desired zip file(s) would be a good short term (and possibly long term) solution.
> Please try again. That was our old download page, which I have now replaced > with a redirect. Let us know where you found that download link so we can > update it. Thanks! Found the referenced build and the zipped repo. > I guess you're specifically interested in the > builder changes. This part we had hoped to complete very early in Juno but the > complexity of the Git migration has pushed it back. I dearly hope that is > completed by M3, or M4 at the latest (early December '11). Thanks for the timeline. That should be fine assuming that SDK zip work as temporary replacement. Will know shortly. > We really do want to cut down on the number of zips we produce though, given > the bulk this adds to our build (each platform build is 6GB). I understand the desire to reduce the build disk footprint, but I hope you guys aren't seriously considering eliminating the eclipse-platform-[ver] zips. These zips together with the repo provide an easy path to any subset using only basic p2 install facilities (either via p2 UI or from the commandline). The same cannot be said about the SDK zips or the provided snippet of Ant. If I was looking to reduce the disk space usage, I'd cut SDK zips instead. Of course, that would be a terrible inconvenience for platform developers, so a reasonable stance would be to provide the platform zips and the SDK zips. I would venture to guess that the rest of the zips have far fewer uses.
My primary workstation was "in the shop" this morning so I had some time to collect statistics on the downloads in Indigo. The biggest candidate to drop is the Platform SDK zips: they are over 1.3GB, and only collectively had ~5000 downloads over two months. Eclipse Indigo (3.7.0) downloads - August 30, 2011 (two months) Eclipse SDK: 1,193,865 SWT zips: 23,753 Platform runtime binary: 4,726 Delta pack: 1780 Platform SDK: 624 RCP binary repo: 585 RCP source repo: 356 JDT binary repo: 537 JDT source repo: 262 ECJ batch compiler: 279 PDE binary repo: 227 PDE source repo: 226 CVS binary repo: 109 CVS source repo: 64 Jar processor: 81
(In reply to comment #7) > The biggest candidate to drop is the Platform SDK zips: they are over 1.3GB, > and only collectively had ~5000 downloads over two months. Sorry that should have read ~600 downloads. It was the platform runtime binary that had ~5000 downloads. > > Eclipse Indigo (3.7.0) downloads - August 30, 2011 (two months) > > Eclipse SDK: 1,193,865 > SWT zips: 23,753 > Platform runtime binary: 4,726 > Delta pack: 1780 > Platform SDK: 624 > RCP binary repo: 585 > RCP source repo: 356 > JDT binary repo: 537 > JDT source repo: 262 > ECJ batch compiler: 279 > PDE binary repo: 227 > PDE source repo: 226 > CVS binary repo: 109 > CVS source repo: 64 > Jar processor: 81
From a quick read, I think the issues discussed in this bug have been addressed now. Please reopen if I've misunderstood.
