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

Bug 338363

Summary:	automatically compute bundlesToUnzip.properties
Product:	[Tools] Orbit	Reporter:	David Williams <david_williams>
Component:	releng	Assignee:	DJ Houghton <dj.houghton>
Status:	RESOLVED FIXED	QA Contact:	Project Inbox <orbit.releng-inbox>
Severity:	enhancement
Priority:	P3
Version:	unspecified
Target Milestone:	Indigo M6
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description David Williams

2011-02-27 22:26:08 EST

This is follow-on work relate to bug 334488. 

To do away with the "bundles" directory, we came up with a quick and easy way to denote which should be marked as "unpack=true" by hard coding the list of bundles in a file named 'bundlesToUnzip' in the maps directory. 

While this list would not change often, it would be more bullet proof to compute the list based on the "original" data in the feature.xml file, or perhaps the repository metadata. 

So, just opening this enhancement to track the eventual improvement. 

In the mean time, if someone adds a new bundle that should be unzipped when installed, then they will have to update the bundlesToUnzip.properties file in the maps directory.

Comment 1 David Williams

2011-02-28 01:16:55 EST

I should note, besides being used to create the "get http" maps, this bundlesToUnzip.properties file is copied over to download site, and used in the php download page so entries in the table of bundles can be labeled with 'unzip' so users would have some indication to unzip these jars, if they download them individually (though, we hope people normally use p2 to do installs).

Comment 2 David Williams

2011-02-28 02:58:02 EST

FYI, until we automate this, I've updated the instructions in our Wiki to mention it. Hopefully not needed much. See 

http://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#Adding_your_bundle_to_the_feature.xml

Comment 3 DJ Houghton

2011-03-02 15:31:26 EST

This scares me because I know I am going to be the first person to break the build because I forgot to update the file. :-)

I'll take a look at putting together some code to generate the file from the feature.xml.

Comment 4 DJ Houghton

2011-03-02 16:13:13 EST

David, my php is rusty and I'm poking around the php files in the builder. How exact do we have to be for the versions in order for it to match?

Currently I have output like: 
   org.junit,3.8.2.qualifier
and I can get rid of the .qualifier but am wondering what happens if we have 1.0.0.20_qualifier or something wacky like that.

Comment 5 DJ Houghton

2011-03-02 16:32:12 EST

I released the first cut of the class to the tools project but didn't create the taskdef or hook it into the builder yet.

Comment 6 David Williams

2011-03-02 16:48:57 EST

(In reply to comment #4)
> David, my php is rusty and I'm poking around the php files in the builder. How
> exact do we have to be for the versions in order for it to match?
> 
> Currently I have output like: 
>    org.junit,3.8.2.qualifier
> and I can get rid of the .qualifier but am wondering what happens if we have
> 1.0.0.20_qualifier or something wacky like that.

The rest of the code just looks at the first three fields ... as a string. 
Since having two bundles with the first three fields the same, and the qualifier prefix be different AND requires to be unzipped seems rare enough I wouldn't bother.  But, if you wanted to code and test ... it probably would work automatically if you stored 1.0.0.20 in the file. ... since we just use that version as a string match.

Comment 7 David Williams

2011-03-02 16:50:10 EST

(In reply to comment #3)
> This scares me because I know I am going to be the first person to break the
> build because I forgot to update the file. :-)
> 
> I'll take a look at putting together some code to generate the file from the
> feature.xml.

Thanks for handling this ... I need to better remember to break up tasks into small pieces ... then someone else likely to finish what I start. :)

Comment 8 DJ Houghton

2011-03-02 17:12:57 EST

No problem. 

For the version, I agree that those cases are specialty ones and I think for now I can just drop the .qualifier and put the resulting version in the file.

I've done the following:
- released the code to the tools project
- updated the tools.jar in the builder project
- added the taskdef in the build.xml in the builder project

So I think all that's left is:
- modifying the builder to call the new task
- not sure if we have to modify any of the current code which reads the file or it just expects it to be there?
- tagging the new builder so it gets used

I think this is how we want to call it:

<eclipse.bundlesToUnzipGenerator
            inputFile="${buildDirectory}/features/org.eclipse.orbit.build.feature.set1/feature.xml"
            outputDir="${buildDirectory}/" />

Do you mind making those changes? I'm not sure the best place to put it in the build and you're probably the best bet at noticing an error.

Comment 9 David Williams

2011-03-02 19:14:19 EST

> Do you mind making those changes? I'm not sure the best place to put it in the
> build and you're probably the best bet at noticing an error.

Hey, wait ... now you are just waiting for someone to finish your work! :) 

Much appreciated. I did some quick test builds, tweak as few things, then committed and released, removed the old properties file, removed the wiki instructions, and started a new production build. Probably only thing to check closely is if 10 bundles still marked as "unzip" and if so not much could be wrong. 
 
Thanks again,

Comment 10 DJ Houghton

2011-03-03 07:30:36 EST

Thanks, David. I was just breaking the task into smaller pieces so others could have the opportunity to contribute. ;-)