Gradle Export Task fails #5257
Comments
|
I am seeing this as well, make a quick fix |
pkriens
added a commit
to pkriens/bnd
that referenced
this issue
May 23, 2022
There was a recent change bndtools@dd2f0c5 that took a shortcut to calculate the embedded packages unconditionally. It used the bundle class path analysis to analyze all the jars in the executable. However, this significantly slows down Eclipse but worse, it then tries to reinterpret the annotation headers. In my case, I got 3 types on the Bundle-Activator. The analysis should only be done when it is needed and I'd suggest to do it either in a separate Builder or try to analyze the manifests for speedup. This patch just makes the analysis conditional but that is a temporary fix to make it compatible with the the previous code. This needs to be cherry picked for 6.3.0 since it is a very serious regression. Fixes bndtools#5257 Signed-off-by: Peter Kriens <Peter.Kriens@aqute.biz>
bjhargrave
pushed a commit
to bjhargrave/bnd
that referenced
this issue
May 23, 2022
There was a recent change bndtools@dd2f0c5 that took a shortcut to calculate the embedded packages unconditionally. It used the bundle class path analysis to analyze all the jars in the executable. However, this significantly slows down Eclipse but worse, it then tries to reinterpret the annotation headers. In my case, I got 3 types on the Bundle-Activator. The analysis should only be done when it is needed and I'd suggest to do it either in a separate Builder or try to analyze the manifests for speedup. This patch just makes the analysis conditional but that is a temporary fix to make it compatible with the the previous code. This needs to be cherry picked for 6.3.0 since it is a very serious regression. Fixes bndtools#5257 Signed-off-by: Peter Kriens <Peter.Kriens@aqute.biz> Signed-off-by: BJ Hargrave <bj@hargrave.dev>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, with the latest version (
6.4.0-SNAPSHOT), the bndruns cannot be exported anymore.It reports several warnings regarding the component property types denoting that the annotation should be in the project build path whereas all our custom property types are in a single base API project which is added to the builpath of all the workspace projects. It also reports the similar problems for
org.osgi.service.event.propertytypes.EventTopicscomponent property type which is also in the aforementioned base API and by default added to the buildpath of all projects.After reporting the above-mentioned warnings, it fails with the following ERROR message:
Surprisingly, the export task thinks that all these different bundle activators are inside a single bundle whereas these activators are in separate bundles. Since a bundle cannot have more than one activator, it is also prevented by bndtools by default during build phase as a precautionary step. But, somehow during export the gradle task considers them to be part of a single bundle and that's why the build fails.
For your reference, all our activators in the workspace use
org.osgi.annotation.bundle.Headerannotation as follows:@Header(name = org.osgi.framework.Constants.BUNDLE_ACTIVATOR, value = "${@class}"). We don't specify theBundle-Activatormanifest entry manually in the respective project'sbnd.bndfile and surprisingly, the abovementioned ERROR log only comprises those projects that have activators specified usingorg.osgi.annotation.bundle.Headerannotation. We also have a few projects whereBundle-Activatormanifest entry has been added manually to their respectivebnd.bndfiles but they are exempted from the aforementioned ERROR log.Please also find the gradle execution log with
--full-stacktraceenabled here.log.txt
The text was updated successfully, but these errors were encountered: