Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #460458 +++ I did not want to "hijack" the original bug, but now that the fix has been made in Tycho, at some point, we'll have to react to that change. At a minimum, we'll have to remove the <compilerArgs><arg>-log... settings, and put new setting in the "configuration". <configuration> <log>xml</log> <logDirectory>path/to/log/</logDirectory> </configuration> There *might* also have to be ways we "collect" and "display" the results ... but, am hoping that will all work as-is -- but, I think we currently are very tied to "looking for "@dot" files.
I'd have no problem with you hijacking bug 460458, as long as "hijack" means "work on a fix";-) And that's exactly what this bug sounds like...
Just to confirm, if I search for <compilerArgs> among pom.xml files and get zero results, we have nothing to do, right?
(In reply to Jay Arthanareeswaran from comment #2) The change to the -log argument only affects the top-level POM everybody refers to (/eclipse.platform.releng.aggregator/eclipse-platform-parent/pom.xml). Other POMs may have additional <compilerArgs> that specify other arguments. There's nothing to do for those.
(In reply to Markus Keller from comment #1) > I'd have no problem with you hijacking bug 460458, as long as "hijack" means > "work on a fix";-) And that's exactly what this bug sounds like... Yes, could have gone either way, I guess, but was trying to distinguish "work we do" vs. "work others do". So, closed bug 460458 as a dup of Tycho bug. As for "work we do", I will change to use Tycho 0.23.0-SNAPSHOT, run a local test build ... and see if I can figure out easy way to "collect" the new log files for nested jars. Now that I think of it, might be easiest to simply write them to where we want them "in production" (which is something like "${builderOuput}/compilelogs") but, so not "mess up" people doing local builds, may make that directory a variable, so the default will be "the usual" spot under "target" and then we'll override it in our production builds. That would probably be a good change in any case, since there's another bug that our current method of "collecting" them is pretty time consuming (bug 454807).
I've made at least "partial fix" in master, to do a test run, just to make sure the fix works as expected. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=4904585a5cf31af8765a8f6c30f4956d1022526e = = = = FYI, may not be possible to put directly into "compoileLogs", since (currently) we collect into $BUILD_DIR"/compilelogs/plugins/${BUNDLE_ID}_${BUNDLE_VERSION} All those variables we can "get", at the time the logs are generated, EXCEPT for "bundle_version" ... don't believe that's been "decided" yet, at the time of compilation. Is that essential?
(In reply to David Williams from comment #5) > FYI, may not be possible to put directly into "compoileLogs", since > (currently) we collect into > > $BUILD_DIR"/compilelogs/plugins/${BUNDLE_ID}_${BUNDLE_VERSION} > > All those variables we can "get", at the time the logs are generated, EXCEPT > for "bundle_version" ... don't believe that's been "decided" yet, at the > time of compilation. Is that essential? Yes. See e.g. http://download.eclipse.org/eclipse/downloads/drops4/I20150303-0800/compilelogs/plugins/?d , which contains bundles that only differ by version: org.eclipse.jdt.annotation_1.1.100.v20140704-0625 org.eclipse.jdt.annotation_2.0.100.v20140817-1401 And for debugging purposes, it also doesn't hurt to have the @dot.xml somewhere in the "build leftovers". Currently e.g. here: http://build.eclipse.org/eclipse/builds/4I/gitCache/eclipse.platform.releng.aggregator/eclipse.jdt.core/org.eclipse.jdt.core/target/ According to bug 460487 comment #41, the log files will be named like this: > path/to/log/@dot.xml > path/to/log/lib_mylibrary.jar.xml > path/to/log/lib_myOtherLibrary.jar.xml For bug 454807, the gathering script needs to include *.jar.xml files. Or maybe a safer choice would be to generate the files into ${project.build.directory}/compilelogs/ , so that the gathering script doesn't have to guess and find log files everywhere but just takes them from the per-bundle compilelogs folder.
(In reply to Markus Keller from comment #6) > ... Or > maybe a safer choice would be to generate the files into > ${project.build.directory}/compilelogs/ , so that the gathering script > doesn't have to guess and find log files everywhere but just takes them from > the per-bundle compilelogs folder. excellent suggestion. Thanks. My first attempt appears to result in lots of compile errors in SWT tests and tools (bug 461427) ... I'm going to try again, in case someone was just "in the middle" of making changes ... but, hope those are not compile errors we've been missing all along! (And, could be a bug with Tycho snapshot, for all I know).
(In reply to David Williams from comment #7) > > My first attempt appears to result in lots of compile errors in SWT tests > and tools (bug 461427) ... I'm going to try again, in case someone was just > "in the middle" of making changes ... but, hope those are not compile errors > we've been missing all along! (And, could be a bug with Tycho snapshot, for > all I know). Saw the same issue a second time, so will revert the change to 0.23.0-SNAPSHOT until there is time to study it more. Also noticed another error (more likely to be valid) that said "Failed to execute goal org.eclipse.tycho:tycho-p2-publisher-plugin:0.23.0-SNAPSHOT:publish-products (default-publish-products) on project equinox-sdk: The product file equinox-sdk.product does not contain the mandatory attribute 'version'. For the record, there were 320 @dot.xml files (not 333 that we expect, but ... some bundles were "skipped", once errors occurred) and there were 160 *target/*jar.xml files ... somewhat indicating the new logging is working.
(In reply to David Williams from comment #8) > (In reply to David Williams from comment #7) > > > > > My first attempt appears to result in lots of compile errors in SWT tests > > and tools (bug 461427) ... I'm going to try again, in case someone was just > > "in the middle" of making changes ... but, hope those are not compile errors > > we've been missing all along! (And, could be a bug with Tycho snapshot, for > > all I know). > > Saw the same issue a second time, so will revert the change to > 0.23.0-SNAPSHOT until there is time to study it more. > To cross-reference, Pascal tracked the SWT issues to a change made in Tycho, see bug 453446, which was related to SWT bug 361901.
Tycho has fixed 460487 and we are close enough to using Tycho 0.23.0-SNAPSHOT I'll close this as "fixed". Does seem to be working well (better?) in the X-builds. (And, from local testing, works even with "old" method of collecting logs!?) I will try with "new" method of collecting logs before M6's first stabilization build. [But, kind of cool, if both still work, since then easy to get "timing data" to verify bug 454807 is improved.
