By default the timestamp is having the format "yyyyMMddHHmm"
<http://bnd.bndtools.org/macros/tstamp.html>), 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 <jus...@justinedelson.com> 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
> On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus <konra...@gmx.de> wrote:
>> I am just migrating the OSGi Installer HC (
>> https://github.com/apache/sling-org-apache-sling-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:
>> sets the snapshot instruction to the timestamp (
>> http://bnd.bndtools.org/instructions/snapshot.html). 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.