Summary: | Support Bundle-ActivationPolicy in OSGi R4.1 | ||
---|---|---|---|
Product: | [Eclipse Project] PDE | Reporter: | Thomas Watson <tjwatson> |
Component: | UI | Assignee: | Brian Bauman <baumanbr> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | b.kolb, baumanbr, caniszczyk, curtis.windatt.public, Darin_Swanson, sja.eclipse, wassim.melhem |
Version: | 3.2 | Keywords: | noteworthy |
Target Milestone: | 3.4 M5 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Thomas Watson
2006-11-07 15:09:42 EST
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 :) |