[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] .qualifier for export package?
- From: Jeff McAffer <jeff@xxxxxxxxx>
- Date: Wed, 03 Sep 2008 11:28:55 +0100
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 184.108.40.206 (Windows/20080708)
FYI - plans for package version support in API tooling have been reduced.
Currently, there is nothing on the draft plan due to resources available
to do the work, and the fact that SDK plug-in developers generally use
components at the plug-in granularity vs. package granularity. I'm not
sure there is a compelling story to have SDK bundles change to using
Resource point taken I feel compelled to point out that PDE is
plugin/bundle tooling not SDK tooling. The success of Equinox and OSGi
is largely predicated on developers being able to develop bundles
whether they be for the SDK, RCP or server side applications. As Tom
pointed out previously, using import-package without version numbers is
questionable. So fundamentally, the various runtime/RCP related bundles
in Eclipse should be putting version numbers on their exports. If they
are going to do that reliably, there needs to be tooling.
To start, I would like to see a better specification developed/agreed upon
before tooling is introduced. Currently, the description of package
versioning is minimal - leaving questions to the developers and tool
implementors:Keep it simple. initial package version == current bundle version
number. @since is package related. Package version numbers increment
with the same semantics as bundle version numbers.
Here are some obvious questions:
* How are @since tags formatted to indicate that the version number
corresponds to packages vs. bundles?
* How are initial package versions derived for existing bundles?
Note that all of these are independent of the use of .qualifier.
Putting version numbers on package exports is just good hygiene.