Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi Steven,

I would consider as "works as designed" ;)

The OSGi version parser expects "flat" versioning.

Regards
JB

> Le 23 mai 2021 à 11:06, Steven Huypens  a écrit :
> 
> Hi All,
> 
> When using a bootFeature with a leading zero in the version number (eg. 
> 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting Karaf. 
> All my bundles are OK, it's only the state of the feature that seems wrong. 
> When I remove the leading zero (1.1.1-SNAPSHOT), the feature gets state 
> STARTED, as expected.
> 
> Should I consider this a bug or is there a specification telling us not to 
> use leading zeroes for version numbers ?
> 
> Best regards,
> Steven 

Re: bootFeature with leading zero in version does not get state STARTED

[Steven Huypens]

Hi JB,

Thanks for your response. I guess we'll have to change our versioning
scheme then. Do you have a reference to the OSGi spec stating leading
zeroes are not allowed ? I might have to convince some people ;-)

Also, it would be convenient to have at least a WARN in the logging about
this, it took us quite some time to figure out what we were doing wrong.
I'd be happy to create a PR if that would help, but you will have to point
me to the code where this has to be changed.

Best regards,
Steven

On Sun, May 23, 2021 at 5:11 PM Jean-Baptiste Onofre 
wrote:

> Hi Steven,
>
> I would consider as "works as designed" ;)
>
> The OSGi version parser expects "flat" versioning.
>
> Regards
> JB
>
> > Le 23 mai 2021 à 11:06, Steven Huypens  a
> écrit :
> >
> > Hi All,
> >
> > When using a bootFeature with a leading zero in the version number (eg.
> 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting Karaf.
> All my bundles are OK, it's only the state of the feature that seems wrong.
> When I remove the leading zero (1.1.1-SNAPSHOT), the feature gets state
> STARTED, as expected.
> >
> > Should I consider this a bug or is there a specification telling us not
> to use leading zeroes for version numbers ?
> >
> > Best regards,
> > Steven
>
>

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi Steven,

Don’t get me wrong: it’s in the feature/osgi version parser (powered by Felix 
utils), not in the spec.

http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html 


The spec allows leading 0, however, I think that the Felix Util version parser 
removes it.

Let me check in Felix.

Regards
JB

> Le 23 mai 2021 à 19:47, Steven Huypens  a écrit :
> 
> Hi JB,
> 
> Thanks for your response. I guess we'll have to change our versioning scheme 
> then. Do you have a reference to the OSGi spec stating leading zeroes are not 
> allowed ? I might have to convince some people ;-)
> 
> Also, it would be convenient to have at least a WARN in the logging about 
> this, it took us quite some time to figure out what we were doing wrong. I'd 
> be happy to create a PR if that would help, but you will have to point me to 
> the code where this has to be changed.
> 
> Best regards,
> Steven
> 
> On Sun, May 23, 2021 at 5:11 PM Jean-Baptiste Onofre  > wrote:
> Hi Steven,
> 
> I would consider as "works as designed" ;)
> 
> The OSGi version parser expects "flat" versioning.
> 
> Regards
> JB
> 
> > Le 23 mai 2021 à 11:06, Steven Huypens  > > a écrit :
> > 
> > Hi All,
> > 
> > When using a bootFeature with a leading zero in the version number (eg. 
> > 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting Karaf. 
> > All my bundles are OK, it's only the state of the feature that seems wrong. 
> > When I remove the leading zero (1.1.1-SNAPSHOT), the feature gets state 
> > STARTED, as expected.
> > 
> > Should I consider this a bug or is there a specification telling us not to 
> > use leading zeroes for version numbers ?
> > 
> > Best regards,
> > Steven 
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Steven Huypens]

Hi JB,

I've found a VersionCleaner class in org.apache.felix.utils.version, which
is being used in Karaf. But as far as I can see, this class doesn't 'clean'
leading zeroes.

I did see however that the method readNumber() in
org.apache.karaf.util.json.JsonReader seems to skip the leading zero. This
results in a 'wrong' version number in the list of installedFeatures
in org.apache.karaf.features.internal.service.State I'm assuming that's the
reason why my feature does not get installed.



Kind regards,
Steven

On Mon, May 24, 2021 at 6:40 AM Jean-Baptiste Onofre 
wrote:

> Hi Steven,
>
> Don’t get me wrong: it’s in the feature/osgi version parser (powered by
> Felix utils), not in the spec.
>
> http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html
>
> The spec allows leading 0, however, I think that the Felix Util version
> parser removes it.
>
> Let me check in Felix.
>
> Regards
> JB
>
> Le 23 mai 2021 à 19:47, Steven Huypens  a écrit
> :
>
> Hi JB,
>
> Thanks for your response. I guess we'll have to change our versioning
> scheme then. Do you have a reference to the OSGi spec stating leading
> zeroes are not allowed ? I might have to convince some people ;-)
>
> Also, it would be convenient to have at least a WARN in the logging about
> this, it took us quite some time to figure out what we were doing wrong.
> I'd be happy to create a PR if that would help, but you will have to point
> me to the code where this has to be changed.
>
> Best regards,
> Steven
>
> On Sun, May 23, 2021 at 5:11 PM Jean-Baptiste Onofre 
> wrote:
>
>> Hi Steven,
>>
>> I would consider as "works as designed" ;)
>>
>> The OSGi version parser expects "flat" versioning.
>>
>> Regards
>> JB
>>
>> > Le 23 mai 2021 à 11:06, Steven Huypens  a
>> écrit :
>> >
>> > Hi All,
>> >
>> > When using a bootFeature with a leading zero in the version number (eg.
>> 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting Karaf.
>> All my bundles are OK, it's only the state of the feature that seems wrong.
>> When I remove the leading zero (1.1.1-SNAPSHOT), the feature gets state
>> STARTED, as expected.
>> >
>> > Should I consider this a bug or is there a specification telling us not
>> to use leading zeroes for version numbers ?
>> >
>> > Best regards,
>> > Steven
>>
>>
>

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi,

Does it mean that you are using features repository in json format ?

Regards
JB

> Le 24 mai 2021 à 12:44, Steven Huypens  a écrit :
> 
> Hi JB,
> 
> I've found a VersionCleaner class in org.apache.felix.utils.version, which is 
> being used in Karaf. But as far as I can see, this class doesn't 'clean' 
> leading zeroes.
> 
> I did see however that the method readNumber() in 
> org.apache.karaf.util.json.JsonReader seems to skip the leading zero. This 
> results in a 'wrong' version number in the list of installedFeatures in 
> org.apache.karaf.features.internal.service.State I'm assuming that's the 
> reason why my feature does not get installed.
> 
> 
> 
> Kind regards,
> Steven
> 
> On Mon, May 24, 2021 at 6:40 AM Jean-Baptiste Onofre  > wrote:
> Hi Steven,
> 
> Don’t get me wrong: it’s in the feature/osgi version parser (powered by Felix 
> utils), not in the spec.
> 
> http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html 
> 
> 
> The spec allows leading 0, however, I think that the Felix Util version 
> parser removes it.
> 
> Let me check in Felix.
> 
> Regards
> JB
> 
>> Le 23 mai 2021 à 19:47, Steven Huypens > > a écrit :
>> 
>> Hi JB,
>> 
>> Thanks for your response. I guess we'll have to change our versioning scheme 
>> then. Do you have a reference to the OSGi spec stating leading zeroes are 
>> not allowed ? I might have to convince some people ;-)
>> 
>> Also, it would be convenient to have at least a WARN in the logging about 
>> this, it took us quite some time to figure out what we were doing wrong. I'd 
>> be happy to create a PR if that would help, but you will have to point me to 
>> the code where this has to be changed.
>> 
>> Best regards,
>> Steven
>> 
>> On Sun, May 23, 2021 at 5:11 PM Jean-Baptiste Onofre > > wrote:
>> Hi Steven,
>> 
>> I would consider as "works as designed" ;)
>> 
>> The OSGi version parser expects "flat" versioning.
>> 
>> Regards
>> JB
>> 
>> > Le 23 mai 2021 à 11:06, Steven Huypens > > > a écrit :
>> > 
>> > Hi All,
>> > 
>> > When using a bootFeature with a leading zero in the version number (eg. 
>> > 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting Karaf. 
>> > All my bundles are OK, it's only the state of the feature that seems 
>> > wrong. When I remove the leading zero (1.1.1-SNAPSHOT), the feature gets 
>> > state STARTED, as expected.
>> > 
>> > Should I consider this a bug or is there a specification telling us not to 
>> > use leading zeroes for version numbers ?
>> > 
>> > Best regards,
>> > Steven 
>> 
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Steven Huypens]

Hi,

No, it's a simple feature.xml file

The JsonReader class is used to read the cached file state.json, but I now
see that that file contains the wrong version already.

I've taken a better look and I think it's the SubsystemResolver where the
zero gets lost, more specifically this line :

wiring = resolver.resolve(context);




Kind regards,
Steven

On Mon, May 24, 2021 at 1:27 PM Jean-Baptiste Onofre 
wrote:

> Hi,
>
> Does it mean that you are using features repository in json format ?
>
> Regards
> JB
>
> Le 24 mai 2021 à 12:44, Steven Huypens  a écrit
> :
>
> Hi JB,
>
> I've found a VersionCleaner class in org.apache.felix.utils.version, which
> is being used in Karaf. But as far as I can see, this class doesn't 'clean'
> leading zeroes.
>
> I did see however that the method readNumber() in
> org.apache.karaf.util.json.JsonReader seems to skip the leading zero. This
> results in a 'wrong' version number in the list of installedFeatures
> in org.apache.karaf.features.internal.service.State I'm assuming that's the
> reason why my feature does not get installed.
>
>
>
> Kind regards,
> Steven
>
> On Mon, May 24, 2021 at 6:40 AM Jean-Baptiste Onofre 
> wrote:
>
>> Hi Steven,
>>
>> Don’t get me wrong: it’s in the feature/osgi version parser (powered by
>> Felix utils), not in the spec.
>>
>> http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html
>>
>> The spec allows leading 0, however, I think that the Felix Util version
>> parser removes it.
>>
>> Let me check in Felix.
>>
>> Regards
>> JB
>>
>> Le 23 mai 2021 à 19:47, Steven Huypens  a
>> écrit :
>>
>> Hi JB,
>>
>> Thanks for your response. I guess we'll have to change our versioning
>> scheme then. Do you have a reference to the OSGi spec stating leading
>> zeroes are not allowed ? I might have to convince some people ;-)
>>
>> Also, it would be convenient to have at least a WARN in the logging about
>> this, it took us quite some time to figure out what we were doing wrong.
>> I'd be happy to create a PR if that would help, but you will have to point
>> me to the code where this has to be changed.
>>
>> Best regards,
>> Steven
>>
>> On Sun, May 23, 2021 at 5:11 PM Jean-Baptiste Onofre 
>> wrote:
>>
>>> Hi Steven,
>>>
>>> I would consider as "works as designed" ;)
>>>
>>> The OSGi version parser expects "flat" versioning.
>>>
>>> Regards
>>> JB
>>>
>>> > Le 23 mai 2021 à 11:06, Steven Huypens  a
>>> écrit :
>>> >
>>> > Hi All,
>>> >
>>> > When using a bootFeature with a leading zero in the version number
>>> (eg. 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting
>>> Karaf. All my bundles are OK, it's only the state of the feature that seems
>>> wrong. When I remove the leading zero (1.1.1-SNAPSHOT), the feature gets
>>> state STARTED, as expected.
>>> >
>>> > Should I consider this a bug or is there a specification telling us
>>> not to use leading zeroes for version numbers ?
>>> >
>>> > Best regards,
>>> > Steven
>>>
>>>
>>
>

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi Steven,

Yeah, the state should already contain the "cleaned" versions.

I will take a look.

Anyway, as best practice, I would avoid leading 0 ;)

Regards
JB

> Le 24 mai 2021 à 16:57, Steven Huypens  a écrit :
> 
> Hi,
> 
> No, it's a simple feature.xml file
> 
> The JsonReader class is used to read the cached file state.json, but I now 
> see that that file contains the wrong version already.
> 
> I've taken a better look and I think it's the SubsystemResolver where the 
> zero gets lost, more specifically this line :
> 
> wiring = resolver.resolve(context);
> 
> 
> 
> 
> Kind regards,
> Steven
> 
> On Mon, May 24, 2021 at 1:27 PM Jean-Baptiste Onofre  > wrote:
> Hi,
> 
> Does it mean that you are using features repository in json format ?
> 
> Regards
> JB
> 
>> Le 24 mai 2021 à 12:44, Steven Huypens > > a écrit :
>> 
>> Hi JB,
>> 
>> I've found a VersionCleaner class in org.apache.felix.utils.version, which 
>> is being used in Karaf. But as far as I can see, this class doesn't 'clean' 
>> leading zeroes.
>> 
>> I did see however that the method readNumber() in 
>> org.apache.karaf.util.json.JsonReader seems to skip the leading zero. This 
>> results in a 'wrong' version number in the list of installedFeatures in 
>> org.apache.karaf.features.internal.service.State I'm assuming that's the 
>> reason why my feature does not get installed.
>> 
>> 
>> 
>> Kind regards,
>> Steven
>> 
>> On Mon, May 24, 2021 at 6:40 AM Jean-Baptiste Onofre > > wrote:
>> Hi Steven,
>> 
>> Don’t get me wrong: it’s in the feature/osgi version parser (powered by 
>> Felix utils), not in the spec.
>> 
>> http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html 
>> 
>> 
>> The spec allows leading 0, however, I think that the Felix Util version 
>> parser removes it.
>> 
>> Let me check in Felix.
>> 
>> Regards
>> JB
>> 
>>> Le 23 mai 2021 à 19:47, Steven Huypens >> > a écrit :
>>> 
>>> Hi JB,
>>> 
>>> Thanks for your response. I guess we'll have to change our versioning 
>>> scheme then. Do you have a reference to the OSGi spec stating leading 
>>> zeroes are not allowed ? I might have to convince some people ;-)
>>> 
>>> Also, it would be convenient to have at least a WARN in the logging about 
>>> this, it took us quite some time to figure out what we were doing wrong. 
>>> I'd be happy to create a PR if that would help, but you will have to point 
>>> me to the code where this has to be changed.
>>> 
>>> Best regards,
>>> Steven
>>> 
>>> On Sun, May 23, 2021 at 5:11 PM Jean-Baptiste Onofre >> > wrote:
>>> Hi Steven,
>>> 
>>> I would consider as "works as designed" ;)
>>> 
>>> The OSGi version parser expects "flat" versioning.
>>> 
>>> Regards
>>> JB
>>> 
>>> > Le 23 mai 2021 à 11:06, Steven Huypens >> > > a écrit :
>>> > 
>>> > Hi All,
>>> > 
>>> > When using a bootFeature with a leading zero in the version number (eg. 
>>> > 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting 
>>> > Karaf. All my bundles are OK, it's only the state of the feature that 
>>> > seems wrong. When I remove the leading zero (1.1.1-SNAPSHOT), the feature 
>>> > gets state STARTED, as expected.
>>> > 
>>> > Should I consider this a bug or is there a specification telling us not 
>>> > to use leading zeroes for version numbers ?
>>> > 
>>> > Best regards,
>>> > Steven 
>>> 
>> 
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Daniel Krügler]

Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:

Hi Steven,

Yeah, the state should already contain the "cleaned" versions.

I will take a look.

Anyway, as best practice, I would avoid leading 0 ;)


I completely agree and I don't understand why there should be additional
work invested to "fix" that. The OSGi specification is clear that any
leading zeros in version numbers are invalid. Anyone attempting to
provide such a bundle should correct the version number and remove the
leading zeros.

- Daniel

Re: bootFeature with leading zero in version does not get state STARTED

[Steven Huypens]

Hi Daniel,

If that's clearly stated, I'll try to have our version numbers changed. Can
you tell me where to find this statement ? I did try to look for it myself,
but couldn't find it.


Best regards,
Steven

On Mon, May 24, 2021 at 5:16 PM Daniel Krügler 
wrote:

> Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
> > Hi Steven,
> >
> > Yeah, the state should already contain the "cleaned" versions.
> >
> > I will take a look.
> >
> > Anyway, as best practice, I would avoid leading 0 ;)
>
> I completely agree and I don't understand why there should be additional
> work invested to "fix" that. The OSGi specification is clear that any
> leading zeros in version numbers are invalid. Anyone attempting to
> provide such a bundle should correct the version number and remove the
> leading zeros.
>
> - Daniel
>
>

Re: bootFeature with leading zero in version does not get state STARTED

[Daniel Krügler]

Am 24.05.2021 um 18:25 schrieb Steven Huypens:

Hi Daniel,

If that's clearly stated, I'll try to have our version numbers
changed. Can you tell me where to find this statement ? I did try to
look for it myself, but couldn't find it.


Hi Steven,

Good that you insisted me to double-check - I was wrong! I was mixing
that up with a different version specification where leading zeros where
not allowed, but I indeed couldn't find concrete evidence for leading
zeros being invalid in OSGi version.

I apologize for the misleading comment and false statement,

- Daniel




Best regards,
Steven

On Mon, May 24, 2021 at 5:16 PM Daniel Krügler mailto:daniel.krueg...@gmx.de>> wrote:

Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
> Hi Steven,
>
> Yeah, the state should already contain the "cleaned" versions.
>
> I will take a look.
>
> Anyway, as best practice, I would avoid leading 0 ;)

I completely agree and I don't understand why there should be
additional
work invested to "fix" that. The OSGi specification is clear that any
leading zeros in version numbers are invalid. Anyone attempting to
provide such a bundle should correct the version number and remove the
leading zeros.

- Daniel

Re: bootFeature with leading zero in version does not get state STARTED

[Steven Huypens]

Hi Daniel,

No problem, I'm glad you sorted it out. I will still try to change our
version numbers, but now I do consider this to be a little bug ;-)

Kind regards,
Steven

On Mon, May 24, 2021 at 6:46 PM Daniel Krügler 
wrote:

> Am 24.05.2021 um 18:25 schrieb Steven Huypens:
>
> Hi Daniel,
>
> If that's clearly stated, I'll try to have our version numbers changed.
> Can you tell me where to find this statement ? I did try to look for it
> myself, but couldn't find it.
>
>
> Hi Steven,
>
> Good that you insisted me to double-check - I was wrong! I was mixing that
> up with a different version specification where leading zeros where not
> allowed, but I indeed couldn't find concrete evidence for leading zeros
> being invalid in OSGi version.
>
> I apologize for the misleading comment and false statement,
>
> - Daniel
>
>
>
> Best regards,
> Steven
>
> On Mon, May 24, 2021 at 5:16 PM Daniel Krügler 
> wrote:
>
>> Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
>> > Hi Steven,
>> >
>> > Yeah, the state should already contain the "cleaned" versions.
>> >
>> > I will take a look.
>> >
>> > Anyway, as best practice, I would avoid leading 0 ;)
>>
>> I completely agree and I don't understand why there should be additional
>> work invested to "fix" that. The OSGi specification is clear that any
>> leading zeros in version numbers are invalid. Anyone attempting to
>> provide such a bundle should correct the version number and remove the
>> leading zeros.
>>
>> - Daniel
>>
>>
>

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi Daniel,

I don’t think there’s any enforcement in the OSGi spec regarding leading 0 
(actually, I think it’s "blurry" as there’s no details in one way or another).

That’s why I said more a "best practice".

Generally speaking (not OSGi related), I don’t see any good reason to use 
leading 0 in version ;)

So, as the spec is not very strict about that, we should support it in the 
resolver.

Regards
JB

> Le 24 mai 2021 à 17:16, Daniel Krügler  a écrit :
> 
> Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
>> Hi Steven,
>> 
>> Yeah, the state should already contain the "cleaned" versions.
>> 
>> I will take a look.
>> 
>> Anyway, as best practice, I would avoid leading 0 ;)
> 
> I completely agree and I don't understand why there should be additional
> work invested to "fix" that. The OSGi specification is clear that any
> leading zeros in version numbers are invalid. Anyone attempting to
> provide such a bundle should correct the version number and remove the
> leading zeros.
> 
> - Daniel
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Steven Huypens]

Hi,

Apparently our customer needs the version numbers to be alphanumerically
sortable, so we cannot remove the leading zeroes. I'm looking forward to a
solution, let me know how I can help.


Best regards,
Steven

On Tue, May 25, 2021 at 6:19 AM Jean-Baptiste Onofre 
wrote:

> Hi Daniel,
>
> I don’t think there’s any enforcement in the OSGi spec regarding leading 0
> (actually, I think it’s "blurry" as there’s no details in one way or
> another).
>
> That’s why I said more a "best practice".
>
> Generally speaking (not OSGi related), I don’t see any good reason to use
> leading 0 in version ;)
>
> So, as the spec is not very strict about that, we should support it in the
> resolver.
>
> Regards
> JB
>
> > Le 24 mai 2021 à 17:16, Daniel Krügler  a écrit
> :
> >
> > Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
> >> Hi Steven,
> >>
> >> Yeah, the state should already contain the "cleaned" versions.
> >>
> >> I will take a look.
> >>
> >> Anyway, as best practice, I would avoid leading 0 ;)
> >
> > I completely agree and I don't understand why there should be additional
> > work invested to "fix" that. The OSGi specification is clear that any
> > leading zeros in version numbers are invalid. Anyone attempting to
> > provide such a bundle should correct the version number and remove the
> > leading zeros.
> >
> > - Daniel
> >
>
>

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Ok,

Can you please create a Jira about that, I will fix/improve that.

Regards
JB

> Le 25 mai 2021 à 09:08, Steven Huypens  a écrit :
> 
> Hi,
> 
> Apparently our customer needs the version numbers to be alphanumerically 
> sortable, so we cannot remove the leading zeroes. I'm looking forward to a 
> solution, let me know how I can help.
> 
> 
> Best regards,
> Steven
> 
> On Tue, May 25, 2021 at 6:19 AM Jean-Baptiste Onofre  > wrote:
> Hi Daniel,
> 
> I don’t think there’s any enforcement in the OSGi spec regarding leading 0 
> (actually, I think it’s "blurry" as there’s no details in one way or another).
> 
> That’s why I said more a "best practice".
> 
> Generally speaking (not OSGi related), I don’t see any good reason to use 
> leading 0 in version ;)
> 
> So, as the spec is not very strict about that, we should support it in the 
> resolver.
> 
> Regards
> JB
> 
> > Le 24 mai 2021 à 17:16, Daniel Krügler  > > a écrit :
> > 
> > Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
> >> Hi Steven,
> >> 
> >> Yeah, the state should already contain the "cleaned" versions.
> >> 
> >> I will take a look.
> >> 
> >> Anyway, as best practice, I would avoid leading 0 ;)
> > 
> > I completely agree and I don't understand why there should be additional
> > work invested to "fix" that. The OSGi specification is clear that any
> > leading zeros in version numbers are invalid. Anyone attempting to
> > provide such a bundle should correct the version number and remove the
> > leading zeros.
> > 
> > - Daniel
> > 
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Steven Huypens]

https://issues.apache.org/jira/browse/KARAF-7163

Regards
Steven

On Tue, May 25, 2021 at 10:06 AM Jean-Baptiste Onofre 
wrote:

> Ok,
>
> Can you please create a Jira about that, I will fix/improve that.
>
> Regards
> JB
>
> Le 25 mai 2021 à 09:08, Steven Huypens  a écrit
> :
>
> Hi,
>
> Apparently our customer needs the version numbers to be alphanumerically
> sortable, so we cannot remove the leading zeroes. I'm looking forward to a
> solution, let me know how I can help.
>
>
> Best regards,
> Steven
>
> On Tue, May 25, 2021 at 6:19 AM Jean-Baptiste Onofre 
> wrote:
>
>> Hi Daniel,
>>
>> I don’t think there’s any enforcement in the OSGi spec regarding leading
>> 0 (actually, I think it’s "blurry" as there’s no details in one way or
>> another).
>>
>> That’s why I said more a "best practice".
>>
>> Generally speaking (not OSGi related), I don’t see any good reason to use
>> leading 0 in version ;)
>>
>> So, as the spec is not very strict about that, we should support it in
>> the resolver.
>>
>> Regards
>> JB
>>
>> > Le 24 mai 2021 à 17:16, Daniel Krügler  a
>> écrit :
>> >
>> > Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
>> >> Hi Steven,
>> >>
>> >> Yeah, the state should already contain the "cleaned" versions.
>> >>
>> >> I will take a look.
>> >>
>> >> Anyway, as best practice, I would avoid leading 0 ;)
>> >
>> > I completely agree and I don't understand why there should be additional
>> > work invested to "fix" that. The OSGi specification is clear that any
>> > leading zeros in version numbers are invalid. Anyone attempting to
>> > provide such a bundle should correct the version number and remove the
>> > leading zeros.
>> >
>> > - Daniel
>> >
>>
>>
>

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Thanks ! Updated to target Karaf runtime 4.2.12 and 4.3.3.

I will keep you posted in the Jira.

Regards
JB

> Le 25 mai 2021 à 10:17, Steven Huypens  a écrit :
> 
> 
> https://issues.apache.org/jira/browse/KARAF-7163 
> 
> 
> Regards
> Steven
> 
> On Tue, May 25, 2021 at 10:06 AM Jean-Baptiste Onofre  > wrote:
> Ok,
> 
> Can you please create a Jira about that, I will fix/improve that.
> 
> Regards
> JB
> 
>> Le 25 mai 2021 à 09:08, Steven Huypens > > a écrit :
>> 
>> Hi,
>> 
>> Apparently our customer needs the version numbers to be alphanumerically 
>> sortable, so we cannot remove the leading zeroes. I'm looking forward to a 
>> solution, let me know how I can help.
>> 
>> 
>> Best regards,
>> Steven
>> 
>> On Tue, May 25, 2021 at 6:19 AM Jean-Baptiste Onofre > > wrote:
>> Hi Daniel,
>> 
>> I don’t think there’s any enforcement in the OSGi spec regarding leading 0 
>> (actually, I think it’s "blurry" as there’s no details in one way or 
>> another).
>> 
>> That’s why I said more a "best practice".
>> 
>> Generally speaking (not OSGi related), I don’t see any good reason to use 
>> leading 0 in version ;)
>> 
>> So, as the spec is not very strict about that, we should support it in the 
>> resolver.
>> 
>> Regards
>> JB
>> 
>> > Le 24 mai 2021 à 17:16, Daniel Krügler > > > a écrit :
>> > 
>> > Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
>> >> Hi Steven,
>> >> 
>> >> Yeah, the state should already contain the "cleaned" versions.
>> >> 
>> >> I will take a look.
>> >> 
>> >> Anyway, as best practice, I would avoid leading 0 ;)
>> > 
>> > I completely agree and I don't understand why there should be additional
>> > work invested to "fix" that. The OSGi specification is clear that any
>> > leading zeros in version numbers are invalid. Anyone attempting to
>> > provide such a bundle should correct the version number and remove the
>> > leading zeros.
>> > 
>> > - Daniel
>> > 
>> 
>