Bugzilla – Full Text Bug Listing
| Summary: | Update org.eclipse.osgi.services and org.eclipse.osgi.util bundles to cmpn R4.3 release. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | John Ross <jwross> | ||||||
| Component: | Framework | Assignee: | John Ross <jwross> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | tjwatson | ||||||
| Version: | 3.7.1 | ||||||||
| Target Milestone: | 3.7 M4 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
John Ross
Created attachment 206633 [details]
Patch 1
This patch contains the changes from executing the build-cmpn-util.xml ant script. It also contains the script itself, although I'll attach that separately for convenience. The script currently does not update the package imports and exports in the manifests, I did that manually.
In addition to adding support for package version updates, another nice feature might be to automatically detect when new packages have been added and add the corresponding manifest entries. For example, org.osgi.service.component.annotations was added in r4.3.
The wireadmin version was upped to 1.0.1, but I'm not aware of any reason the import can't remain as [1.0,1.1)
Created attachment 206634 [details]
Build Script
The required properties are documented at the top of the script.
I would like to see the Equinox implementations of the OSGi service specifications to include the package they implement. For example, the DS bundle should contain the org.osgi.service.component package and both export and import the package. This will make the bundles more self sufficient and not require a bundle such as org.eclipse.osgi.services to be present. (In reply to comment #3) > I would like to see the Equinox implementations of the OSGi service > specifications to include the package they implement. For example, the DS > bundle should contain the org.osgi.service.component package and both export > and import the package. This will make the bundles more self sufficient and not > require a bundle such as org.eclipse.osgi.services to be present. That is bug 264524. (In reply to comment #1) > The wireadmin version was upped to 1.0.1, but I'm not aware of any reason the > import can't remain as [1.0,1.1) I think it should be updated to be [1.0.1, 1.1). This because we want to be sure that at least version 1.0.1 is available as an export. If we leave the floor at 1.0 then there is a chance our export of 1.0.1 could be substituted for 1.0.0. (In reply to comment #1) > The script currently does not update the package > imports and exports in the manifests, I did that manually. How hard would it be to add this support. We have had cases where the versions were not updated correctly which ultimately caused much confusion. > > In addition to adding support for package version updates, another nice feature > might be to automatically detect when new packages have been added and add the > corresponding manifest entries. For example, > org.osgi.service.component.annotations was added in r4.3. Perhaps for subpackages, but I am reluctant to add any new packages to the services bundle. I would prefer all new APIs simply go in their implementing bundles, if we have any. (In reply to comment #6) > How hard would it be to add this support. We have had cases where the versions > were not updated correctly which ultimately caused much confusion. Not too hard, I think. It's just a question of whether this can be done in ant or if we'll need to use python/jython or, perhaps, a call out to a java class. > Perhaps for subpackages, but I am reluctant to add any new packages to the > services bundle. I would prefer all new APIs simply go in their implementing > bundles, if we have any. Support for including new subpackages already exists. What would need to be added is adding the new packages as version imports/exports to the manifest. (In reply to comment #5) > I think it should be updated to be [1.0.1, 1.1). This because we want to be > sure that at least version 1.0.1 is available as an export. If we leave the > floor at 1.0 then there is a chance our export of 1.0.1 could be substituted > for 1.0.0. Okay, I'll make this update. I just thought the rule was not to explicitly state micro versions on imports unless there was some critical bug fix included. I guess that would be for if you're only importing the package? (In reply to comment #7) > > Okay, I'll make this update. I just thought the rule was not to explicitly > state micro versions on imports unless there was some critical bug fix > included. I guess that would be for if you're only importing the package? As a general rule you should not use a floor that includes the micro version unless you really care. For example, a critical bug fix, or in this case we want to ensure the version we provide is not substituted for a lower version. Script added in commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=4dda7ea764497d82ba155a4904e6ae4240a977f2 Updated the companion code with: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=0d59d5e22c3e3b6a164e39fe26b0246a3b02f8e7 Updated package imports of DS and CM with: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=d578d7448b5581888413617d2aadd5856546a9d6 |