Community
Participate
Working Groups
After the generation of the component definition XML file, there are two warnings shown in the project. IMHO it is bad practice that code generation creates warnings in a project. At least if it is not intended to show a user that he has to modify something. a) build.properties Honestly I'm not sure if the warning is correct or if the modification of the build.properties should be modified. It definitely forces a user to modify the build.properties manually to get rid of the warning. I would suggest to modify the generation to create only an entry for the OSGI-INF folder in the build properties instead of the component definition XML. So instead of something like this: bin.includes = META-INF/,\ .,\ OSGI-INF/component.xml it should look like this: bin.includes = META-INF/,\ .,\ OSGI-INF/ Doing this would avoid the warning and automatically add all component definition XML files if there are multiple service implementations in that bundle. b) MANIFEST.MF I still don't understand why in Eclipse the DS do not work without that header. Probably a startup order issue. Nevertheless the OSGi wiki says "if another service is registering the components (such as Declarative Services or Blueprint) then the lazy policy may be beneficial". So it doesn't seem to hurt. Just as information, a DS bundle created with Bndtools does not specify the Bundle-ActivationPolicy. Coming to the point, if a warning is raised that the Bundle-ActivationPolicy needs to be set to make a bundle that provides a DS work correctly with Equinox, we should add that header automatically.
New Gerrit change created: https://git.eclipse.org/r/70180
(In reply to Dirk Fauth from comment #0) > b) MANIFEST.MF > > I still don't understand why in Eclipse the DS do not work without that > header. Probably a startup order issue. Equinox provides services only for plug-ins which are in active status. See http://www.vogella.com/tutorials/OSGiServices/article.html#osgiservice_active By setting the flag the OSGi service registry activates the plug-in once someone requests the service from the service registry as this registry load the class. +1 for always setting the flag, this will ensure it works under Equinox and AFAIK it does not hurt for other OSGi runtimes.
I think both of these changes should be considered in a larger context -- please don't focus on the "example" scenario where you generate a bundle with some initial DS files. There is a lot of logic in this plugin to ensure as little intrusion/impact on existing code as possible; the "new bundle" use-case is just one of many. As far as the build.properties warning, this is not in scope of this plugin -- the warning comes from another place, and frankly I question the warning itself. I don't think we should automatically add a wildcard entry instead of individual files. This is quite presumptuous -- what if the user already has xml files in that directory that they don't intend to include? We'd now include them automatically without any warning. Similarly for Bundle-ActivationPolicy: lazy -- I don't believe this should be automatically added. With the "it doesn't hurt" argument, why not just add it to all bundles all the time then? It's definitely not required in all cases; it's up to the user to consider whether it's applicable in their scenario (e.g., they may be managing bundle activation somewhere else/using some other approach). We can do this in the templates when generating the example code, but -1 for both changes in the general case.
(In reply to Peter Nehrer from comment #3) > Similarly for Bundle-ActivationPolicy: lazy -- I don't believe this should > be automatically added. With the "it doesn't hurt" argument, why not just > add it to all bundles all the time then? Felix does activate all bundles, IIRC Equinox does not activate all plug-ins because Tom Watson had performance concerns with regards to bad implemented Activators. > It's definitely not required in all > cases; it's up to the user to consider whether it's applicable in their > scenario (e.g., they may be managing bundle activation somewhere else/using > some other approach). It is required as Equinox only provides services for activated plug-ins. And without this flag the user has be manually activate the plug-in via the configuration. The missing flag has been a source of pain, in the past at least for me and my customers. +1 for this part of the change, unless I missed one of your arguments Peter. It is getting really late here and I'm getting tired. > We can do this in the templates when generating the example code, but -1 for > both changes in the general case.
Adding Brian, IIRC he was also once hit by an missing lazy activation flag.
All I'm saying is that it should be the user's choice and we shouldn't force it. OSGi doesn't require all bundles to be activated automatically, nor does it require them the be lazy-activated. It's not just Equinox that will only consider DS descriptors in active (or lazy-activated) bundles -- that's in the DS spec, so all SCR implementations are required to behave this way. Which bundles to activate may be a deployment-time choice. Maybe you have an installation manager that lets you (the user/operator) choose which bundles should be activate and there's some business logic associated with that (e.g., resource management, etc). In that case you wouldn't want all DS bundles to automatically start, only some of them (i.e., the ones you choose).
(In reply to Peter Nehrer from comment #6) > All I'm saying is that it should be the user's choice and we shouldn't force > it. As it is such a big discussion it should be configurable via preferences. Users of Equinox need this setting to be done. Otherwise the DS will not work. And it is frustrating to do such a manual task after the automation is done. So you could add a preference that allows an Equinox user to enable the automatic setting of the Bundle-ActivationPolicy flag. Regarding the build.properties, I don't know about the warning in detail. If the warning itself is wrong, it should be fixed. Then please open a ticket for this against PDE or wherever the warning is coming from. You are looking at the tooling from the point of an experienced OSGi developer. I'm trying to see the perspective of a developer who doesn't have that detailed knowledge (for which such a tooling is mostly intended)
(In reply to Dirk Fauth from comment #7) > (In reply to Peter Nehrer from comment #6) > > All I'm saying is that it should be the user's choice and we shouldn't force > > it. > > As it is such a big discussion it should be configurable via preferences. > Users of Equinox need this setting to be done. Otherwise the DS will not > work. And it is frustrating to do such a manual task after the automation is > done. > So you could add a preference that allows an Equinox user to enable the > automatic setting of the Bundle-ActivationPolicy flag. +1 for this preference with default "one". None Equinox users or expert which want to control that behavior can turn it of. I retarget the bug for this.
BTW is it possible to disable the warning regarding the activation policy that was added with neon? I think that warning will bother experts in the future otherwise. And what should we do about the build.properties warning? Is the warning incorrect? Can this warning be turned off?
(In reply to Dirk Fauth from comment #9) > BTW is it possible to disable the warning regarding the activation policy > that was added with neon? I think that warning will bother experts in the > future otherwise. I think the warning here is fine from the perspective of Equinox. I would not add a preference to turn it of, that feels like overdesign. > And what should we do about the build.properties warning? Is the warning > incorrect? Can this warning be turned off? Lets discuss via a new bug report.
(In reply to Lars Vogel from comment #10) > I think the warning here is fine from the perspective of Equinox. I would > not add a preference to turn it of, that feels like overdesign. If I understand Peter correctly he is also looking at it from a non equinox perspective
FWIW, the "Bundle-ActivationPolicy: lazy" (let's call it BAPL) setting is only ever required for bundles that are used in Eclipse, i.e. in the SDK and in RCP applications. This setting is not required by people using Equinox as a plain OSGi Framework. So let's stop calling this an Equinox issue and be clear that it's an Eclipse issue. The root of the problem is that Eclipse goes out of its way to start as few bundles as possible. Whereas DS is *required* to ignore bundles that are not started (this is in the specification, as Peter Nehrer points out). The conflict here should be clear! Therefore BAPL is needed in Eclipse so that p2's SimpleConfigurator starts the bundle. It is not needed in plain OSGi because we just start all the bundles.
(In reply to Neil Bartlett from comment #12) > > This setting is not required by people using Equinox as a plain OSGi > Framework. So let's stop calling this an Equinox issue and be clear that > it's an Eclipse issue. Not sure I understand. Are you saying that if I use Equinox as a plain OSGi framework, that is also activates all plug-ins?
Thanks for the clarification Neil. IIUC BAPL is useless in plain OSGi because all bundles are started automatically. Is that correct? I recently set up a plain OSGi application with equinox that used the updateconfigurator. And there the bundles where not automatically started. Probably my fault because of a misconfiguration in the config.ini. I need to check this. But for Eclipse RCP it is important which still means making it configurable sounds like a good idea.
To both Lars' and Dirk's last question: not exactly. OSGi itself NEVER STARTS ANY BUNDLES automatically. This is true for Equinox as well as Felix and all the others. Because OSGi developers know this fact, we usually use launchers that automatically start all bundles. (Note that the Equinox JAR does also contain a launcher application, but that is not part of the OSGi Framework implementation and its behaviour is not described by any OSGi spec.) Eclipse also has a launcher, because ultimately it's just an OSGi application too. The Eclipse launcher installs and starts the bundles listed in config.ini. One of those is normally simpleconfigurator, which installs the rest of the bundles under 'plugins', and then starts the bundles having BAPL in their manifests.
From what I have found here [1] the update configurator only automatically installs bundles, it does not activate them. Unlike Felix there is only a setting for auto start on bundle level in config.ini @Neil Could you point me to the documentation where it is explained how I can tell equinox to automatically start all bundles in a specific directory (like the update configurator) ? [1] http://www.eclipse.org/equinox/documents/quickstart-framework.php
Mid-air collision Thanks again Neil. So that means the equinox/eclipse launcher is the "bad guy". And basically BAPL is used for auto activation in that context. Correct? So using the equinox launcher and the update configurator makes the usage of BAPL necessary to avoid auto start configuration in the config.ini. Is that statement correct?
(In reply to Dirk Fauth from comment #16) > From what I have found here [1] the update configurator only automatically > installs bundles, it does not activate them. Well this might have changed, but some time ago I put a breakpoint on my BundleActivator and looked at the call stack to figure out who was starting my bundle. It was simpleconfigurator. Again this might have changed, it was probably the Eclipse Indigo time frame. Whichever bundle does this, the contract is clear. If your bundle has BAPL then it will be started with 'Bundle.start(START_ACTIVATION_POLICY)'. See the javadoc for Bundle.START_ACTIVATION_POLICY for more details. If it doesn't have BAPL then it will not be started at all, therefore will remain in RESOLVED state and will be ignored by DS. > > Unlike Felix there is only a setting for auto start on bundle level in > config.ini > > @Neil > Could you point me to the documentation where it is explained how I can tell > equinox to automatically start all bundles in a specific directory (like the > update configurator) ? No because, as per my previous comment, this setting does not exist. > > > [1] http://www.eclipse.org/equinox/documents/quickstart-framework.php
(In reply to Dirk Fauth from comment #17) > Mid-air collision > > Thanks again Neil. So that means the equinox/eclipse launcher is the "bad > guy". And basically BAPL is used for auto activation in that context. > Correct? > > So using the equinox launcher and the update configurator makes the usage of > BAPL necessary to avoid auto start configuration in the config.ini. > > Is that statement correct? Basically yes, though I'm not calling anybody a "bad guy". This all stems from a decision made in the early days of Eclipse 3.0 to avoid starting bundles. In retrospect it was not the best decision but it was justifiable at the time.
> Basically yes, though I'm not calling anybody a "bad guy". This all stems > from a decision made in the early days of Eclipse 3.0 to avoid starting > bundles. In retrospect it was not the best decision but it was justifiable > at the time. Ok, exchange "bad guy" with responsible. But still for Eclipse developers BAPL is necessary (something to keep in mind for Eclipse RCP support in bndtools). And it means that BAPL has no impact in plain OSGi when all bundles are automatically activated (just for clarification if I understand correctly). Therefore Eclipse developers need it. For plain OSGi it is almost useless. Configure whether BAPL is automatically added or not sounds like a good idea.
(In reply to Dirk Fauth from comment #7) > As it is such a big discussion it should be configurable via preferences. Yes, a preference is better than forcing it on everyone. Thanks.
Not sure when I will be able to update my patch for the preference setting. For the build.properties warning I created Bug 491666.
(In reply to Peter Nehrer from comment #21) > (In reply to Dirk Fauth from comment #7) > > As it is such a big discussion it should be configurable via preferences. > > Yes, a preference is better than forcing it on everyone. Thanks. Dirk, can you create a new bug for the configuration of this warning?
(In reply to Lars Vogel from comment #23) > (In reply to Peter Nehrer from comment #21) > > (In reply to Dirk Fauth from comment #7) > > > As it is such a big discussion it should be configurable via preferences. > > > > Yes, a preference is better than forcing it on everyone. Thanks. > > Dirk, can you create a new bug for the configuration of this warning? Already done this morning Bug 491651
Gerrit change https://git.eclipse.org/r/70180 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=8b0d7507dc99a7eb340865699486c71b5a31e7f7
Thanks Dirk for the contribution and to all for the great discussion.
Dirk, can you verify this defect?
(In reply to Vikas Chandra from comment #27) > Dirk, can you verify this defect? You want me to verify my own patch? OK I created the ticket and therefore typically I should verify it. But if I am the one who also contributes, am I then still the one who needs to verify? I think that is an interesting question for the contribution process. ;) Nevertheless, I am working with this for a few days now and it works as expected. Therefore VERIFIED
Thanks Dirk :-)
