--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/868d3d0a-3161-47b4-825d-81cba6968cd9n%40googlegroups.com.
It was treated as a Release 3 bundle. But it is basically dead since it exports no packages and has no Bundle-Activator.
--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/deceaac4-698a-4318-b5a3-b1b6c7849a34n%40googlegroups.com.
Normally wrapping is done once and placed in a repository. I don't think you want to wrap dependencies in every build. This is why we do not have maven and gradle tasks for wrapping.
However, the wrap command has reminded me that my jars will need optional imports as well as version=0 on all their exports
--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/92824cf2-0b44-4df1-a6a0-c58e4de314dfn%40googlegroups.com.
Wrapping is a mysterious art. There is no way you can reliably make this work without human introspection. If you can, it is useless since you incorporate all problems of the flat class path. I.e. you buy big money for OSGi but then don't use its primary features that give lots of benefits.
--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/38381063-02f1-4ff6-a4bf-b92b6e1d6128n%40googlegroups.com.
The problem is that you need to properly _analyze_ that set to make work reliable. You can quickly get to 98% percent working ok but the remaining 1% is going to cost you sooooo much pain ... Mainly because you're users are going to have no experience with the problems.The beauty of Java is that it has a very decent formal specification and that the byte code allows you to an (almost) full transitive analysis.
On 24 Oct 2020, at 17:14, Chris Rankin <rank...@gmail.com> wrote:On Saturday, 24 October 2020 at 14:11:43 UTC+1 pkriens wrote:The problem is that you need to properly _analyze_ that set to make work reliable. You can quickly get to 98% percent working ok but the remaining 1% is going to cost you sooooo much pain ... Mainly because you're users are going to have no experience with the problems.The beauty of Java is that it has a very decent formal specification and that the byte code allows you to an (almost) full transitive analysis.I take your point about the potential problems with the "user experience"... :-).
Bnd has a fine "Resolve" Gradle task which should be able to validate that the user's set of N bundles all wire together correctly. I think this should be able to provide the kind of "full transitive analysis" of which you speak.
In fact, considering that Guava clearly resolves already without com.google.error-prone etc being bundles in the first place, it's possible we don't need to wrap all non-bundles automatically either. We could probably restrict that to just those dependencies which are explicitly added to some kind of "bundleImplementation" Gradle configuration. And then we'd tell users that they would only need to use the "bundleImplementation" when their "resolve check" has failed because something isn't a bundle that actually needs to be.
All of which would be more for Mr Gradle Bunny to implement, of course. Oh well...Thanks,Chris
--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/1ceed6f1-1f0c-439d-8ae0-cb50d4d9fd60n%40googlegroups.com.
Yes. But only when the metadata is correct.
I think you should forget OSGi and just use the underlying technology to analyze an app class path the user uses. This analysis can then tel the user that he's got X dependencies that are not found on the class path and if it is ok that we run that time bomb. That way it is her fault if things blow up.
--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/035222fd-9962-4f96-83f8-42fa338ae759n%40googlegroups.com.
Unfortunately, broken OSGi metadata seems to be extremely common (perhaps even the rule rather than the exception!). Things like packages that should be optional marked as mandatory, missing requirement declarations for ServiceLoader, split packages that make bundles impossible to resolve, etc. We have a couple of ideas for new features in bnd that can fix metadata in 3rd party dependencies rather than forcing you to generate it from scratch. A matter of time and resources.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/1fbfa468-af17-4ebb-fc88-e5cb15231460%40data-in-motion.biz.
I currently work for a customer, who already uses OSGi, as RCP
and in a servlet container at backend side. They have really a lot
of bundles and most of them are not really good in shape. Beside
that no one really cares about their dependencies. This project is
a good bad example for a modular monolith. Many developers in the
teams dont care about OSGi at all. Its just there, they hate it,
they don't really take profit of it. The whole team develops like
in ordinary Java. And providing imports and exports is just a
work, they don't really like.
I dont think, that this is only a result of just bad habbits. It really goes back to the company structure and culture. Non technical departments tend to spend money for their features not in technical improvements that are not obvious for customers. They often don't care about efficient development processes, well structured software architecture. This is something they expect from the development department, something that should already be there. But if it isn't, the technical dept, stay dept until the end of days until someone realizes that developers and business together create the product.
But this is not dedicated to OSGi alone. You can substitute these situation with any technology and end up with the same root cause ;-)
So, OSGi is overhead for many developers at this customer. And with Peters words: They have an ugly baby. But because it is already OSGi, its much easier to beautify it. But how to convince the developers, that they are on the right track. All they have to do is learn a little bit and try to understand whats happening inside OSGi. These discussions are in the end the hardest part.
Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAMm6HcASzxCuA3CefNmnOmJZLVmAH%2BpnygpEn0hjMoCN%2B7%3DSDQ%40mail.gmail.com.
-- Mark Hoffmann M.A. Dipl.-Betriebswirt (FH) Geschäftsführer Tel: +49 3641 384 910 0 Mobil: +49 175 701 2201 E-Mail: m.hof...@data-in-motion.biz Web: www.datainmotion.de Data In Motion Consulting GmbH Kahlaische Straße 4 07745 Jena Geschäftsführer Mark Hoffmann Jürgen Albert Jena HRB 513025 Steuernummer 162/107/05779 USt-Id DE310002614
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/69909b10-5d7c-4a0f-7428-60118fd42985%40data-in-motion.biz.