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 <steven.huyp...@gmail.com> 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 <j...@nanthrax.net > <mailto:j...@nanthrax.net>> wrote: > Hi, > > Does it mean that you are using features repository in json format ? > > Regards > JB > >> Le 24 mai 2021 à 12:44, Steven Huypens <steven.huyp...@gmail.com >> <mailto:steven.huyp...@gmail.com>> 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 <j...@nanthrax.net >> <mailto:j...@nanthrax.net>> 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 >> <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 <steven.huyp...@gmail.com >>> <mailto:steven.huyp...@gmail.com>> 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 <j...@nanthrax.net >>> <mailto:j...@nanthrax.net>> 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 <steven.huyp...@gmail.com >>> > <mailto:steven.huyp...@gmail.com>> 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 >>> >> >
