--
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/d83ad643-0bde-4029-9934-81dc965a294en%40googlegroups.com.
The subsystem exporters are in a different jar than bndlib. See the exporters project (https://github.com/bndtools/bnd/tree/master/biz.aQute.bnd.exporters) which includes the subsystem exporters.So the documentation is not quite accurate. The bnd command includes the exporters jar and so it can do subsystems exports. But bndlib does not and bndlib is used by gradle and maven plugins. So to use the subsystem exporters there, you will need to configure the plugin, aQute.bnd.exporter.subsystem.SubsystemExporter, as a bnd plugin with a `-plugin` instruction and make sure the exporters jar is accessible via the class loader.
--
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/ced9b2e8-10a0-4b68-90dc-f1f9a92f904an%40googlegroups.com.
--
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/ced9b2e8-10a0-4b68-90dc-f1f9a92f904an%40googlegroups.com.
Subsystems are not widely used.- Ray
--
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/CAK2bqV%2Btc%2B2MnwP0TnKRRxAQaU%3DEHnaT6YQACu%2BGOE%3DVSANQyw%40mail.gmail.com.
You received this message because you are subscribed to a topic in the Google Groups "bndtools-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bndtools-users/Llc9imaJcnI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAMm6HcDA_QgP9OZiC_N0gV-L19b7BMN898bp68C8yGL0uAsvfA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAK2bqVLGuH6R6%2BFDQ4-g8Z0AaWw%2B5tt0zZTFyy6v1RmtCvEt1A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAMm6HcBmwVmcLGaUdH8EKk0YT9QwKk-ZHwdnJFHwnfM5SjT%2BoA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAK2bqVLHeVY%2BE4wcEKCSi_LM4BPXB976X1AKsqaJoRj5wqowQw%40mail.gmail.com.
Outside. The subsystems are expected to be provided by external developers and only contain their own code (plus its dependencies). My understanding was that any requirement would be imported from the parent subsystem if it couldn't be satisfied internally. That is definitely the goal here anyway.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAK2bqVLHeVY%2BE4wcEKCSi_LM4BPXB976X1AKsqaJoRj5wqowQw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAPr%3D90O3HK1UpWmjfgreHfnGGkZa9xzTJ-gv%3Ds7BjGYVdYzq2Q%40mail.gmail.com.
Icertainly thought I documented this when I implemented it, but it doesn’t appear to be currently documented. IIRC you need to configure SCR with the ds.global.extender
flag set to true, then the single SCR will find components everywhere. I believe I was talked out of making true the default value, but I don’t recall why; it’s what I’d expect.
I certainly thought I documented this when I implemented it, but it doesn’t appear to be currently documented. IIRC you need to configure SCR with the ds.global.extenderflag set to true, then the single SCR will find components everywhere. I believe I was talked out of making true the default value, but I don’t recall why; it’s what I’d expect.
--
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/2a3ed3aa-4b17-4715-93e4-70f3d6193006n%40googlegroups.com.
The property is a Felix SCR implementation feature. It is not part of the OSGi Declarative Services specification.
On Oct 14, 2020, at 11:41 AM, Chris Rankin <rank...@gmail.com> wrote:On Wed, 14 Oct 2020 at 18:49, BJ Hargrave <b...@bjhargrave.com> wrote:The property is a Felix SCR implementation feature. It is not part of the OSGi Declarative Services specification.Ah, and the reason why this property is false by default is revealed - because it enables non-standard behaviour!
Thanks, that is good to know.As an aside, I did experiment with obtaining a @Reference to the root's ServiceComponentRuntime service, adding itprogrammatically to the newly installed subsystem and then starting the subsystem up. However, this wasn't enough to
activate component discovery. But now I'm wondering if this approach could have been made to work after all…
Cheers,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/CAK2bqVKMLUXW_Ogc5SFm5DkJBQj1gtTXWQVv1nTsyXOR%2Bn2-NQ%40mail.gmail.com.
How did you add the reference? I can’t imagine a way this could possibly work.
Anyway this is off-topic for bndtools…
--
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/ced9b2e8-10a0-4b68-90dc-f1f9a92f904an%40googlegroups.com.
If you do not have a very strong mandatory binding required obligation to use subsystems I would not touch them with a ten foot pole.My preferred way of delivering code is via the fat jar approach. The set of bundles is then assembled using the resolver that can have a global view of the dependencies. Features, subsystems, etc., are all attempts at a partial delivery model where you share dependencies. This requires assumption about the runtime that are too easily violated or create contradictory constraints.Subsystems is probably then the worst of all worlds. Although Java made a decent attempt, it is clearly not as isolating between bundles as we originally thought. The only proper isolation is the process. Subsystems dig an even deeper hole since the isolation between subsystems is even less than between bundles and it requires a very complex implementation.Although it was the original goal of OSGi to share in runtime, the software industry has been abandoning this model everywhere. If you download a mobile app today, it is often 60Mb because each app carries _all_ its dependencies. There is no Java delivered by Apple because each app must bring its own VM. The only thing you want to share are API to the environment.Although fat jars are not _efficient_, they are remarkably _robust_. Sharing is really hard and flash memory is really cheap.
--
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/bdd99d4f-07b9-4696-8544-3ec7e12edfbfn%40googlegroups.com.
Anyway. I am not sure what you're use case is but hoping that you can throw a messy class path into a container and make it work is probably going to be problematic. If the apps really cannot each have their own framework, then one trick I sometimes use is to deliver the application/subsystem as a single bundle that contains all its dependencies. The bnd -conditionalpackage is very nice for this. I know Netflix uses this trick. As long as you keep the dependencies in private there is no chance of class conflicts.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/41BF86BA-97A7-4B77-8082-C7AE8ADB8202%40gmail.com.