Why the OSGi version policy I see?

[Benson Margulies <bi...@gmail.com>]

Another 'why' question.

Why do we use

<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>

as opposed, perhaps, to

   <!-- Force consumers to respect third version component. -->

<_consumer-policy>$${range;[===,+)}</_consumer-policy>

or something like it? I don't, personally, even know what it means to
put that third value into the policy, I thought that only two slots
were defined.

As a matter of pointless taste, I am not fond of

<Bundle-Activator>${cxf.bundle.activator}</Bundle-Activator>

as opposed to just writing the instruction in the pom that wants it,
but I'm not proposing to have an argument (or to change it).

Re: Why the OSGi version policy I see?

[Benson Margulies <bi...@gmail.com>]

One more ...

      <_failok>true</_failok>

This seems dangerous to me. Don't we want to fix things if they are wrong?


On Tue, Dec 15, 2015 at 9:10 PM, Benson Margulies <bi...@gmail.com> wrote:
> Another 'why' question.
>
> Why do we use
>
> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
>
> as opposed, perhaps, to
>
>    <!-- Force consumers to respect third version component. -->
>
> <_consumer-policy>$${range;[===,+)}</_consumer-policy>
>
> or something like it? I don't, personally, even know what it means to
> put that third value into the policy, I thought that only two slots
> were defined.
>
> As a matter of pointless taste, I am not fond of
>
> <Bundle-Activator>${cxf.bundle.activator}</Bundle-Activator>
>
> as opposed to just writing the instruction in the pom that wants it,
> but I'm not proposing to have an argument (or to change it).