Bugzilla – Full Text Bug Listing
| Summary: | Update ECJ compiler version property during auto-tagging | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Jay Arthanareeswaran <jarthana> | ||||||
| Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | blocker | ||||||||
| Priority: | P3 | CC: | amj87.iitr, daniel_megert, david_williams, Olivier_Thomann, srikanth_sankaran, stephan.herrmann, tomasz.zarna | ||||||
| Version: | 3.8 | Flags: | tomasz.zarna:
review+
|
||||||
| Target Milestone: | 3.8.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jay Arthanareeswaran
Created attachment 218260 [details]
Proposed patch
I think we can use the custom call back script that get called during the build process to achieve what we want. This patch updates the ecj ant scripts to pick the build label passed from the global scripts and updates the messages.properties file on the fly.
Released in master with one change - changes the version to 3.8.1, so that it is consistent with the MANIFEST. http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=b349d60b6a800b223aee4dca1924d2fdf0926843 Just verified that the ecj -version option produces the desired result with the nightly build N20120709-2000. Only unexpected result is that the comment that mentions the build_qualifier placeholder also gets changed. But since this is part of a binary and we don't expect people to be viewing the file content, it doesn't really matter. The M builds still have the older version format. Can we back-port this to R3_8_maintenance too? (In reply to comment #4) > The M builds still have the older version format. Can we back-port this to > R3_8_maintenance too? Please go ahead - Jay, Thanks. The ecj -version in I20120806-0800 was still showing as 3.8.0.build_qualifier. Fixed this to 3.9.0... in master via commit e4f7008d1c4de6c4879a6c502af07befba61c957 Will have to be verified in today's build There is something wrong with the latest ecj.jar:
D:\home>java -cp ecj-I20120807-2000.jar org.eclipse.jdt.internal.compiler.batch.Main -version
Exception in thread "main"java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.Main
Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.batch.Main
at java.net.URLClassLoader.findClass(URLClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:660)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:346)
at java.lang.ClassLoader.loadClass(ClassLoader.java:626)
Could not find the main class: org.eclipse.jdt.internal.compiler.batch.Main. Program will exit.
The jar is not only missing the forementioned class, it's only 202k comparing to 1,7M for ecj-I20120806-2000.jar. Apparently a bunch classes haven not been included in it.
Not sure if I should reopen this bug or there is another one that caused this.
(In reply to comment #7) > There is something wrong with the latest ecj.jar: ... > Not sure if I should reopen this bug or there is another one that caused > this. Thanks for spotting this Tom. I'll reopen this, so Jay can take a look. (In reply to comment #7) > Not sure if I should reopen this bug or there is another one that caused > this. If anything from the recent changes, it should be the fix made to bug 386318. We have had good builds with this fix till yesterday. But I must say the recent changes have nothing that would have caused so many files to be skipped. Unfortunately I can't find much from the build logs. (In reply to comment #9) > (In reply to comment #7) > > Not sure if I should reopen this bug or there is another one that caused > > this. > > If anything from the recent changes, it should be the fix made to bug > 386318. We have had good builds with this fix till yesterday. But I must say > the recent changes have nothing that would have caused so many files to be > skipped. Unfortunately I can't find much from the build logs. Since it's technically the bug fix 386318 that caused this, I am moving the discussion there. Srikanth, this can remain fixed and we can reopen bug 386318. I quickly checked the latest I build and things looks alright. Ayush, can you please verify? Srikanth, if everything goes alright, I will release this 3.8.1. Ayush is away at Innovate today, Tom, could you verify that the latest bits look alright please ? TIA. Created attachment 219702 [details]
About > Plugins
D:\home>java -cp ecj-I20120808-2000.jar org.eclipse.jdt.internal.compiler.batch.Main -version
Eclipse Compiler for Java(TM) v20120808-155455, 3.9.0, Copyright IBM Corp 2000, 2012. All rights reserved.
The version is now correctly displayed. It says "3.9.0" and "v20120808-155455" which is aligned with o.e.jdt.core version from About > Plugins tab.
Bugs should not be moved to verified state unless the testing is for the target milestone. When there is a mismatch, we should leave the bug in RESOLVED state but clear the white board entry. D:\home>java -cp ecj-M20120809-1200.jar org.eclipse.jdt.internal.compiler.batch.Main -version
Eclipse Compiler for Java(TM) v20120809-105805, 3.8.2, Copyright IBM Corp 2000, 2012. All rights reserved.
The version displayed ("3.8.2" and "v20120809-105805") is aligned with o.e.jdt.core version from About > Installation Details > Plugins tab.
Q: Isn't it too early for "3.8.2"? The version has been bumped in eab065546b280c2a77a97e80202f0b92c06521e0, 12 days ago. Jay?
(In reply to comment #15) > Q: Isn't it too early for "3.8.2"? The version has been bumped in > eab065546b280c2a77a97e80202f0b92c06521e0, 12 days ago. Jay? The bundle version need not align with the product release cycle. The version 3.8.1 was used briefly on master (for 3.9 releases) and we have had few builds in M1 cycle bearing that version number (in the jdt.core bundle, of course). So, obviously we can't use that for 3_8 maintenance and it has to be 3.8.2. Enough said, thx. Marking as verified, see comment 15. (In reply to comment #16) > (In reply to comment #15) > > Q: Isn't it too early for "3.8.2"? The version has been bumped in > > eab065546b280c2a77a97e80202f0b92c06521e0, 12 days ago. Jay? > > The bundle version need not align with the product release cycle. The > version 3.8.1 was used briefly on master (for 3.9 releases) and we have had > few builds in M1 cycle bearing that version number (in the jdt.core bundle, > of course). So, obviously we can't use that for 3_8 maintenance and it has > to be 3.8.2. (In reply to comment #17) > Enough said, thx. Sorry, I can't resist ;-) > The version 3.8.1 was used briefly on master (for 3.9 releases) This is not true. True is, that 3.8.1 was used for Juno (R3.8 and R4.2). |