Community
Participate
Working Groups
Bug 374777 and bug 384531 makes the compiler.version property (which is used by the batch compiler as version) to be in sync with the bundle version. Earlier, the version is manually created (e.g. 0.C58) There is some code that is depending on this format as the compiler version. For instance, TestCase.java and FullSourceWorkspaceTests. These need to be modified so that they work with the new version format.
(In reply to comment #1) > There is some code that is depending on this format as the compiler version. > For instance, TestCase.java and FullSourceWorkspaceTests. Affirmative, I noticed that when trying to run FullSourceWorkspaceBuildTests, see http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg02205.html for more details.
Created attachment 219473 [details] Proposed fix I have fixed the code that was expecting the compiler.version to be in the older format. Tom, could you please review this patch and also see if you are able to run the performance tests and if possible if the ordering works as expected too?
With the patch applied I'm able to run the tests again. I wasn't able to check if RANDOM_ORDER_JDT works since the version I have when self-hosting is "bundle_qualifier", which obviously cannot be parsed as long. In the patch you not only reverted compiler.version to the previous format but bumped the version at the same time (ie from 3.8.0 to 3.9.0). I assume this was intentional.
(In reply to comment #4) > With the patch applied I'm able to run the tests again. I wasn't able to > check if RANDOM_ORDER_JDT works since the version I have when self-hosting > is "bundle_qualifier", which obviously cannot be parsed as long. > > In the patch you not only reverted compiler.version to the previous format > but bumped the version at the same time (ie from 3.8.0 to 3.9.0). I assume > this was intentional. Yes, that is intentional, to keep it in sync with the manifest version, which also got bumped up recently. You could perhaps test the ordering by one of the following ways: 1. Replace the bundle_qualifier with a temporary but real-looking version, let's say "v20120725-181921". 2. Set the qualifier on "bundleVersion" property in the export-ecj.xml, then run the script with Ant (use Java 6 or above) and run the tests without touching the messages.properties in the source folder. This is preferable as it covers the build scenario as well. Thanks for looking into this.
Tom, any chance of looking at this for M1?
(In reply to comment #5) > 1. Replace the bundle_qualifier with a temporary but real-looking version, > let's say "v20120725-181921". Went with this one and the tests are running smoothly. > 2. Set the qualifier on "bundleVersion" property in the export-ecj.xml, then > run the script with Ant (use Java 6 or above) Now I got 3 ecj*.jars in ../ecj-export folder. > and run the tests without > touching the messages.properties in the source folder. How do I tell the tests to use one of the forementioned jars?
(In reply to comment #7) > How do I tell the tests to use one of the forementioned jars? We can't really do that from the dev environment. The 2nd method I mentioned is not accurate, but the closest I can think of to the build scenario. When you have built the ecj JARs, the org.eclipse.jdt.core binaries get updated too(This is what the performance tests use) And then you run the tests and the performance tests are seeing the version you supplied to the export-ecj.xml, then you can say things are working as expected.
(In reply to comment #5) > 2. Set the qualifier on "bundleVersion" property in the export-ecj.xml, then run > the script with Ant (use Java 6 or above) and run the tests without touching the > messages.properties in the source folder. This works as well. Tests are running, the order changes between each suite execution (FullSourceWorkspaceBuildTests in my case).
Thanks for the review, Tom. I have released this for 4.3 M1 here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=cf985f1f2c8ec8245d610a0a35ce5524c11bc220
I have run the tests again while on I20120807-2000 with only tests.* projects open. I assumed that would mean I'm effectively running them against the Running Platform, so no tricks from comment 5 needed. To my surprise, while checking the random ordering I was hit again by: "Cannot extract valid JDT/Core version number from 'compiler.version': bundle_qualifier => no order will be finally used..." Do I need to run the tests from eclipse-Automated-Tests-I20120807-2000.zip or is there another way of verifying the fix?
Please refer to https://bugs.eclipse.org/bugs/show_bug.cgi?id=374777#c7 that indicates some serious problem with the current state of affairs.
I see this in the build logs: [subant] /opt/public/eclipse/eclipse4I/build/supportDir/src/plugins/org.eclipse.jdt.core/customBuildCallbacks.xml:92: The following error occurred while executing this line: [subant] /opt/public/eclipse/eclipse4I/build/supportDir/src/plugins/org.eclipse.jdt.core/scripts/export-ecj.xml:41: Replace: source file /opt/public/eclipse/eclipse4I/build/supportDir/src/plugins/org.eclipse.jdt.core/bin/org/eclipse/jdt/internal/compiler/batch/messages.properties doesn't exist The fix expects the properties file to be present along with other binaries. But don't know why it's not there. Need to check with the build masters for the right location.
I have rolled back part of the fix and released in master. Tom can you please verify the fix once so that I can release into integration for the next I build? http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=f2f5ef46db39434b1ffe1f8131ff03ce750ed39b This rollback means we will not have the order based on the version for performance tests. But I have retained the fix that addresses what is reported in comment #2.
With the reverting commit I'm still able to run the tests, good. I also keep getting the error from comment 11 when trying to use random order, but that (afaik) is expected for the time being.
(In reply to comment #13) > Need to check with the build masters for > the right location. There's plenty to choose from, under plugins/org.eclipse.jdt.core [14:28:20] david_williams@build:/opt/public/eclipse/eclipse4I/build/supportDir/src/plugins/org.eclipse.jdt.core $ find ./ -name "messages.properties" ./batch/org/eclipse/jdt/internal/compiler/batch/messages.properties ./compiler/org/eclipse/jdt/internal/compiler/problem/messages.properties ./compiler/org/eclipse/jdt/internal/compiler/messages.properties ./org.eclipse.jdt.core_3.9.0.v20120808-112019/org/eclipse/jdt/internal/compiler/problem/messages.properties ./org.eclipse.jdt.core_3.9.0.v20120808-112019/org/eclipse/jdt/internal/compiler/batch/messages.properties ./org.eclipse.jdt.core_3.9.0.v20120808-112019/org/eclipse/jdt/internal/compiler/messages.properties ./org.eclipse.jdt.core_3.9.0.v20120808-112019/org/eclipse/jdt/internal/core/util/messages.properties ./org.eclipse.jdt.core_3.9.0.v20120808-112019/org/eclipse/jdt/core/formatter/messages.properties ./org.eclipse.jdt.core_3.9.0.v20120808-112019/org/eclipse/jdt/core/index/messages.properties ./search/org/eclipse/jdt/core/index/messages.properties ./@dot/org/eclipse/jdt/internal/compiler/problem/messages.properties ./@dot/org/eclipse/jdt/internal/compiler/batch/messages.properties ./@dot/org/eclipse/jdt/internal/compiler/messages.properties ./@dot/org/eclipse/jdt/internal/core/util/messages.properties ./@dot/org/eclipse/jdt/core/formatter/messages.properties ./@dot/org/eclipse/jdt/core/index/messages.properties ./formatter/org/eclipse/jdt/core/formatter/messages.properties ./antadapter/org/eclipse/jdt/internal/antadapter/messages.properties ./model/org/eclipse/jdt/internal/core/util/messages.properties But assume you want the first one; that'd be "batch" instead of "bin" in your original path: ./batch/org/eclipse/jdt/internal/compiler/batch/messages.properties It has a section like ### compiler #Format: compiler.name = word1 word2 word3 compiler.name = Eclipse Compiler for Java(TM) #Format: compiler.version = (The placeholder 'bundle_qualifier' will be automatically filled. Do not remove or alter it) compiler.version = bundle_qualifier, 3.9.0 compiler.copyright = Copyright IBM Corp 2000, 2012. All rights reserved. Think that is the one you're after?
(In reply to comment #16) > Think that is the one you're after? Not sure, really. It could be this one: ./org.eclipse.jdt.core_3.9.0.v20120808-112019/org/eclipse/jdt/internal/compiler/batch/messages.properties I want the properties file to get into org.eclipse.jdt.core_3.9.0.v20120808-112019.jar. The one you mentioned looks like a source location.
(In reply to comment #17) > (In reply to comment #16) > > Think that is the one you're after? > > Not sure, really. It could be this one: > > ./org.eclipse.jdt.core_3.9.0.v20120808-112019/org/eclipse/jdt/internal/ > compiler/batch/messages.properties > > I want the properties file to get into > org.eclipse.jdt.core_3.9.0.v20120808-112019.jar. The one you mentioned looks > like a source location. It appears these three all have the same content, using 'diff', ... at least, once the build is finished and I look at the files on build server after everything is done: ./batch/org/eclipse/jdt/internal/compiler/batch/messages.properties ./org.eclipse.jdt.core_3.9.0.v20120808-155455/org/eclipse/jdt/internal/compiler/batch/messages.properties ./@dot/org/eclipse/jdt/internal/compiler/batch/messages.properties I think it depends on when your "customCallback" runs (and sorry, I've lost track). But, think you are right ./batch ... is initial source ./@dot/.... the results after the compiler runs and ./org.eclipse.jdt.core_3.9.0.v20120808-155455/ .... is the "collection" area. I'm not sure which is used for jdt.core jar, vs. ecj.jar vs. the "batch compiler" bundle, but would guess one of the latter two, if your call back runs "late" in the process. Let me know if I can help more directly ... but, IMHO, would be easiest just to guess and it wouldn't take too many runs to get the right one :)
(In reply to comment #18) > I'm not sure which is used for jdt.core jar, vs. ecj.jar vs. the "batch > compiler" bundle, but would guess one of the latter two, if your call back > runs "late" in the process. > > Let me know if I can help more directly ... but, IMHO, would be easiest just > to guess and it wouldn't take too many runs to get the right one :) Ideally, I would like to touch just one file, which would be used both in the jdt.core jar and the ecj.jar. Right now only the latter getting the updated version. This bug is likely to be moved out of M1 and 3.8.1 since it's a bit too late in the game and we only have a minor issue left (considering that the performance tests are not yet running) And yes, soon after M1 we would require couple of test runs. TIA.
Moving out of 4.3 M1. But it can still make it to 3.8.1
Let us first release for 4.3 M2 and after a few weeks of there being all calm and no storm, we will consider for 3.8.2 if needed.
I will try to get it in early during M4.
Fix released it here - http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=a4fee9474be86c01ee26ffe530c8553215f93bfb Will mark it resolved after testing with the new builds.
Confirmed that the ordering is as per the timestamp when requested with the latest build - N20121121-2000. To verify, download the automated test suite, and run one of the tests that extend org.eclipse.jdt.core.tests.junit.extension.TestCase against the same version SDK.
Verified for 4.3 M4 using I20121210-2000 build
*** Bug 384531 has been marked as a duplicate of this bug. ***
