Bugzilla – Full Text Bug Listing
| Summary: | Regression in 0.23.0-SNAPSHOT related to fix for "compiler log output, if more than one jar in a bundle" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | David Williams <david_williams> | ||||
| Component: | Tycho | Assignee: | Martin Schreiber <Martin.SCHREIBER> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | daniel_megert, igor, jarthana, markus.kell.r, Martin.SCHREIBER, t-oberlies | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 460487, 460762 | ||||||
| Bug Blocks: | 460458, 461207 | ||||||
| Attachments: |
|
||||||
|
Description
David Williams
Created attachment 251383 [details]
example project, using 0.23.0-SNAPSHOT, and correct compilerArgs format.
I think this must be fixed. It is my fault, I did specify for both new parameter ('logDirectory' and 'log') a default value, which means, logging is always enabled.
The attached project does fail because the custom compiler argument and the new parameter are taken into account.
With the path https://git.eclipse.org/r/#/c/43366/ I fixed it by removing the default value for the compiler plugin parameter 'log' in order to do not break any old projects which are using -log in the custom compiler arguments.
If there is a project wich does use the new compiler plugin parameter and the custom compiler arguments, the build will fail with an appropriate error message, that only either of them should be used.
(In reply to Martin Schreiber from comment #2) > If there is a project wich does use the new compiler plugin parameter and > the custom compiler arguments, the build will fail with an appropriate error > message, that only either of them should be used. To "fail" I don't think is too bad ... but, less than ideal, since, reminding you of things you probably know better than me, with the way "inheritance" works in Maven and Tycho, it's not always easy to know how "a child" might be doing ... especially if someone has a complicated build, and then perhaps "adds in" someone else's module, who were maybe doing it differently. In other words, to print a warning, and let one (the new one :) have priority would be a better solution. But, in practice, I doubt this would occur all that often, so to fail would probably not impact too many people. Not sure what you mean, though, that "logging is always enabled"? So if I don't specify the old <log> nor the old <-log> nor the new <logDirectory> I will still get logs? Not all that bad ... just surprising. If is helps, remember one is "inside" <compilerArgs> and the other is "outside" of it (so, I'd think would be different "model elemments" ... what little I know). = = = = <configuration> <compilerArgs> <args>${code.ignoredWarnings}</args> <args>-verbose</args> <args>-inlineJSR</args> <args>-enableJavadoc</args> <args>-encoding</args> <args>${project.build.sourceEncoding}</args> <args>-proceedOnError</args> <!-- <args>-log</args> <args>${project.build.directory}/@dot.xml</args> --> </compilerArgs> <log>xml</log> <logDirectory>${project.build.directory}/compilelogs</logDirectory> <showWarnings>true</showWarnings> <excludeResources> <exclude>**/package.html</exclude> </excludeResources> </configuration> (In reply to David Williams from comment #3) > > To "fail" I don't think is too bad ... but, less than ideal, since, > reminding you of things you probably know better than me, with the way > "inheritance" works in Maven and Tycho, it's not always easy to know how "a > child" might be doing ... especially if someone has a complicated build, and > then perhaps "adds in" someone else's module, who were maybe doing it > differently. In other words, to print a warning, and let one (the new one :) > have priority would be a better solution. It was easier to fix it that way and fail the build, but I can also do a fix which lets the new one win and just log a warning. > > Not sure what you mean, though, that "logging is always enabled"? So if I > don't specify the old <log> nor the old <-log> nor the new <logDirectory> I > will still get logs? Not all that bad ... just surprising. Yes you would still get logs in files. Before fixing bug 460487, no logging was persisted into a file if no specific compiler args for that was set. I thought it might be usefull to keep that as it was. > If is helps, remember one is "inside" <compilerArgs> and the other is > "outside" of it (so, I'd think would be different "model elemments" ... what > little I know). > Yes they are differnt model elements, but at the end, they all end up in a map of compiler arguments which will be passed to the compiler and as said it was easier to look into that map and fail the build if there is already an entry for log in there. Martin proposed a change here: https://git.eclipse.org/r/#/c/43366/ |