[
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628370#action_12628370
]
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: 2.4.0.dev 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 bundle.version?).
It will be just about adding the OSGi version to the current used command line:
{noformat}
ant -Dversion=2.3.0 -Dbundle.version=2.3.0.final clean dist dist-src
generate-maven-artifacts
{noformat}
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|http://mail-archives.apache.org/mod_mbox/ant-dev/200808.mbox/[EMAIL
PROTECTED] 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
2.3.0.final, then OSGi will understand that 2.3.0.final 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: https://issues.apache.org/jira/browse/LUCENE-1344
> 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, MANIFEST.MF.diff
>
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
