-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for building plugins with using bnd as manifest generator #536
Conversation
Test Results 222 files - 6 222 suites - 6 17m 35s ⏱️ - 8m 54s For more details on these failures and errors, see this check. Results for commit 5b2131a. ± Comparison against base commit 3578bac. This pull request removes 2624 and adds 6 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's very interesting.
Could you add a correspondingly set up project as test case?
I have not yet looked into the details of this change, but have some questions/thoughts:
Will the bnd-lib only be used to generate the Manifest of the project or will it also build the jar and consequently handle the inclusion of resources, which would conflict with the build.properties?
What I personally like about PDE's Manifest first approach is that it gives us the what-you-see-is-what-you-get principle. The drawback is that good metadata are hard to maintain manually and as you said often the metadata can be derived from the code, which actually means that they have to be synchronized manually. On the other hand I personally would like to avoid having another configuration file in the project (ok for bnd-only projects the manifest is probably only generated into the bin-folder or similar).
BND is great in computing good OSGi metadata, but every time I set it up for a project (actually always only using the bnd-maven-plugin/maven-bundle-plugin I end up checking the generated Manifest and since it is not nicely formatted, that's a hard task. Maybe that is because I don't use the bnd-tools and therefore lack tool support for bnd or it is just what I'm used to from PDE.
So what I personally would like to have in a bright future is a mixture of both, that the Manifest is in principle maintained manually and one can for example specify the BSN there or which packages are exported etc. But at the same time the values are enhanced/completed automatically by PDE (internally probably computed by the BND-lib) with data derived from the code, for example uses-constraints and versions for exported packages or Imported-Packages (this way they are always up to date and even easier to use than Require-Bundle). This would IMHO combine the best of both worlds and PDE users would not have to learn BND.
PDE already does that in the simple case of Service-Component headers, so it would actually not be that new, but the suggested cases are probably harder since there are likely many edge-cases to handle when merging manually and derived/computed metadata.
That being said, nothing speaks about this PR to add support for bnd files to fully compute the manifest.
I used a bundle of equinox for testing this feature org.eclipse.equinox.event.zip
It will generate the manifest and any DS-components or metatypes and a like similar to what bnd-process-goal does. PDE is actually never building a jar, so this then works as if one would maintain this files manually in the usual way, but
Actually I think we need to improve PDE to make things more "visible", e.g. BndTools shows exported packages by having a small symbol in the content tree and I think PDE should support some kind of "show the manifest" menu entry when you select the project (currently one needs to go to the target state), or show a virtual item in the navigator (not yet checked how hard this would be).
You can already do this in the So as mentioned above (I have extended the list now) I hope this being the trigger of many more changes / enhancements and any help is appreciated :-) |
aa694e1
to
e23846f
Compare
Currently PDE only supports a "Manifest-First" approach whne building plugins, but actually most of the data in a manifest can be derived from the compiled class files and sources. This adds a very basic aproach to support "Code-First" but still retain the basic concepts of PDE like a target platform and the integration with the existing PDE ecosystem.
e23846f
to
5b2131a
Compare
@HannesWell I now have adjusted the code so it also do resource processing, so the equivalent of "bin.includes" in a
but with the advanced functionality as described here: all content is then copied into the output folder so JDT/PDE should find it without special treatment. |
Great. 👍🏽 Maybe this was ambiguous in my previous comment, but I think it is better to not build the jar for performance reasons.
Fully agree, this also bothers me often that it is cumbersome to get the nicer manifest-editor opened for a bundle at many places.
Actually you are right. One improvement would IMHO be to format the generated manifest in a nicer way. I know some in the BND area argue that the MANIFEST.MF is a build output artifact and therefore should not be nice, but I believe it is important to be able to understand the manifest easily. |
The "Jar" is actually a memory object and "building" it is required to let BND perform certain actions, but there is never really a real jar file created, it is all transparently translated to the resource API of eclipse so you always gets an exploded folder as a result.
This would complicate things a lot for very little gain as the usual case is that resources included in a jar are quite small (usually a few kilobytes maybe megabytes) and we need to rely on native support for hardlinks (eclipse itself only supports softlinks right now), also it might be that people modify the file in the bin folder and getting confused that the source is edited as well and so on.
This should then be done at BND itself, currently there is no "format the manifest" (afaik) but PDE does format some headers as it is written but thats all done as specialized code path.
Every Manifest header is a valid syntax for bnd, so one do not really need to learn anything new, but you can use additional things, e.g instead of listing all exported packages you can use:
BND by default includes a file named
and you are done, but usually bnd requires less things mentioned (e.g. no
Yes Tycho contains already some magic, and you neither need a
it currently uses a bnd workspace to detect what has to be done, but with the new nature this can also be done based on the nature. |
Please note, this PR most likely caused a whole bunch of test fails and crashes in the last IBuild, all seem to be related to bnd dependencies missing at test runtime. |
I have checked here: and only see a few failures related to the URI problem that @HannesWell is currently working on, also the overview page only shows a few failures I can't directly relate to this change: |
This is not a few! |
@iloveeclipse please be more specific then... You claimed this change "caused a whole bunch of test fails and crashes" if I look at the page I see we have success rates > 99 % If I look at PDE it reports the "URI is not hierarchically" here for two failing test: while for example I see three other platform succeed, so it can't be a general dependency problem. The I see a lot of (for example here) " Could not initialize class org.eclipse.jdt.internal.core.JavaModelManager" but not a single pde in the stacktracke nor any mentioning of bnd classes not found (that where used already before in this commit here three weeks ago: 7ec2f75#diff-0bc962190317f532adb62e552a649bf36dc62d3b449e22555a7bc16439efb189 So if there is some evidence that this is caused by missing dependencies I can't see this ... |
don't you see BndResourceChangeListener in all logs? |
I see this, but I don't see any "bnd dependencies missing at test runtime", this is a PDE class, but what I see is that we have a start-order dependency that requires JDT to always start before PDE and the listener now trigger this the other way round. What happens is that PDE is activated and try to call JDT:
but as So I'll try to make the listener more lazy here, but the JDT problem will happen for any plugin that unluckily starts before JDT is started (what might be unusual in a normal IDE setup) and access the |
Please read carefully my first comment.
My assumption regarding missing dependencies was wrong. The rest not. I glad you finally see:
So please provide a patch. |
Yes but based on these assumptions I was not able to relate this to any dependency problem and therefore it is quite confusing if not given a reference why it is assumed to be a dependency problem.
it is not see above, JDT accesses a possibly null value in a static constructor that is not guaranteed to be initialized always and therefore has a start-order-dependency problem.
This PR reveals the problem previously hidden.
I already added a workaround here that should hides the problem again: |
Support for creating new project has now been added with: |
Is this the reason why eclipse has started to open .bnd files with PDE (which then says it has no editor) instead of the editor for bnd-files that comes with the bnd-plugin? I can do "open with" as a (tedious) workaround but it seems impossible to change the default association. |
Then please open a bug at eclipse-platform, PDE can only provide editor associations but the rest is not provided by PDE. If you still think there is a bug at PDE please open a dedicated issue with exact steps to reproduce the problem. |
Currently PDE only supports a "Manifest-First" approach whne building plugins, but actually most of the data in a manifest can be derived from the compiled class files and sources.
This adds a very basic aproach to support "Code-First" but still retain the basic concepts of PDE like a target platform and the integration with the existing PDE ecosystem.
How to try this out
bnd.bnd
in the root of the project (see below for an example)org.eclipse.pde.BndNature
(this should automatically add theYou can now configure the project in the BND file, for example similar to this:
Whats not included but can be added later on based on this:
buildpath
entries like for a Manifest-First-Pluginbnd.bnd
file