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

Bug 334487

Summary:	avoid 'bundles' directory on download page links
Product:	[Tools] Orbit	Reporter:	David Williams <david_williams>
Component:	releng	Assignee:	David Williams <david_williams>
Status:	RESOLVED FIXED	QA Contact:	Project Inbox <orbit.releng-inbox>
Severity:	normal
Priority:	P3	CC:	dj.houghton, pwebster
Version:	unspecified
Target Milestone:	Indigo M6
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description David Williams

2011-01-16 19:45:09 EST

Currently, on a builds download page, in the big table of bundles produced, we link to each bundle in that build, and link to the version in the 'bundles' directory. To avoid redundancy, we should point to the version in the 'repository/plugins' directory. Eventually, then, we could get rid of the 'bundles' directory, and provide only the 'repository'. 

On that one hand, that'd be pretty simple change to make. But, on the other hand ... currently the bundles in the 'bundles' directory are of two types; jars and zip files. This is meant as a subtle documentation that the jar files can be used as-is (as jars) but the zip files are intended to be unzipped in an installation. This corresponds to a feature.xml file's specification of unpack=false/true for a given bundle. 

Once we change to point to the bundle in 'repository/plugins' directory, all bundles will be jars. 

So, ideally, I propose, we'd still provide this documentation as part of the big table, by adding a column named "unpack?" and put a "yes" in the cells that should be unzipped in most installations. 

To do that easily, we may want to provide some special/extra file as part of the build that lists which are meant to be unpacked in installs ... the php file that produces the table could then read this file ... instead of, for example, having to read/parse the content.jar/xml file for the repository. Maybe.

Comment 1 DJ Houghton

2011-01-17 11:37:46 EST

I'm not sure if it is easier, but perhaps an interm step would be to have both .zip and .jar files in the repository for the JARs which need to be expanded? At least that will reduce duplication of the regular JAR'd bundles.

Comment 2 David Williams

2011-02-27 22:30:44 EST

I've made the change so the download page points to ../repository/plugins/ jars, instead of ../bundles directory. And, the bundles directory is no longer produced. 

So far, I do not "mark" the entries in the table as needing to be unzipped when installed (usually) so I'll leave this open. Just wanted to document progress so far.

Comment 3 David Williams

2011-02-28 01:18:26 EST

Decided to go ahead and hack this up. Still building, but my local test worked ok (eventually). 

Note to cross-reference, see bug 338363 for some potential future work that might effect how this download page is done.

Comment 4 DJ Houghton

2011-02-28 08:43:29 EST

Cool, thanks for doing this David. And I'm sure that the webmaster will appreciate the savings per build in disk space. :-)