Mailing-List: contact dev-help@sling.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@sling.apache.org
Received-SPF: pass (athena.apache.org: domain of chetan.mehrotra@gmail.com
 designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
Date: Mon, 3 Feb 2014 10:39:45 +0530
Message-ID: 
 <CAHCW-m=tOj28=8j1nSZjgvuKbTBZd-Q+yjM5HzViMZKEUFH0eg@mail.gmail.com>
Subject: How to version packages exported from embedded bundles
From: Chetan Mehrotra <chetan.mehrotra@gmail.com>
To: dev <dev@sling.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I need some guidance around how to version packages which are exported
from embedded depedency. In case of Commons Log we are embedding
Logback jars. So far we were using version 1.0.13 and now we need to
switch to 1.1.0. However Logback (like most thirdparty jars) does not
follow OSGi semantic versioning guidelines and versions the packages
as per release number.

In most cases client of Commons Log would not have any API dependency
on the Logback unless they are providing custom Appenders

So far there has been no release of common log jar so we can safely
export the Logback packages at 1.1.0 version. But what should we do in
future

Some of the options I can think of

1. Do not export package with versions i.e. let it default to 0.0.0.
2. OR Keep a watch on changes and release it at versions which confirm
    to OSGi Semantic Versioning guidelines
3.  Similar to #2 above but we then export packages twice. One as per version
     stated in Logback jar and another at version which confirms to #2
4. OR Let it export at release version and expect the client bundles to have
   a more relaxed import range for versions

Similar issue exist with Slf4j also

Chetan Mehrotra