Update all bundles, or update one that is dependent on the rest?

[Dan Gravell <el...@googlemail.com>]

When updating bundles, is the best strategy to update all extant bundles or
update one bundle which is a little like an eclipse feature, having
dependencies to the rest?

I've been doing the latter but the resulting workflow seems pretty crazy to
me. 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. Bear in mind first of all that this isn't actually an API
change and not really a package level code change either, so I'm not 100%
sure where that sits in 'semantic versioning', but anyway here's what I do
after adding the dependency:

1) Choose an arbitrary package in bundle C and incremement the version
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.
3) Now increment an arbitrary package in B
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

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?

Dan

Re: Update all bundles, or update one that is dependent on the rest?

[Dan Gravell <el...@googlemail.com>]

Thanks Felix. Just to clarify, you answered my question by saying "update
just bundle C". I need to move to updating all bundles, rather than just
one.

Also thanks for the guidance on incrementing the micro level.

Dan

Re: Update all bundles, or update one that is dependent on the rest?

[Felix Meschberger <fm...@adobe.com>]

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 <nj...@gmail.com> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Update all bundles, or update one that is dependent on the rest?

[Dan Gravell <el...@googlemail.com>]

Cheers Neil, clarifications inline...

On Mon, Jul 2, 2012 at 2:35 PM, Neil Bartlett <nj...@gmail.com> 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

Re: Update all bundles, or update one that is dependent on the rest?

[Neil Bartlett <nj...@gmail.com>]

Responses inline...

On Mon, Jul 2, 2012 at 2:12 PM, Dan Gravell
<el...@googlemail.com> wrote:
> When updating bundles, is the best strategy to update all extant bundles or
> update one bundle which is a little like an eclipse feature, having
> dependencies to the rest?
>
> I've been doing the latter but the resulting workflow seems pretty crazy to
> me. 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?

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.

> Bear in mind first of all that this isn't actually an API
> change and not really a package level code change either, so I'm not 100%
> sure where that sits in 'semantic versioning', but anyway here's what I do
> after adding the dependency:

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!).

> 1) Choose an arbitrary package in bundle C and incremement the version

Why?

> 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).

> 3) Now increment an arbitrary package in B

Why? Does B actually need to change at all? If not, why update it?

> 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.

> 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.

Neil

>
> Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org