Community
Participate
Working Groups
See http://bundles.osgi.org/Design/LazyStart for the proposed changes that will go into the upcoming OSGi R4.1 - Why should PDE-UI care? This proposal adds a new header "Bundle-ActivationPolicy" ... The Bundle-ActivationPolicy header is introduced to allow a bundle to specify a bundle start policy. Bundle-ActivationPolicy ::= policy-type (';' directive)* policy-type ::= token The only defined policy type is lazy. The lazy activation policy has the following defined directives: include – A comma-separated list of package names that require the lazy activation policy. Note that the use of a comma in the value requires it to be enclosed in double quotes. If not specified then all packages require the lazy activation policy. exclude – A comma-separated list of package names that do not use the lazy activation policy. Note that the use of a comma in the value requires it to be enclosed in double quotes. If not specified then all packages require the lazy activation policy. For example: Bundle-ActivationPolicy: lazy; include:="org.lazy.stuff" Bundle-ActivationPolicy: lazy; exclude:="org.notlazy.stuff" The Bundle-ActivationPolicy header should be used instead of the Eclipse-LazyStart when a bundle is targeting a 3.3 or higher version of Eclipse. I suggest you keep the UI the same with the "Activate this plug-in when one of its classes is loaded" checkbox. If it is checked/uncheck you simply add/remove the following header Bundle-ActivationPolicy: lazy Developers that need to use the more advanced include/exclude directives will be required to edit the header by hand. The code in Equinox has been released today to support this new header at runtime. See bug 135885.
As per Wassim's wishes
Want to split some of this work Brian? I can hack out the quickfixes, maybe you work on the other things?
so areas that will be affected are: 1. New plug-in project wizard: add 3.3 target and make sure the headers generated for Eclipse plug-ins are compliant with specified target version: >= 3.3: Bundle-ActivationPolicy 3.2: Eclipse-LazyStart <= 3.1: Eclipse-AutoStart 2. The checkbox in the General Information section of the plug-in editor should support the new header 3. Manifest.mf content assist 4. Manifest.mf quick fixes 5. Manifest.mf syntax highlight. Bundle-ActivationPolicy is a reserved OSGi header, so it should be in bold red. That's all I could think of at the moment.
*** Bug 177688 has been marked as a duplicate of this bug. ***
mine, since Wassim likes to steal bugs from me and assign it to Brian.
The moment you remove Eclipse-LazyStart, the bundle will stop running against Eclipse <= 3.2. That's a bit harsh result, just to upgrade to the new header. One option would be to keep both headers. In any event, I think it is late to start pushing for it one way or another at this time in the 3.3 cycle.
At a minimum, can we at least get the old headers flagged as deprecated. Having that for 3.3 would be super. I'm not even asking for a preference or anything. ;-)
If developing plugins/bundles that are designed to run on multiple versions of Eclipse, then you want to support having all of them. I'd say supporting: 3.1: Eclipse-AutoStart, Eclipse-LazyStart, Bundle-ActivationPolicy: lazy 3.2: Eclipse-LazyStart, Bundle-ActivationPolicy: lazy 3.3: Bundle-ActivationPolicy: lazy I don't think enforcing only one of them based on the target is a good idea. Further, I think that if there's a Bundle-ActivationPolicy: lazy and Eclipse-Lazy/AutoStart, that you don't want to report a warning.
Hey Tom, is it time for this one?
yes, we should take the same approach used when the Eclipse-AutoStart header was deprecated. I think this should be done in 3.4.
functionality added in HEAD. > Further, I think that if there's a Bundle-ActivationPolicy: lazy and > Eclipse-Lazy/AutoStart, that you don't want to report a warning. Though I don't think many users have multiple activation headers, I decided to implement this anyways. If the user has a valid activation header based on the target platform, we won't mark any other activation headers as deprecated or unsupported. One note, when migrating Eclipse-AutoStart, if the target platform is 3.2,3.3 we will continue to use Eclipse-LazyStart since that was the header we used in 3.3. If the user already has the Bundle-LocalizationHeader and their target platform is 3.3, we do not flag a warning as this is supported. The quick fix also carries over any "excludes" attributes to the "exclude" directive.
How about a noteworthy for this one :)
