sub-bundles: show warning markers in sub .bnd file#6470
Conversation
|
@pkriens would appreciate some feedback. Tests are passing and the fix does what I expect. But I am not sure if there is a better place for that code, or if there are any side effects I don't see. @laeubi pinging you, since you also recently added something related in https://github.com/bndtools/bnd/pull/6458/files#diff-4467b68f13db09a0b59718cfc70696d470c9a0875dfc0c85b7a3fd5ecf312d2cR91 You see any issues? Or is it maybe even helpful for your maven cases? Just to have more eyes on it. |
laeubi
left a comment
There was a problem hiding this comment.
I think you can even implement this on the Processor level as getPropertiesFile() is defined there. Maybe even at aQute.bnd.osgi.MessageReporter.warning(String, Object...) what seem to have access to a processor already and then can be overridden in custom reporter implementations if desired.
|
I think laeubi is right. The Processor is already associated with the proper file. ProjectBuilder should only have functions that are specific to project building. |
instead of project bnd.bnd This fixes the problem that previously, when you had sub-subbundles, then Warning / Error Markers where always shown at the parent bnd.bnd in the project, instead of in the sub-bundle's .bnd file (where the warning actually belongs to). Now it is showing up correctly in the sub-bundle's .bnd file if it is comming from a sub-bundle, or if it is a normal bundle, it shows at the bnd.bnd as it already was the case. Signed-off-by: Christoph Rueger <[email protected]> move methods to Processor
951e9c9 to
c34cad7
Compare
|
Commit pushed. Now the change is in Processor. Tested locally quickly, result is still as I expect it. Let's see if all tests pass. |
|
lets see how it works ... |

instead of project bnd.bnd
This fixes the problem that previously, when you had sub-subbundles, then Warning / Error Markers where always shown at the parent bnd.bnd in the project, instead of in the sub-bundle's .bnd file (where the warning actually belongs to).
Now it is showing up correctly in the sub-bundle's .bnd file if it is comming from a sub-bundle, or if it is a normal bundle, it shows at the bnd.bnd as it already was the case.
Before:
bnd.bnd(see Resource column), but it actually belongs to the sub-bundlebnd.bndfilebnd.bndAfter:
bnd.bnd)