Bugzilla – Full Text Bug Listing
| Summary: | Compile warnings in org.eclipse.ant.ui are not reported by Eclipse SDK build | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Releng | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | daniel_megert, david_williams, jarthana, Michael_Rennie, sarika.sinha |
| Version: | 4.5 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 460487, 461207, 461651 | ||
| Bug Blocks: | |||
|
Description
Markus Keller
(In reply to Markus Keller from comment #0) > <bad link> > only contains build output for the "Remote Ant Support" folder that gets > compiled into remoteAnt.jar. Correct link: http://download.eclipse.org/eclipse/downloads/drops4/N20150219-2000/compilelogs/plugins/org.eclipse.ant.ui_3.5.600.N20150219-2000/@dot.xml Looks like a more general problem with bundles that also build an extra JAR.
In jdt.core, the following problem is reported in mb060_run-maven-build_output.txt , but it doesn't end up on the results page:
1. WARNING in /opt/public/eclipse/builds/4N/gitCache/eclipse.platform.releng.aggregator/eclipse.jdt.core/org.eclipse.jdt.core/model/org/eclipse/jdt/core/util/ExternalAnnotationUtil.java (at line 470)
switch (mergeStrategy) {
^^^^^^^^^^^^^
The enum constant REPLACE_SIGNATURE needs a corresponding case label in this enum switch on ExternalAnnotationUtil.MergeStrategy
org.eclipse.pde.core is another case where warnings are swallowed. That's another bundle whose build.properties not only builds the bundle, but also an extra JAR.
Thanks Markus. I've fixed the problems but also wondered why the build didn't report the issue, given there's not special directive in the corresponding pom.xml. I've been afraid of this, for the past few years! For some of the "history" of this problem, you can read the following bugs (but, there is no reason for you to ... just FYI, that is has been an ongoing problem). https://bugs.eclipse.org/bugs/buglist.cgi?quicksearch=335229%2C%20402016%2C%20404636%2C%20400753%2C%20405092%2C%20400862%2C%20454807&list_id=11157812 I'll look into this with "top priority", but suspect a true "fix" will require much more sophisticated parsing of the log files than we currently do. I actually think this is a bug in Tycho (though I don't know enough about the CBI build to open a bug). I don't see anything special in /org.eclipse.ant.ui/pom.xml, and AFAIK, it's Tycho's job to look at the build.properties and build the extra JARs. I suspect Tycho just overwrites the previous @dot.xml when it builds the next library. If that's true, then there's not much we can do better in our "gathering" scripts. (In reply to Markus Keller from comment #5) > I actually think this is a bug in Tycho (though I don't know enough about > the CBI build to open a bug). > > I don't see anything special in /org.eclipse.ant.ui/pom.xml, and AFAIK, it's > Tycho's job to look at the build.properties and build the extra JARs. I > suspect Tycho just overwrites the previous @dot.xml when it builds the next > library. If that's true, then there's not much we can do better in our > "gathering" scripts. You might be right. I've opened bug 460487 and we'll see what they think. But did check, and there are 333 @dot.xml files produced in the "build area" and there are 333 @dot.xml files in our "compilerLogs" directory (that's where we copy them to, after the build, and where I thought we *might* be stepping on ourselves ... but, apparently not. Plus, studying the @dot.xml file for the ant.ui case, it's pretty clear "it" thinks that the 'antrunner' jar is already built, and it is working on the 'remoteant' jar. At the same time, we might be accidentally be partially causing Tycho to operate outside it's normal settings, because in our parent pom, we do specify where we want the log file to go, namely <log>${project.build.directory}/@dot.xml</log> I am not sure how most people do it and don't recall where Tycho puts it if we do not specify. But, I *think* we might specify it specifically so we have a consistent place to go find them, to "gather them up". (In reply to David Williams from comment #6) > > <log>${project.build.directory}/@dot.xml</log> > > I am not sure how most people do it and don't recall where Tycho puts it if > we do not specify. But, I *think* we might specify it specifically so we > have a consistent place to go find them, to "gather them up". A. It seems leaving out the <log> argument results in "no log" at all ... that is, all messages just go to "std out" which end up in the big huge log file (as they do even now). B. As far as I can tell, from Git History, we have always used this value for <log> ... first occurrence of it I could find (in master) was 2 and a half years ago, in the commit: ded0b032b4ced953220cc4bfe66dc0daf384bcda Update pom with latest from R4_2_maintenance Thanh Ha <thanh.ha@eclipse.org> on 12/7/12 10:47 AM For the record, I've created and attached to bug a small "stand alone" project, which I think shows the problem easily. Hopefully that will lead to a fix or work-around. http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=dacc5d9cc39c826c51c5a5c6bbe0ba9540d53e8a To "store" this in a public place, I created a "test" path under eclipse.platform.releng, and put the test there. The idea (of that folder) is to have a place to put "tests" which are not really tests of our code, per se, but test some aspect of our build and/or Tycho. CCing Jay for awareness. Jay, not sure if you know off the top of your head, but if the "batch compiler" is called, say, 3 times, to compile classes in one bundle (so that it can put the class files in different places, within that bundle) does the compiler purposely "re-write" the log file? Or does it append to any log files that already exists? If the former ... this *might* turn into a request to have a "append" option for the log ... but, we should wait to see what Tycho team has to say ... perhaps there is a simple solution? I think this can be marked as fixed, once we actually make use of the Tycho fix. That "make use of" part of the work will be tracked in bug 461207. We are still waiting to hear "when and how" the fix will be delivered. Closing as a dup of Tycho bug, since that is/was the fundamental problem. Will track our "reaction" to the Tycho fix in bug bug 461207. *** This bug has been marked as a duplicate of bug 460487 *** |