Hi, top posting, because the answer is simple and straight forward:
Add the Import-Package to bundle C and update just bundle C. Done. Longer answer: The dependency on the missing package (javax.xml.parsers in your example) is basically an implementation detail of Bundle C and neither B nor A care (actually its none of their business). So you just add the Import-Package for the missing package and increment the micro level version of bundle C. Regards Felix Am 02.07.2012 um 15:48 schrieb Dan Gravell: > Cheers Neil, clarifications inline... > > On Mon, Jul 2, 2012 at 2:35 PM, Neil Bartlett <[email protected]> wrote: > >>> Imagine the following package dependencies: >>> >>> A -> B -> C >>> >>> That is, A is dependent on B, B is dependent on C. A, B and C are all in >>> different bundles. For the sake of discussion, the bundles are also >> called >>> A, B and C. The package dependencies are declared in the respective >>> manifests for each bundle >>> >>> Now, I am running C and I notice a CNFE. So I add the required package to >>> C's manifest. >> >> This is not a very precise description of the problem... "add the >> required package to C's manifest" could be interpreted in many ways. >> Are you adding the package as a new export of C? >> > > Sorry. I meant the package required to avoid the CNFE. In this case, > javax.xml.parsers (I think). This isn't really relevant to my question > though, I was just thinking up "some change" to my bundle. It could've been > a code change... > > >> Also, why did the CNFE happen, and from which bundle? It sounds like >> you were missing an Import-Package somewhere, but that kind of problem >> would need to be fixed in A or B, not in C. >> > > From bundle C, because javax.xml.parsers wasn't in Import-Package. I added > this and it worked. I don't know why PDE didn't pick this up nor why I > didn't see it running under Equinox. But as I said above, this isn't > related to my posting, it's just an example of a change which means > versions have to be updated. > > >> Assuming it's a new export then it's a new feature of the bundle, >> therefore the Bundle-Version should be incremented in its minor (i.e. >> second segment). However, semantic versioning of Bunde-Version can be >> a little looser than package versions because they're not actually >> used in resolution (if we ignore Require-Bundle!). > > > No, just an Import-Package. > > >>> 1) Choose an arbitrary package in bundle C and incremement the version >> >> Why? >> > > Because... (deep breath) C is a dependency of B which is a dependency of A, > and I am only updating A as a result of the strategy I outlined in my very > first paragragh. To get C to update so it works, given I only update A, I > need to update the versions so that the correct versions get pulled through > when I update A. > > OBR sees that A has a new version, so it looks at its requirements, and > sees a req for package B version n' which in turn is in bundle B which has > a req for package C version n'. That's how I think it's working anyway. > > >>> 2) In the import for the package chosen in (1) in bundle B, increment the >>> version so the new version will be pulled in upon update. >> >> This doesn't make sense since B could not have an existing import for >> the package (assuming I understood correctly that you are adding a new >> Export to C). >> > > No, so maybe ignore that. > > >>> 3) Now increment an arbitrary package in B >> >> Why? Does B actually need to change at all? If not, why update it? >> > > Because I am only updating A, my "psuedo feature". To get C to update, A > has to have requirements to update down the chain. > > >>> 4) In the import for the package chosen in (3) in bundle A, increment the >>> version so the new version will be pulled in upon update >>> 5) Increment the version of bundle A so that OBR will update it >> >> Why? Again it looks like A doesn't need to change, so there's no need >> to update it. >> > > See the answer for B. > > >>> If I update all extant bundles then I don't need to do this, but how do I >>> remove bundles that are no longer required? >> >> I don't *think* that OBR currently supports "garbage collection" for >> bundles that are no longer needed. However it sounds like you don't >> need to create anywhere near as much garbage as you're currently >> creating, so this is probably less of a problem than you think it is. >> > > Agreed. I think I am answering myself that the other way of doing it, > updating all extant rather than one which has dependencies, is the best > way. Are there any recommended approaches or best practices to this process > for instance covering getting rid of bundles no longer needed? > > If I update each bundle that exists, does ordering matter? For example, > with service registration and other implicit dependencies. I think that's > why I decided against that approach originally. > > Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
