lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée (JIRA) <>
Subject [jira] Commented: (LUCENE-1344) Make the Lucene jar an OSGi bundle
Date Thu, 04 Sep 2008 16:17:44 GMT


Nicolas Lalevée commented on LUCENE-1344:

bq. Nicolas, does this mean we need to maintain the new META-INF/MANIFEST.MF, manually? Ie
on each release go edit it & bump up the versions in there? (We need to update the wiki
to this effect too)

in the META-INF/MANIFEST.MF, only the Export-Package header is important to maintain. The
other headers will never change or will be overrided by the build system. The other headers
are also there for the users (aka me) that have imported the Lucene source in Eclipse and
are willing to use it as an OSGi bundle.

bq. There are quite a few "copies" of version in there, and for example we have Bundle-Version: and then Specification-Version: 2.4.0-dev - is that right? (Ie, one uses "." and
the other uses "-").

About the different version schemes, yep, this is yet another one to maintain. The version
number taken into account in a OSGI environment is "Bundle-Version", I don't know what the
header "Specification-Version" is used for. I tried to refactor a little bit in the build
system to generate the version numbers, but I failed, a more bigger patch would be needed
(I am willing to do some if needed).

bq. I was able to generate a release candidate using your command above. What command would
be used to generate the actual release? (Ie, what to specify for version, spec.version and

It will be just about adding the OSGi version to the current used command line:

ant -Dversion=2.3.0 clean dist dist-src generate-maven-artifacts

bq. OK I'm a little confused by this. What does "cr1" mean?

it would mean "candidate release 1". Not very english but it is the best we found when [discussing
about it|]
for Ivy.

bq. And, while I can see the lexicographic sort order, your first case (2.3.0 < 2.3.0rc1)
seems backwards because 2.3.0rc1 ("release candidate 1") arrives before 2.3.0 (this is the
released 2.3.0 right?) in time, whereas in the 2nd case those releases are in time order.
I'm confused.

That was exactly my point. Due to the way OSGi orders the versions, if the release candicate
version number is 2.3.0.rc1, and the final version is, then OSGi will understand
that is previous to 2.3.0.rc1, which is wrong. In the second case, if the release
candidate number is 2.3.0.cr1, then OSGI will be right and will order the different Lucene
version as expected.
You could also choose 2.3.0.rc1 and 2.3.0.zfinal but then it is a question of taste :)

bq. Sorry for the silly questions - I know very little about OSGi bundles!

your questions are welcomed Michael ;)

> Make the Lucene jar an OSGi bundle
> ----------------------------------
>                 Key: LUCENE-1344
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Build
>            Reporter: Nicolas Lalevée
>             Fix For: 2.4
>         Attachments: LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, LUCENE-1344-r690691.patch,
> In order to use Lucene in an OSGi environment, some additional headers are needed in
the manifest of the jar. As Lucene has no dependency, it is pretty straight forward and it
ill be easy to maintain I think.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message