By default the timestamp is having the format "yyyyMMddHHmm" 
<>), this could be a problem in 
certain cases where you redeploy two builds within the same minute.

> On 9. Apr 2018, at 15:55, Justin Edelson <> wrote:
> I'm not sure this is problematic from the perspective of the installer. The
> point of the different SNAPSHOT handling is to support the use case of
> updating a bundle with the *same* bundle version. However, if the bundle
> versions are including a timestamp, it isn't needed since the bundle
> versions would be constantly increasing.
> Now there could be a problem if the timestamp somehow not taking timezones
> into account, but assuming it is UNIX epoch based, then this won't be an
> issue.
> Regards,
> Justin
> On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus <> wrote:
>> I am just migrating the OSGi Installer HC (
>> to the
>> bnd-maven-plugin and I observed one difference to the maven-bundle-plugin:
>> The bundle version for SNAPSHOTs by default looks like "1.0.1.<Timestamp>"
>> instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
>> The reason for that is this line:
>> wich
>> sets the snapshot instruction to the timestamp (
>> This leads to the
>> SNAPSHOT qualifier in the version being replaced by the timestamp in the
>> generated bundle version.
>> This is IMHO problematic in combination with the OSGi Installer, as that
>> behaves differently when it detects a SNAPSHOT (
>> ).
>> Should we configure all our bundles in a way that SNAPSHOT in the version
>> is not being replaced, or can we come up with a more intelligent solution
>> in the OSGi Installer?
>> I noticed that in the manifest we have in addition still
>> "Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base the
>> SNAPSHOT detection of the OSGi Installer.
>> WDYT?
>> Konrad

Reply via email to