-
-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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>
# for free
to join this conversation on GitHub.
Already have an account?
# 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.EventTopics
component 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.Header
annotation as follows:@Header(name = org.osgi.framework.Constants.BUNDLE_ACTIVATOR, value = "${@class}")
. We don't specify theBundle-Activator
manifest entry manually in the respective project'sbnd.bnd
file and surprisingly, the abovementioned ERROR log only comprises those projects that have activators specified usingorg.osgi.annotation.bundle.Header
annotation. We also have a few projects whereBundle-Activator
manifest entry has been added manually to their respectivebnd.bnd
files but they are exempted from the aforementioned ERROR log.Please also find the gradle execution log with
--full-stacktrace
enabled here.log.txt
The text was updated successfully, but these errors were encountered: