Community
Participate
Working Groups
"We" need to decide what to do about me literally removing (stop building) the delta pack. See bug 470932 and the original bug 419246. I would like to do this by M6. I am fairly sure PDE still has unit tests that assume the delta pack is "present" when they run. I think there are basically 2 alternatives. 1. remove, or disable the tests. (Or similarly, have them conditional based on presence of "*deltapack.zip" and if not there, then do not run the tests). 2. during the "setup" of PDE's unit tests (that depend on deltapack) then PDE can create their own, in a way similar to how we tell legacy users to do it. Advantages of '1' is that we are truly moving on and simplifying things. The advantage of '2' is that there are still "legacy users" (apparently) that use it, so as a favor that that part of our community we could still create it and run the unit tests -- to make sure we do not break those legacy users. There is another "hidden" advantage of '2'. It is an indirect test that the "configuration feature" exists and roughly works as intended. I happen to know one adapter that still depends on that "configuration feature" (but not the delta pack per se). We do not use the configuration feature ourselves, and we could devise simpler tests for it -- such as only make sure it exists! -- if the PDE team would prefer to simply get rid of the delta pack tests. If the PDE team wants to continue the tests, then I can tell you one way to create it. At the begging of your tests run the equivalent of ./eclipse -application org.eclipse.ant.core.antRunner -f createdeltapack.xml Your starting point for "createdeltapack.xml" could be a copy of a file we have in our repo for "legacy users", at http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/scripts/createdeltapack.xml You would want to tweak it a little and may want to invoke it programmatically via Java, instead of through literally calling eclipse via 'exec'. Let me know your preferences when it would be safe for me to remove it from releng.
FYI, I have removed the delta pack from the build in bug 470932. At the same time, I added some code to the production tests to create the delta pack where the PDE build tests expect them to be. I'd like to "move" that code down to PDE, but not sure yet the easiest way to do that. It depends on if the "test.xml" file in PDE build has the variables/data it needs. I'll run some test builds locally to find out. [If anyone knows of a better way, feel free to say :) ]
Created attachment 261131 [details] Patch to move "creating the delta pack" to the test that needs it I hope you don't mind an old-fashioned patch. :) Not sure a "gerrit/hudson" build would tell you much. I was able to add a "call" method to your "init", and I make sure in the "testing infrastructure" (as ran on "production tests") that the right variables are initialized for you so that the "called" createDeltaPack task ends up creating the 'deltapack' directory in the same place that it used to, and all your 162 tests pass for me locally. We will have to "coordinate" our commits, to be sure they both go into the same build. Actually, you could probably do yours first, but wouldn't be a very good test of the new code if I was still also creating 'deltapack' in the testing infrastructure code.
Created attachment 261132 [details] patch for Releng to apply to testing infrastructure Just to make sure I didn't lose it, this is the patch I (for someone with releng permissions) would apply to the "infrastructure" to compute "currentUpdateSite". Everything else is "removal". Now that I think of it, I need to follow through with similar changes to the standard test.xml (which we do not use in our "production tests".).
I have committed pde.build.test patch via http://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?id=a71e603924005821183873ff18db69d7ad3573f2
I've committed all the corresponding "infrastructure" changes so will mark as fixed. I'll be doing a test build sometime today to confirm I got in all the right pieces, and we'll verify after tests pass next production tests in nightly build.
(In reply to David Williams from comment #5) > I've committed all the corresponding "infrastructure" changes so will mark > as fixed. > > I'll be doing a test build sometime today to confirm I got in all the right > pieces, and we'll verify after tests pass next production tests in nightly > build. FYI my local test build and tests went just fine (tests were on Linux) so would expect all to be well in this evenings's N-build.
David, can you please verify this defect.
Verified it is not longer built, no longer produced in overall tests.xml, and the 22 tests pass that would otherwise fail.
Something related to deltapacks killed test execution on Linux, see bug 492580.
