Adds bnd maven plugin to gen osgi manifest for issue #2074#2075
Adds bnd maven plugin to gen osgi manifest for issue #2074#2075scottslewis wants to merge 4 commits intosmallrye:mainfrom
Conversation
|
Also might want to look at/modify Export-Packages and/or the package versioning. |
cescoffier
left a comment
cescoffier
left a comment
There was a problem hiding this comment.
LGTM, just a question (mostly for @jponge actually)
|
@scottslewis also note we use https://www.conventionalcommits.org/en/v1.0.0/ to structure commits. Thanks! |
|
Also: does the produced metadata match what the Java module definition? Our focus is to support Java module definitions, not OSGi which is not part of our stacks. I'm not against having OSGi meta-data in Mutiny, but it has to be correct, and we'd leave it to the OSGi users community to maintain it in the long run. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2075 +/- ##
============================================
+ Coverage 89.10% 89.19% +0.09%
- Complexity 3117 3128 +11
============================================
Files 412 412
Lines 13296 13296
Branches 1687 1687
============================================
+ Hits 11847 11860 +13
+ Misses 820 810 -10
+ Partials 629 626 -3 🚀 New features to boost your workflow:
|
I can't answer this. If Automatic-Module header needs to be removed because it's defined differently elsewhere then I can simply replace it (and will do so if./when requested).
I understand that. I'm a potential consumer of mutiny/commons jars though, and would like them to be able to run on osgi environments without 'wrapping' jars with bundles....as that doesn't work well in the long term. But as part of this request, I am prepared to maintain the manifest/bundle meta-data as needed. RE: your comments here: As a long-time project lead myself I understand what you are saying. However:
As a contributor all I can do is to run the build and test locally from maven pom, and I will do that. I would request that if a CI build break occurs that I can't catch locally, before you remove the OSGi meta-data that you give me or others a chance to fix. Also, once deployed to maven central, there will be consumers that use this (not just me!). Further, if you want osgi environment test code, I can produce it, but I would have to know more about your CI to do so, as it's a bigger deal than writing a new unit test.
Yes. RE: correct...of course. I will of course look at the shape of the bundle produced as output during local testing, and assure that it resolves properly in OSGi 8+/Java 17+ environments. It will, however, still be necessary to verify that the jar continues to properly in non-OSGi environments (e.g. Auto Module Name). |
for OSGI meta-data generation.
|
Please see pr #2078. The requested changes, and a simplification of the bnd-maven-plugin configuration will be easier to maintain and more reusable (for other parts of mutiny as well dependent libs such as commons). |
3 participants
Added bnd maven plugin manifest generation for implementation sub-module.
Starting with the implementation. Once we have this in good shape I'll contribute prs for any other desired jars that are part of mutiny.
Here is the generated manifest.mf for my local test build:
Things to look at/discuss among smallrye team:
This version in pom.xml is almost certainly not right, but don't know how your build works. 999-SNAPSHOT
Bundle-SymbolicName: io.smallrye.reactive.mutiny
Bundle-Developers: cescoffier;email="clement[AT]apache[DOT]org";name="Cl
ement Escoffier",jponge;email="julien[AT]ponge[DOT]org";name="Julien Po
nge"
This was generated from maven metadata...not sure if that's what you want there or not.
This is the groupName.projectName which is the usual for bundle naming in maven land. But maybe you want:
io.smallrye.mutiny instead?
Again, please let me know which if any other jars you would like to be bundles, and I'll add appropriate prs.