OK Igor, I found the origin of the problem...
The problem is a collateral effect caused by a hack that I introduced, some months ago, in order to eliminate the error marks (out of sync) accompanying our maven based bundles when they appeared in the 'Bundles' tab of an Eclipse OSGi Framework Run Configurations of PDE. Besides the fact that those bundles was working as expected that error mark was bothering me.
What I did was to create a profile activated only inside eclipse and I configured the maven-bundle-plugin to generate the manifest into the ${basedir}/META-INF directory instead the default one.
That removed the error mark from PDE but caused an issue when the bundle contains annotated DS components whose xml files are being generated by maven-scr-plugin because it generates the files into target/classes. So, I introduced an ant task to copy those files into a place that pde/equinox don't complains.
I've created a demonstration project here [1]. it has 3 different branches to show the different situations:
- without-ant -> maven-bundle-plugin and maven-scr-plugin generates its files in the default location, but the project has an error mark in Run Configurations.
- issue-when-mbp-generates-into-custom-manifest-location
-> I change the place where the manifest is generated. the issue
occurs because its not possible to locate the generated ds component xml
files.
- with-ant -> I added an ant task to
sync the generated component xmls and that fix the above issue. but as stated
yesterday, it introduced a new error when using Bundle.getEntry()
Everything was working ok until now that I needed to debug a bundle using Bundle.getEntry(). :)
Well, for now I removed my hacks (the out of sync error mark returned of course)...