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
