Re: [osgi-dev] Micro version ignored when resolving, rationale?

Right, so lets look at these one by one: > "The importer's version range matches the exporter's version. See Semantic > Versioning > .” > The reference to semantic versioning makes the

Re: [osgi-dev] Micro version ignored when resolving, rationale?

Thanks for engaging yourself with my question. I think my problems boil down to two issues that could (and maybe should) be improved in the specification. > I’ll try to take the questions individually, and we can attempt to > separate your questions about build/packaging (i.e. creating your >

Re: [osgi-dev] Micro version ignored when resolving, rationale?

-- Original message - >> From: Michael Lipp via osgi-dev >> <mailto:osgi-dev@mail.osgi.org> >> Sent by: osgi-dev-boun...@mail.osgi.org >> <mailto:osgi-dev-boun...@mail.osgi.org> >> To: Neil Bartlett <mailto:njbartl...@gmail.com>, OSGi >> Deve

Re: [osgi-dev] Micro version ignored when resolving, rationale?

>   > > - Original message - > From: Michael Lipp via osgi-dev > Sent by: osgi-dev-boun...@mail.osgi.org > To: Neil Bartlett , OSGi Developer Mail List > > Cc: > Subject: [EXTERNAL] Re: [osgi-dev] Micro version ignored when >

Re: [osgi-dev] Micro version ignored when resolving, rationale?

// mobile: +1 386 848 3788hargr...@us.ibm.com     - Original message -From: Michael Lipp via osgi-dev Sent by: osgi-dev-boun...@mail.osgi.orgTo: Neil Bartlett , OSGi Developer Mail List Cc:Subject: [EXTERNAL] Re: [osgi-dev] Micro version ignored when resolving, rationale?Date: Tue, Jun 18, 2019

Re: [osgi-dev] Micro version ignored when resolving, rationale?

> As for why bnd makes this implementation choice, bear in mind that > import ranges are applied to packages, which in a pure and ideal world > would contain only interfaces and perhaps DTOs, but no implementation > code. What kind of "bugs" could we be talking about in such a package, > other

Re: [osgi-dev] Micro version ignored when resolving, rationale?

> So having default settings in the tool that cause a behavior that does not comply with the specification should not be considered a bug? Which specification?? There is NO specification in OSGi for how a packaging tool such as bnd should generate bundles from Java classes and descriptors. The

Re: [osgi-dev] Micro version ignored when resolving, rationale?

>> Considering this, lowering a lower bound of an Import-Package statement when >> resolving should be acknowledged as a bug. >> Bnd does not alter the version used when resolving, as this would give “incorrect” answers that don’t resolve. The resolver must use the exact metadata from the

Re: [osgi-dev] Micro version ignored when resolving, rationale?

>> Considering this, lowering a lower bound of an Import-Package >> statement when resolving should be acknowledged as a bug.  >> > I beg to differ ... > > As said, you can set the consumer/provider policy to your desired > strategy. > So having default settings in the tool that cause a behavior

Re: [osgi-dev] Micro version ignored when resolving, rationale?

> Considering this, lowering a lower bound of an Import-Package statement when > resolving should be acknowledged as a bug. > I beg to differ ... As said, you can set the consumer/provider policy to your desired strategy. Kind regards, Peter Kriens > On 18 Jun 2019, at 10:33,

Re: [osgi-dev] Micro version ignored when resolving, rationale?

> > I expect there are two things at play. First, OSGi specifies things as > you indicate. An import of [1.2.3.qualifier,2) must not select > anything lower than 1.2.3.qualifier. Second, bnd does have heuristics > that do drop the qualifier and micro part in calculating the import > ranges from

Re: [osgi-dev] Micro version ignored when resolving, rationale?

As Tim indicates we need more information. I expect there are two things at play. First, OSGi specifies things as you indicate. An import of [1.2.3.qualifier,2) must not select anything lower than 1.2.3.qualifier. Second, bnd does have heuristics that do drop the qualifier and micro part in

Re: [osgi-dev] Micro version ignored when resolving, rationale?

"the specification, which states that the micro part of the version should be ignored when resolving bundles" The OSGi specification absolutely does NOT state this. Mainly for the reasons you have laid out yourself. Regards, Neil. On Mon, 17 Jun 2019 at 23:14, Michael Lipp via osgi-dev <

Re: [osgi-dev] Micro version ignored when resolving, rationale?

Hi > I may have expressed myself badly. Nothing goes wrong, everything works > according to the specification, which states that the micro part of the > version should be ignored when resolving bundles. …. > If OSGI didn't specify that the micro part should be dropped, then > everything would

Re: [osgi-dev] Micro version ignored when resolving, rationale?

Hi Tim, I may have expressed myself badly. Nothing goes wrong, everything works according to the specification, which states that the micro part of the version should be ignored when resolving bundles. My question is whether anybody can explain why the behavior was specified in such an

Re: [osgi-dev] Micro version ignored when resolving, rationale?

Hi Michael, I’m afraid that there’s quite a lot of missing information before I could come to a conclusion about what’s going on. What are your input requirements? Have you checked that B actually has the version range that you think it does? Are there two versions of A being deployed? If it’s