Community
Participate
Working Groups
The 04/13 build is ok, but not the 4/19 build (some were in between, but have been lost). There is one odd thing that happened 4/16 that might be related. It can be seen in the history of org.eclipse.orbit.releng.builder\build.properties On 2/10/2010 I moved up to latest version of the base builder, R36_M4. But I left the PDE build script directory at version 3.5.0.v20090511-1742. On 4/16 I had to make other changes, and that when I noticed the build script directory was wrong. Looking at it today, I think I never did "release" the configuration version that used R36_M4 ... which meant we have been using R35_RC1 base builder until quite recently, 4/16. If accurate so far, it also means something's wrong with R36_M4 base build, such that it does not produce our Orbit source jars!? As a first step, I'll revert to R35_RC1 and make sure that builds as expected. Then we'll figure out how to use a more recent builder.
Kim, I know in WTP we use the base builder tagged v20100216 (per some other bug report). Do you have any other recommendation to make Orbit "current"? I guess technically we wouldn't _have_ to move up if no known reason to ... but, somehow seems best.
The current version I'm using is v20100416. I recommend moving up to a recent version to take advantage of bug fixes in our components.
Just to document it, from a quick scan of the log from the "failed" build, it appears the source jars were being created. I guess not copied to the right (same) place as before? I wonder if the order of something has changed from the 35 based builds, to the 36 based builds? See /shared/orbit/committers/orbit-I/20100419141755/I20100419141755/antBuilderOutput.log At any rate, after making sure the 35 based build builds as it used to, I'll try Kim's recommended builder.
From doing a local build, even v20100416 had the problem of not producing source jars. I'll investigate a little ... but, will likely need some expert help :) In the mean time, will leave the builder at 35_RC1 for now.
DJ, Andrew, On a local build, I can "watch" this building, the source jars are generated, and they even end up in "updateSite" repository ... but not the zip, and not the "bundles" directory. It appears, just from "watching" it during the build, that the source jars are created and added to the zip, but then in a subsequent step, the zip is created anew, instead of just being updated with results of second step (the normal code jars). Every place I can find in our custom builder code, we "update" the zip, not create ... so, I'm wondering if someplace in the "packager" code (or somewhere) something changed to create the zip, instead of update an existing one? I'm not even sure we need PDE to create the zip for us (I think we do it all in our custom code) but I'm not sure how to turn that off (I tried skipMirroring=true and runPackager=false) but didn't seem to change this behavior. Any ideas? I suppose in the worst case, I could change our "custom" code to use a custom, unique "archiveName" and let PDE do to archiveName what ever it wants. Thanks for any suggestions. But if nothing comes to mind, eventually I'll experiment more with using a different zip file name, and just renaming/merging/cleaning up at end if necessary.
Created attachment 166159 [details] zip of "workdir" from two runs, one including source, one not Here's all the critical files produced by PDE build (minus the plugins, themselves), once with 35 based builder, once with 36 based builder .. the latter one "missing" the source bundles. The source bundles are produced, and end up in p2 repo ("updateSite") but not as part of the zip nor "bundles" directory. I think the critical difference is that in the "no source" case, the constructed pde container feature for the source jars is not included in the gather.bin.parts task of assemble.org.eclipse.pde.build.container.feature.xml. This becomes important later, when we use the <unpackUpdatejars task from the platform's releng tools. The "source" jars get left behind, not copied, since there is no feature to "pull" them to the "unpacked" directory. So ... Andrew, DJ ... what's the best or easiest way to fix this for Orbit builds? I can think of some quick hacks, but also doesn't seem like the build.properties file of assemble.org.eclipse.pde.build.container.feature.xml is quite right (and we produce that build.properties in our source generating code)? Is this a bug? Or a deliberate change in behavior, that just revealed a bug in our releng setup?
BTW, this stuff is probably easier for you to debug, then I, but I created a test branch of org.eclipse.orbit.build.feature.set1 org.eclipse.orbit.releng org.eclipse.orbit.releng.builder org.eclipse.orbit.releng.control That only builds 3 to 7 bundles, leaves a lot of "temp" data in place, so you can compare steps more easily (and more quickly since only a few bundles, if that would help you ... they are branched as 'david_williams-tempTest4 In theory, we could move to use p2.runnable, instead of <unpackUpdatejars, but off hand, I'd guess you'd need complete features for that too?
Hm, generating a different build.properties didn't seem to help (I created it just like the other feature's build.properties). So ... I'll need Andrew or DJ to comment/fix.
I found changes made for bug 284499 back in M2. The generate PDE container features are explicitly excluded from being gathered. I raised bug 309723 I found this based on looking at the attached zip. I tried running org.eclipse.orbit.releng.build/build.xml but it was taking too long to figure out all the required setup properties. There is so much custom stuff here I don't really have any idea of what is going on. Also, the property ${eclipse.pdebuild.scripts} is defined by pde.build and points to the scripts directory of the running pde.build. Similarly, ${eclipse.pdebuild.templates} points to the templates folder. You can use this instead of the more error prone manual "pde.build.scripts"
(In reply to comment #9) > I found changes made for bug 284499 back in M2. > The generate PDE container features are explicitly excluded from being > gathered. I raised bug 309723 > Thanks for the tips ... but the bug number you pasted points to 'this'.
Sorry, its Bug 310674
From doing a small test, I think I can work around the current problem by changing to a p2 runnable task ... instead of the old unpackjars task. I assume we do not really need the PDE container feature in our build or repo? It is there in an old "recommended" build, from ~/downloads/tools/orbit/downloads/drops/R20100114021427 using the 35 based builder. But, from my little local test, seems the repo is ok without it. I wish we could get rid of the "set1.feature" but think we need that to "document" which jars are to be packed into jars, or unpacked into directories.
I've successfully moved up to v20100416 basebuilder. It appears the "p2 runnable" approach works fine. (i.e. it "copies" the source jars, even though not referenced in a feature). Now I wonder ... maybe we can leave out "set1 feature"?
