Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cross-project-issues-dev] Changes coming soon to Orbit download pages and structure ...

None of these changes should break or negatively effect anyone ... but, they are large enough they deserve some explicit mention here on cross-project list, just in case.

If it does effect anyone ... let us know over in Orbit ... open a bug, or comment on one of the existing ones mentioned below.

1) (small) change to retention policy for active builds: We will still keep everything forever that was ever "released", as before, but we are going to be a bit more aggressive in removing _old_ versions from active builds for the next release. For example, instead of continuing to build 7 versions of ICU ... we might just build the most recent two or three versions ... everyone should be on the most recent version anyway (in most cases), and if you need a older one, it will still be there in the archives. And no removals after M6. Just open a bug if you need something 'active' that we removed. [Initial, low hanging fruit made repo 25% smaller (200 M to 150 M) so it will be worth some streamlining!].

2) massive "installable" zip replaced by massive zip of p2 repository. It should be of more general use. The old one was made for the old "install by unzipping into eclipse" model, which has not even worked anyway for Orbit bundles, for a very long time. Now you can actually have a local copy of the whole zipped repo, and use it in your target runtime. (bug 274837).

3) URL for http access repo documented on each download-build page. (All experienced release engineers knew where it was ... but no one else).   (bug 274837). Again, should be able to use it in your runtime targets.

The above items can be "seen" in the latest I-build, the rest will be implemented soon.

4). The get-http style of map file has been marked as "deprecated", and we encourage release engineers to use the p2 style in their builds. It should be very easy to migrate to consume p2 style. Do let us know if not. The get-http style will not be going away anytime soon ... but, we are going to make some "internal" changes to its exact data so a) always a tiny risk of it not working as before (a very tiny risk in this case) and b) if anyone has any custom programs which do some custom parsing of these map files you might want to check if you've hard coded any assumptions on URL paths or unzipping bundles that are supposed to be unzipped. (See bug 334488).

5). Ok, I lied ... this item might effect some developer's routine workflow ...  if you are old fashioned and work like me. :) Until now, the link to individual bundles on download pages have been pointing to either jars or zip files, the zip extension was a small hack to make the files "self documenting" -- they should be unzipped if zip extension, or, leave as jars, if a jar extension. To avoid redundant processing and storage we'd like to just point to the jars in the repository so the "documentation" of whether or not to unzip will be on the download page itself, and you'll have to check if a jar should be unzipped in your install. This does not effect anything if you use map files in your builds. This does not effect anything if you use p2 to install bundles or add a runtime target. This might effect you only if you construct your own custom development environment and individually download and "install" a bundle into 'dropins' folder (or similar), which should be unzipped (like ant, or soap) so an alternative to reading download page information is to use p2 and/or take advantage of using runtime targets. But do please comment in bug 334487 if you think this change is negative and we'll reconsider. (I am probably the only person left who does it the old fashioned way :)


Back to the top