Bug 361067

Comment 1 David Williams 2012-01-18 23:50:35 EST

Initial (test) build in progress. (after doing some small tests on my local machine. 

There was one thing that we did use from "basebuilder" and that was a "countFiles" tasks to record number of zips and archives in a file named files.count. But, that's pretty easy to accomplish with recent versions of Ant, by using relatively new "resourcecount" built-in task. 

    <target name="countFiles">
        <resourcecount property="files.count">
            <fileset dir="${resultDir}">
                <include name="*.zip"/>
            </fileset>
        </resourcecount>
        <echo file="${resultDir}/files.count">${files.count}</echo>
    </target>

And, naturally, had to change they way we "get" the "basebuilder". I left basic terminology and locations the same same, such as there is still a "getBaseBuilder" task, but under the covers it simply gets the eclipse SDK specified in dependencies.properties. 

Once changed area, I'd forgotten about, was that we could no longer use the "eclipse.launcher" jar to start eclipse from java tasks (since, the version number or qualifier would frequently change. So, instead of 


        <java
            jar="${eclipse.launcher}"
            fork="true"
            failonerror="true">

I changed to the common pattern of using

        <java
            classname="org.eclipse.equinox.launcher.Main"
            fork="true"
            failonerror="true">
            <classpath>
                <fileset dir="${pde.builder.path}/plugins">
                    <include name="org.eclipse.equinox.launcher_*.jar"/>
                </fileset>
            </classpath>

Comment 2 David Williams 2012-01-18 23:56:59 EST

Just to document it, we had been using org.eclipse.releng.basebuilder version R37_M7 (that last known tagged one ... when I last looked, months ago) and now, for our initial test build, I am using Eclipse SDK from R-3.7.1-201109091335, which I'm pretty sure is "close enough" to give identical results for our simple Orbit assembly builds. 

After confirming the initial test build looks right, I'll move up to Eclipse SDK 3.8 M4, which will be substantially different in the metadata produced, as desired for bug 368999.

Comment 3 David Williams 2012-01-19 00:06:29 EST

To leave a little record here, the version of the Orbit builder we used (for Juno) before the change was v201112151816. The tag of the (first) basebuilder-free version is  v201201190330. 

For Indigo maintentance, the orbit builder tag is v201111250704 (which, as I recall, is not really different than v201112151816 but 1) if we did have to change Indigo builder, could (should?) branch off of v201111250704 to risk least change, but 2) in reality could probably use the new base-builder free version, as long as we left the "pre-req" Eclipse SDK at the 3.7.1 level.

Comment 4 David Williams 2012-01-19 01:41:39 EST

Something seems amiss. There's seems to be an odd "temp" source jar left behind ... there is a content.jar.pack.gz file created (before I ever pack the rest). 

I'm going to try "reverting" to SDK from R-3.7-201106131736 since that would be closer to the previously used  R37_M7 base builder ... but, I wouldn't be surprised if there's some other difference that's not obvious. 

= = = = = 

$ diff out09.txt out19.txt 
1,2d0
< 
< javax.annotation.source_1.0.0.v20101115-0725.jar
543d540
< plugins/temp.javax.annotation.source_1.0.0.v20101115-0725.jar:

Comment 5 David Williams 2012-01-19 03:09:11 EST

(In reply to comment #4)

I was a bit confused in what I was looking at. It was actually the "old" build that had the extra content.jar.pack.gz file and the "temp" source bundle. 

And! .. that build, I20120109153617, appears to have been promoted by Kim Moir, from file ownership bits. So ... Kim ... did you promote an orbit build? Did you use the 'promote.sh" script? As described in 
http://wiki.eclipse.org/Orbit/Builds#How_to_run_the_promote_script

At any rate, I'm not sure what went wrong with "the old" I20120109153617, but, I think we are in better shape than I thought. To be safe, I think I'll revert builder changes, use the base builder to do one more, then switch back and use the Eclipse SDK just to make sure we are comparing apples to apples.

Comment 6 Kim Moir 2012-01-19 11:06:55 EST

regarding comment #5

Yes, I promoted an orbit build a while ago so we could consume the new Ant bundles.  Yes, I used to script.

Comment 7 David Williams 2012-01-19 12:43:52 EST

In my "repeat" apples-to-apples builds, they do produce the same list of bundles, exact same versions and qualifiers. So, that's good. 

I've looked a little at repo metadata. The content.xml file looks very similar, as you'd expect, but a little hard to compare, since the order of some elements change (fairly common when writing XML, normally) so it would likely use some more analysis/comparisons perhaps with xdiff tools or something. 

The artifacts.xml file had differences a little more noticeable, but, as far as I know, could be normal that always happens ... many of the jars were just a little different in size, such as from 1 to 6 bytes. Not sure what would cause that ... but, I personally am not too concerned about that. (Though, as above, could use some more analysis/comparisons). 


If anyone is able and willing, you can check the differences, and report if anything looks off. 

build I20120119083013 was last one with traditional basebuiler R37_M7

build I20120119132721 was the first one with plain Eclipse SDK, using version 3.7.0.

http://download.eclipse.org/tools/orbit/downloads/drops/I20120119083013/

http://download.eclipse.org/tools/orbit/downloads/drops/I20120119132721/

But, think I will assume the best, and promote the desired build, using Eclipse SDK M4, since that's the one that will have substantial changes in the metadata and would deserve the most attention for "correctness".

Comment 8 David Williams 2012-01-19 13:01:16 EST

(In reply to comment #6)
> regarding comment #5
> 
> Yes, I promoted an orbit build a while ago so we could consume the new Ant
> bundles.  Yes, I used to script.

I did enter bug 369124 to track this issue of "extra files" ... might well have been an odd fluke, but, might want to capture output some time and see if anything appears odd.