Re: [equinox-dev] .qualifier for export package?
I agree. Another example is SWT. We have full SWT, eSWT and RWT (RAP's SWT). Assuming that they implemented complete packages (I don't know this to be true but this is an example) then consumers would depend on the packages and the packages would expose API but would include implementation. The pulling thread analogy is good and that is indeed what we need here. For example, there is a thread on the pmc and now pde ui list about using p2 for managing PDE targets. It makes a lot of sense IMHO but we need some way of people saying they need X and get everything else they need put in the target. BJ's comment about builds initially put me off but then combined with a notion of lineups I'm seeing something good. If the build defined a lineup and people could spec their preferred lineup(s) then when they go for X and need Y and Z etc they would get the ones from the lineups. An alternative would be to have one repo per build but that IMHO gets hard to manage and is divergent from our normal expected usecases. So perhaps we version our package exports without qulifiers (and perhaps with or without micro) and work in the p2 world to get lineups working Jeff Thomas Watson wrote: For the most part I agree. But I do think there is value in versioning API packages that contain not only pure specification but also implementation. One real example is the OSGi package org.osgi.util.tracker package. This package contains the ServiceTracker API, but the ServiceTracker class also provides a significant amount of code behind the implementation of the API. Any bug fixes to the implementation contained in this package should be reflected by increasing the micro version of the package. Clients that only care about the pure specification would use the major.minor version to import, but if a bundle cannot work without some fix contained in a micro version of the package then the bundle should be able to import down to the micro version of the package. Tom John Arthorne ---09/05/2008 11:00:08 AM---We have qualifiers on bundles to support the notion of provisioning "line-ups" (aka features) that list precise groups of IUs ( From: John Arthorne [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 09/05/2008 11:00 AM Subject: Re: [equinox-dev] .qualifier for export package? We have qualifiers on bundles to support the notion of provisioning "line-ups" (aka features) that list precise groups of IUs (one precise build of a particular bundle). We *don't* have qualifiers on bundles so that require-bundle statements can precisely choose a particular build of a bundle to depend on, since this kind of coupling is too restrictive. We don't have any mechanism today for defining line-ups of packages as we do today with bundles, so qualifiers on packages currently have no value. I think the use case you have in mind is picking a single bundle as a starting point, and then expanding from that bundle based on its dependencies (picking a thread in the ball of yarn and pulling on it to see what comes out). In this scenario, if the bundle has an import-package statement, and there are multiple builds of a bundle providing that package in the repository, which one do you choose? The problem here as BJ points out, is we would never want to couple our require-bundle/import-package statements down to the qualifier level. This tight coupling completely defeats the purpose of the component architecture where dependencies are expressed at the level of specification. So, I don't think this ball-of-yarn scenario can work in a development scenario where I want to provision and test a particular build from a development repository containing several builds. I think this scenario is only interesting when run against repositories of officially released content such as the release train repository, in which case any package that satisfies the import is acceptable and qualifiers on either imports or exports are not needed. More fundamentally, I may be alone here but I question the premise that packages are simply finer-grained versions of bundles, and so everything we do with bundle versions is still applicable at the package level. My thinking is that a bundle is a container that holds specifications, implementations, and other non-code artifacts. As such its version number must have the flexibility to capture the fact that it contains not only API, but other non-API artifacts that people may rely on (implementation characteristics, extension points, documentation, source code, etc). When someone has a require-bundle statement, they may want to express their dependency on any one of the things that bundle contains. Thus it's reasonable for someone to have a dependency range
Re: [equinox-dev] .qualifier for export package?
no. If you spec a constraint on a package, the bundle or version of the bundle from which the package comes does not factor into the decision. Jeff David M Williams wrote: Without some sort of increasing version number on the packages, p2 for example, will have a hard time figuring out what to give you cause everything will look the same to it. Can anyone think of another way of enabling #2? Wouldn't p2 _have_ to always pick a bundle with the highest qualifier (thereby getting the highest level of any packages in that bundle)? If not, then this API use case would only be a special case of a general problem of using "old" implementations. Perhaps I'm missing the point? From: Jeff McAffer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 09/05/2008 04:32 AM Subject: Re: [equinox-dev] .qualifier for export package? I'm certainly sympathetic to you thinking here. Having qualifiers in import statements is ugly at best. The challenge is that in the dev cycle the API of something may change many many times. This would lead to quite visible changes in unreasonable ways. For example, say we introduce some API and then "break" it several times as we refine in the dev cycle. Then the first release of the API might have version 42.23.27 or some such. Trying to manage API semantics during the dev/release cycle seems like overkill. Clearly that is an over done example but you get the point I hope. Lets step back for a second. Some goals in decreasing order of priority/importance. Goal #1: ensure that at least all API packages have version numbers on the exports. Goal #2: be able to eat our own dog food wrt provisioning and version management during the dev cycle. Good news is that #1 is likely agreed to and *all* we have to do is put the initial version numbers on the current packages and then have the tooling help people manage them according to the current versioning model. The proposal for using .qualifier was actually one possible implementation of goal #2. #2 is interesting because eating our own dog food seems to greatly increase the likelihood of our technology being good/useful. Without some sort of increasing version number on the packages, p2 for example, will have a hard time figuring out what to give you cause everything will look the same to it. Can anyone think of another way of enabling #2? Of the top of my head I'm thinking that something like the odd/even version pattern might help... Jeff BJ Hargrave wrote: If you change API during dev cycle, that is the proper time to also change the major or minor version. That is the whole point. I would assume that API tooling will complain until you do so. Just changing the qualifier is insufficient to capture an API change. Also, I think that last thing we want to see are bundles using qualifiers in import package statements! So if you use qualifier to denote API change during dev, then other bundles will need to import using qualifiers to ensure they wire to the desire API if they use it. UGLY! Qualifiers are useful to capture implementation changes. But API is a specified thing that changes deliberately and (hopefully) slowly and its version is not subject to implementation. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Jeff McAffer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/03 06:16 AM Subject: Re: [equinox-dev] .qualifier for export package? I understand your hestiation and actually agree with you from the "released code" point of view. However, we spend a lot of time dealing with code and API that is in development. If we are to have any hope of provisioning and managing that, we need to know the difference between the various iterations of the packages. For example, when someone adds an API during the dev cycle and you want use it, you need to import the right version of the package to ensure you get it. Changing the first three segments version number of the package for every change done in the dev cycle feels too disruptive. To a certain extent this could be handled in the provisioning system but that would force the situation of bundles in a particular context (e.g., a build "lineup"). That is, bundles would no longer be completely/accurately
Re: [equinox-dev] .qualifier for export package?
Yup. It is not so much that I want to control the version of the package rather that I want to be able to use p2 during development. So I started this thread off with a solution rather than stating the problem (to be honest I don't think I fully formed the problem in my head at that time). I'm thinking that something in the lineup direction will be beneficial here... Jeff BJ Hargrave wrote: If I understand #2 correctly, then you want a controlled version practice during the development cycle. This is challenging since you may want to change your mind and break from a previous API change made during the same dev cycle. For example: 1.2 is the last shipped version of a package (let's say thats in Ganymede). So during the dev cycle you change to 1.3 because you add new API. Soon you add more API. 1.3.1 or 1.4? Then you decide to pull some of those API changes because we learned they did not work as expected. What version then? 2.0? Because of the breaking change? I think this is a fairly impossible situation during the dev cycle because we are free to change our mind about new API until API freeze. I think the odd/even versioning could be useful. But it still does not easily handle the removal of new API previously added during the dev cycle. It only seems to work well if the API only "grows" but does not shrink. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Jeff McAffer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/05 04:32 AM Subject: Re: [equinox-dev] .qualifier for export package? I'm certainly sympathetic to you thinking here. Having qualifiers in import statements is ugly at best. The challenge is that in the dev cycle the API of something may change many many times. This would lead to quite visible changes in unreasonable ways. For example, say we introduce some API and then "break" it several times as we refine in the dev cycle. Then the first release of the API might have version 42.23.27 or some such. Trying to manage API semantics during the dev/release cycle seems like overkill. Clearly that is an over done example but you get the point I hope. Lets step back for a second. Some goals in decreasing order of priority/importance. Goal #1: ensure that at least all API packages have version numbers on the exports. Goal #2: be able to eat our own dog food wrt provisioning and version management during the dev cycle. Good news is that #1 is likely agreed to and *all* we have to do is put the initial version numbers on the current packages and then have the tooling help people manage them according to the current versioning model. The proposal for using .qualifier was actually one possible implementation of goal #2. #2 is interesting because eating our own dog food seems to greatly increase the likelihood of our technology being good/useful. Without some sort of increasing version number on the packages, p2 for example, will have a hard time figuring out what to give you cause everything will look the same to it. Can anyone think of another way of enabling #2? Of the top of my head I'm thinking that something like the odd/even version pattern might help... Jeff BJ Hargrave wrote: If you change API during dev cycle, that is the proper time to also change the major or minor version. That is the whole point. I would assume that API tooling will complain until you do so. Just changing the qualifier is insufficient to capture an API change. Also, I think that last thing we want to see are bundles using qualifiers in import package statements! So if you use qualifier to denote API change during dev, then other bundles will need to import using qualifiers to ensure they wire to the desire API if they use it. UGLY! Qualifiers are useful to capture implementation changes. But API is a specified thing that changes deliberately and (hopefully) slowly and its version is not subject to implementation. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Jeff McAffer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008/09/03 06:16 AM Subject:
