Mailing-List: contact api-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: api@directory.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: 
 <1429191438.1222075.254600081.55B7CB7B@webmail.messagingengine.com>
From: Benjamin Abernathy <ben@babernathy.net>
To: api@directory.apache.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: Request for slf4j import package in API bundles changes
Date: Thu, 16 Apr 2015 07:37:18 -0600
In-Reply-To: <552EDB77.3000204@stefan-seelmann.de>
References: <1428355583.368130.249955045.52BFA2EA@webmail.messagingengine.com>
 <55242F64.9070103@stefan-seelmann.de>
 <1428508865.981582.250821073.1F75FF03@webmail.messagingengine.com>
 <1428526642.1662155.250956749.5219E12B@webmail.messagingengine.com>
 <552E087C.2080604@stefan-seelmann.de>
 <552EDB77.3000204@stefan-seelmann.de>

Stefan,

That sounds like a really good idea. Thanks for doing that for me.

Ben

On Wed, Apr 15, 2015, at 03:43 PM, Stefan Seelmann wrote:
> On 04/15/2015 08:43 AM, Stefan Seelmann wrote:
> > On 04/08/2015 10:57 PM, Benjamin Abernathy wrote:
> >> Stefan,
> >>
> >> I think I have found a reasonable solution. I implemented it and it
> >> passes the integration tests as well as solves the problem I am
> >> experiencing in OSGi. Here is what I did.
> >>
> >> 1. I updated the parent pom by adding the following properties:
> >>
> >>     <slf4j.api.version.min>1.7</slf4j.api.version.min>
> >>     <slf4j.api.version.max>1.8</slf4j.api.version.max>
> >>
> >> 2. Then in each child pom that had an import declaration for org.slf4j,
> >> I changed the import statement from:
> >>
> >> org.slf4j;version=3D${slf4j.api.version},
> >>
> >> to:=20
> >>
> >> org.slf4j;version=3D"[${slf4j.api.version.min},${slf4j.api.version.max=
})",
> >>
> >>
> >> This approach has some drawbacks:
> >>
> >> 1. You now have three places that may need to be updated when the
> >> version of slf4j is updated.=20
> >> 2. BND (which is called by maven-bundle-plugin) is not the one deciding
> >> the what version should be used.
> >>
> >> Now, supposedly BND can choose a version range, but I could not get
> >> consistent behavior from the build using that approach.
> >=20
> > You mean the following? I tried to use BND range macro which magically
> > works:
> >=20
> >     org.slf4j;version=3D"$=ABrange;[=3D=3D,=3D+)=BB",
> >=20
> > The result in mainifest is then org.slf4j;version=3D"[1.7,1.8)"
> >=20
> > But I didn't find lot of documenation why it works. And the maven build
> > prints out a warning (but still it works):
> >=20
> > [INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @
> > api-ldap-model ---
> > [WARNING] Bundle
> > org.apache.directory.api:api-ldap-model:bundle:1.0.0-M30-SNAPSHOT : No
> > translation found for macro: range;[=3D=3D,=3D+), in
> >=20
>=20
> I think I finally found a good solution.
>=20
> In parent pom I added a property that defines the range macro
>=20
>   <slf4j.api.bundleversion>"$=ABrange;[=3D=3D,=3D+)=BB"</slf4j.api.bundle=
version>
>=20
> And in the actual poms the Import-Package instruction just looks like
> this
>=20
>   org.slf4j;version=3D${slf4j.api.bundleversion},
>=20
> So in case the macro magic makes problems we just have to change the
> property in parent pom. All tests (API, ApacheDS, Studio) work fine,
> I'll commit the changes tomorrow.
>=20
> Kind Regards,
> Stefan
>=20