Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.3, 4.0-ALPHA
    • Component/s: general/build
    • Labels:
      None

      Description

      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.

      1. MANIFEST.MF.diff
        1 kB
        Nicolas Lalevée
      2. LUCENE-1344-r696747.patch
        7 kB
        Nicolas Lalevée
      3. LUCENE-1344-r690691.patch
        6 kB
        Nicolas Lalevée
      4. LUCENE-1344-r690675.patch
        7 kB
        Nicolas Lalevée
      5. LUCENE-1344-r679133.patch
        7 kB
        Nicolas Lalevée
      6. LUCENE-1344-maven.patch
        1 kB
        Ryan McKinley
      7. LUCENE-1344-3.0-branch.patch
        2 kB
        Kirby Bohling
      8. LUCENE-1344.patch
        5 kB
        Gunnar Wagenknecht
      9. LUCENE-1344.patch
        11 kB
        Gunnar Wagenknecht
      10. LUCENE-1344.patch
        14 kB
        Gunnar Wagenknecht
      11. LUCENE-1344.patch
        14 kB
        Gunnar Wagenknecht
      12. LUCENE-1344.patch
        18 kB
        Gunnar Wagenknecht
      13. LUCENE-1344.patch
        31 kB
        Gunnar Wagenknecht
      14. lucene_trunk.patch
        1 kB
        Luca Stancapiano

        Activity

        Hide
        Nicolas Lalevée added a comment -

        Here is a patch against trunk.

        The patch on common-build.xml allows the core or every contrib to package the jar as an OSGi bundle. When building, it just need a property "bundle.manifest.file" which is pointing to the template MANIFEST.MF to use. The patch on build.xml with the MANIFEST.MF makes lucene core jar an OSGi bundle.

        Also in order to not have to maintain a third version scheme, I have added a /release target to compute the versions. So this doc should be updated :
        http://wiki.apache.org/lucene-java/ReleaseTodo

        ant -Dversion=2.3.0-rc1 -Dspec.version=2.3.0 clean dist dist-src generate-maven-artifacts

        should be replaced by:

        ant /release clean dist dist-src generate-maven-artifacts

        Then about maintenance, the version in the MANIFEST.MF file is just usefull for people having the Lucene source in Eclipse and usin it as an OSGi bundle. The version is actually overridden while building the jar. And every new java package that is part of the Lucene API have to be added to the Export-Package header.

        Show
        Nicolas Lalevée added a comment - Here is a patch against trunk. The patch on common-build.xml allows the core or every contrib to package the jar as an OSGi bundle. When building, it just need a property "bundle.manifest.file" which is pointing to the template MANIFEST.MF to use. The patch on build.xml with the MANIFEST.MF makes lucene core jar an OSGi bundle. Also in order to not have to maintain a third version scheme, I have added a /release target to compute the versions. So this doc should be updated : http://wiki.apache.org/lucene-java/ReleaseTodo ant -Dversion=2.3.0-rc1 -Dspec.version=2.3.0 clean dist dist-src generate-maven-artifacts should be replaced by: ant /release clean dist dist-src generate-maven-artifacts Then about maintenance, the version in the MANIFEST.MF file is just usefull for people having the Lucene source in Eclipse and usin it as an OSGi bundle. The version is actually overridden while building the jar. And every new java package that is part of the Lucene API have to be added to the Export-Package header.
        Hide
        Nicolas Lalevée added a comment -

        Updated patch, which fix the Bundle-RequiredExecutionEnvironment, and now the packages are exported with their version

        Show
        Nicolas Lalevée added a comment - Updated patch, which fix the Bundle-RequiredExecutionEnvironment, and now the packages are exported with their version
        Hide
        Michael McCandless added a comment -

        Should we do this for 2.4? Nicolas, there are quite a few changes to common-build.xml – do you see any risks/downsides to these changes?

        Show
        Michael McCandless added a comment - Should we do this for 2.4? Nicolas, there are quite a few changes to common-build.xml – do you see any risks/downsides to these changes?
        Hide
        Nicolas Lalevée added a comment -

        You are right to ask Michael, one part of the patch was risky, the part that was computing the version dynamically. I changed the way the properties were loaded and it made some mess with building the contrib during the release process.
        So I removed it. So then instead of

        ant -Dversion=2.3.0-rc1 -Dspec.version=2.3.0 clean dist dist-src generate-maven-artifacts
        

        there should be

        ant -Dversion=2.3.0-rc1 -Dspec.version=2.3.0 -Dbundle.version=2.3.0.cr1 clean dist dist-src generate-maven-artifacts
        

        Note that there is no spell mistake here. The OSGi specification expects that the qualifier part of the version (the last one) is incremented based on the lexical order. So 2.3.0 < 2.3.0.rc1. But 2.3.0.alpha1 < 2.3.0.beta1 < 2.3.0.beta2 < 2.3.0.cr1 < 2.3.0.final

        About the remaining patch, it is really just about adding additional fields into the manifest.mf, addition which is triggered by the existence of the bundle.manifest.file property. I attached the diff of the manifest of the core of a 2.4.0 release, between the trunk version and the patched one. And If I remove the property bundle.manifest.file from the build.xml, there is no diff at all (apart from the Implementation-Version because of the timestamp).

        Show
        Nicolas Lalevée added a comment - You are right to ask Michael, one part of the patch was risky, the part that was computing the version dynamically. I changed the way the properties were loaded and it made some mess with building the contrib during the release process. So I removed it. So then instead of ant -Dversion=2.3.0-rc1 -Dspec.version=2.3.0 clean dist dist-src generate-maven-artifacts there should be ant -Dversion=2.3.0-rc1 -Dspec.version=2.3.0 -Dbundle.version=2.3.0.cr1 clean dist dist-src generate-maven-artifacts Note that there is no spell mistake here. The OSGi specification expects that the qualifier part of the version (the last one) is incremented based on the lexical order. So 2.3.0 < 2.3.0.rc1. But 2.3.0.alpha1 < 2.3.0.beta1 < 2.3.0.beta2 < 2.3.0.cr1 < 2.3.0.final About the remaining patch, it is really just about adding additional fields into the manifest.mf, addition which is triggered by the existence of the bundle.manifest.file property. I attached the diff of the manifest of the core of a 2.4.0 release, between the trunk version and the patched one. And If I remove the property bundle.manifest.file from the build.xml, there is no diff at all (apart from the Implementation-Version because of the timestamp).
        Hide
        Michael McCandless added a comment -

        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)

        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
        "-").

        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?).

        So 2.3.0 < 2.3.0.rc1. But 2.3.0.alpha1 < 2.3.0.beta1 < 2.3.0.beta2 < 2.3.0.cr1 < 2.3.0.final

        OK I'm a little confused by this. What does "cr1" mean? 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.

        Sorry for the silly questions – I know very little about OSGi bundles!

        Show
        Michael McCandless added a comment - 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) 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 "-"). 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?). So 2.3.0 < 2.3.0.rc1. But 2.3.0.alpha1 < 2.3.0.beta1 < 2.3.0.beta2 < 2.3.0.cr1 < 2.3.0.final OK I'm a little confused by this. What does "cr1" mean? 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. Sorry for the silly questions – I know very little about OSGi bundles!
        Hide
        Nicolas Lalevée added a comment -

        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.

        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).

        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:

        ant -Dversion=2.3.0 -Dbundle.version=2.3.0.final clean dist dist-src generate-maven-artifacts
        

        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.

        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

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

        your questions are welcomed Michael

        Show
        Nicolas Lalevée added a comment - 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. 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). 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: ant -Dversion=2.3.0 -Dbundle.version=2.3.0.final clean dist dist-src generate-maven-artifacts 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. 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 Sorry for the silly questions - I know very little about OSGi bundles! your questions are welcomed Michael
        Hide
        Michael McCandless added a comment -

        Thanks Nicolas. I understand a bit more now

        One problem: even though I was able to successfully run the above command, the resulting MANIFEST.MF in the Lucene core JAR (dist/maven/org/apache/lucene/lucene-core/2.3.0/lucene-core-2.3.0.jar) does not have any of your added lines (eg Export-Package) – do you see this too?

        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).

        I think it's OK for now if we have to update the versions in META-INF/MANIFEST.MF manually as part of the release process? (It sounds hard to get the build to autogen the versions).

        Show
        Michael McCandless added a comment - Thanks Nicolas. I understand a bit more now One problem: even though I was able to successfully run the above command, the resulting MANIFEST.MF in the Lucene core JAR (dist/maven/org/apache/lucene/lucene-core/2.3.0/lucene-core-2.3.0.jar) does not have any of your added lines (eg Export-Package) – do you see this too? 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). I think it's OK for now if we have to update the versions in META-INF/MANIFEST.MF manually as part of the release process? (It sounds hard to get the build to autogen the versions).
        Hide
        Nicolas Lalevée added a comment -

        About the missing header in the maven jar, this is weird because they exist in every other jar in the distrib but in the maven one. And this is a lot more strange to see that the manifest of the lucene core jar is in fact the manifest of the demo one... And I retested without the patch, everything works correctly. I don't see yet how it can happen.

        And the META-INF/MANIFEST.MF file doesn't have to be updated when releasing. The build process is overriding the header entries. The file is mainly a template. See the build-bundle-manifest macro in the patch.
        But it will have to be updated after the release, just like the common-build.xml, to update the version number.

        Show
        Nicolas Lalevée added a comment - About the missing header in the maven jar, this is weird because they exist in every other jar in the distrib but in the maven one. And this is a lot more strange to see that the manifest of the lucene core jar is in fact the manifest of the demo one... And I retested without the patch, everything works correctly. I don't see yet how it can happen. And the META-INF/MANIFEST.MF file doesn't have to be updated when releasing. The build process is overriding the header entries. The file is mainly a template. See the build-bundle-manifest macro in the patch. But it will have to be updated after the release, just like the common-build.xml, to update the version number.
        Hide
        Michael McCandless added a comment -

        About the missing header in the maven jar, this is weird because they exist in every other jar in the distrib but in the maven one. And this is a lot more strange to see that the manifest of the lucene core jar is in fact the manifest of the demo one... And I retested without the patch, everything works correctly. I don't see yet how it can happen.

        Actually I can't find "Export-Package" header in any of the jars under dist/maven/* (at least, contrib/wordnet, contrib/highlighter and contrib/benchmark).

        I'll hold off committing until you figure this out

        Show
        Michael McCandless added a comment - About the missing header in the maven jar, this is weird because they exist in every other jar in the distrib but in the maven one. And this is a lot more strange to see that the manifest of the lucene core jar is in fact the manifest of the demo one... And I retested without the patch, everything works correctly. I don't see yet how it can happen. Actually I can't find "Export-Package" header in any of the jars under dist/maven/* (at least, contrib/wordnet, contrib/highlighter and contrib/benchmark). I'll hold off committing until you figure this out
        Hide
        Gunnar Wagenknecht added a comment -

        I would love to see bundle headers in the manifests.

        RE: {{

        {2.3.0 < 2.3.0.rc1}

        }}
        One way to handle this problem is byI using a timestamp as qualifier when generating the version number. This ensures that each new build is of a higher version. At Eclipse we use a ".qualifier" suffix which will be replaced with the actual CVS/SVN tag at build time. The CVS/SVN tag is actually a timestamp "v20080916-1020" or just an increasing number (eg., "v1, v2, v3..."). It depends on what a project favors. I could also imaging that this would be the SVN revision at build time.

        Show
        Gunnar Wagenknecht added a comment - I would love to see bundle headers in the manifests. RE: {{ {2.3.0 < 2.3.0.rc1} }} One way to handle this problem is byI using a timestamp as qualifier when generating the version number. This ensures that each new build is of a higher version. At Eclipse we use a ".qualifier" suffix which will be replaced with the actual CVS/SVN tag at build time. The CVS/SVN tag is actually a timestamp "v20080916-1020" or just an increasing number (eg., "v1, v2, v3..."). It depends on what a project favors. I could also imaging that this would be the SVN revision at build time.
        Hide
        Nicolas Lalevée added a comment - - edited

        This is a good idea as soon as you can be sure that you are building the different versions in the correct order. I think that in most use case, it will work. But it seems wrong to bind the versions order to the builds order.

        Show
        Nicolas Lalevée added a comment - - edited This is a good idea as soon as you can be sure that you are building the different versions in the correct order. I think that in most use case, it will work. But it seems wrong to bind the versions order to the builds order.
        Hide
        Gunnar Wagenknecht added a comment - - edited

        But it seems wrong to bind the versions order to the builds order.

        Not all the versions ... just those which appear to be of the same version (i.e., same tag or branch). If it's a different version, you would change the numbers before the qualifier. The qualifier really is just a build identifier. Giving it a meaning full name like .rc1 is a nice thing to have. But in reality this is hard to manage with automatic provisioning/update systems. They usually handle automatic updates to a higher build of the same version or a different build of a higher version fine.

        Show
        Gunnar Wagenknecht added a comment - - edited But it seems wrong to bind the versions order to the builds order. Not all the versions ... just those which appear to be of the same version (i.e., same tag or branch). If it's a different version, you would change the numbers before the qualifier. The qualifier really is just a build identifier. Giving it a meaning full name like .rc1 is a nice thing to have. But in reality this is hard to manage with automatic provisioning/update systems. They usually handle automatic updates to a higher build of the same version or a different build of a higher version fine.
        Hide
        Michael McCandless added a comment -

        Given the healthy discussion here, plus the fact that the current patch doesn't actually add Export-Package to the manifest, and this is the last bug holding up 2.4, I think we should take this off the plate for 2.4.

        Show
        Michael McCandless added a comment - Given the healthy discussion here, plus the fact that the current patch doesn't actually add Export-Package to the manifest, and this is the last bug holding up 2.4, I think we should take this off the plate for 2.4.
        Hide
        Gunnar Wagenknecht added a comment -

        Michael, when would be the last chance to submit a patch for inclusion into 2.4? I really, really need this because I'm about to embed Lucene into an OSGi based solution and this would really help.

        Show
        Gunnar Wagenknecht added a comment - Michael, when would be the last chance to submit a patch for inclusion into 2.4? I really, really need this because I'm about to embed Lucene into an OSGi based solution and this would really help.
        Hide
        Michael McCandless added a comment -

        The current plan is to branch tomorrow, freeze the branch for ~10 days, and then release 2.4. If we can get a patch that works here say in the next few days we might be able to get it into 2.4?

        If/when we do 2.4.1 we could probably backport this into that as well (since it's a small change).

        Show
        Michael McCandless added a comment - The current plan is to branch tomorrow, freeze the branch for ~10 days, and then release 2.4. If we can get a patch that works here say in the next few days we might be able to get it into 2.4? If/when we do 2.4.1 we could probably backport this into that as well (since it's a small change).
        Hide
        Gunnar Wagenknecht added a comment -

        Michael, attached is a patch which is less intrusive and mimics what Lucene does for Maven. It adds a new target to the build.xml called generate-osgi-bundles. This generated the OSGi bundles into dist/osgi (similar to maven). It uses Peter Kriens Bnd Tool to generate the bundle manifest. Thus, no additional work is involved for you guys.

        Please review and comment. Feel free to commit meanwhile. I'll continue to work on OSGi-ifing the other JARs as well. However, this is a bit more tricky because it requires a correct classpath setup and I haven't fully got into how you build contrib jars.

        Show
        Gunnar Wagenknecht added a comment - Michael, attached is a patch which is less intrusive and mimics what Lucene does for Maven. It adds a new target to the build.xml called generate-osgi-bundles . This generated the OSGi bundles into dist/osgi (similar to maven). It uses Peter Kriens Bnd Tool to generate the bundle manifest. Thus, no additional work is involved for you guys. Please review and comment. Feel free to commit meanwhile. I'll continue to work on OSGi-ifing the other JARs as well. However, this is a bit more tricky because it requires a correct classpath setup and I haven't fully got into how you build contrib jars.
        Hide
        Gunnar Wagenknecht added a comment -

        This patch replaces the previous one and implements building OSGi JARS for all contribution. It follows the Maven build, i.e. an OSGi jar will only be created if an osgi.bnd.template file exists. I included one for the analyzers. Others can be contributed individually.

        Show
        Gunnar Wagenknecht added a comment - This patch replaces the previous one and implements building OSGi JARS for all contribution. It follows the Maven build, i.e. an OSGi jar will only be created if an osgi.bnd.template file exists. I included one for the analyzers. Others can be contributed individually.
        Hide
        Michael McCandless added a comment -

        Thanks Gunnar; I'll try this today. What is the suggested ant command-line for building the dist now?

        Show
        Michael McCandless added a comment - Thanks Gunnar; I'll try this today. What is the suggested ant command-line for building the dist now?
        Hide
        Gunnar Wagenknecht added a comment -

        {{

        { ant -Dversion=2.4.0 clean dist dist-src generate-maven-artifacts generate-osgi-artifacts }

        }}

        It's important to note, that "spec.version" must always be major.minor.service (digits only). The qualifier is automatically computed based on the time stamp.

        Show
        Gunnar Wagenknecht added a comment - {{ { ant -Dversion=2.4.0 clean dist dist-src generate-maven-artifacts generate-osgi-artifacts } }} It's important to note, that "spec.version" must always be major.minor.service (digits only). The qualifier is automatically computed based on the time stamp.
        Hide
        Michael McCandless added a comment -

        Gunnar, when I apply the patch and run a toplevel "ant clean" followed by "ant test", I hit an error when trying to compile/test contrib/highlighter. Are you seeing this too?

        compile-highlighter:
             [echo] Building highlighter...
        
        build-memory:
             [echo] Highlighter building dependency /lucene/lucene.osgi/build/contrib/memory/lucene-memory-2.4-dev.jar
             [echo] Building memory...
        
        javacc-uptodate-check:
        
        javacc-notice:
        
        jflex-uptodate-check:
        
        jflex-notice:
        
        common.init:
        
        build-lucene:
        
        init:
        
        clover.setup:
        
        clover.info:
             [echo] 
             [echo]       Clover not found. Code coverage reports disabled.
             [echo]   	
        
        clover:
        
        compile-core:
            [mkdir] Created dir: /lucene/lucene.osgi/build/contrib/highlighter/classes/java
            [javac] Compiling 22 source files to /lucene/lucene.osgi/build/contrib/highlighter/classes/java
            [javac] /lucene/lucene.osgi/contrib/highlighter/src/java/org/apache/lucene/search/highlight/WeightedSpanTermExtractor.java˘:35: package org.apache.lucene.index.memory does not exist
            [javac] import org.apache.lucene.index.memory.MemoryIndex;
            [javac]                                      ^
            [javac] /lucene/lucene.osgi/contrib/highlighter/src/java/org/apache/lucene/search/highlight/WeightedSpanTermExtractor.java:312: cannot find symbol
            [javac] symbol  : class MemoryIndex
            [javac] location: class org.apache.lucene.search.highlight.WeightedSpanTermExtractor
            [javac]       MemoryIndex indexer = new MemoryIndex();
            [javac]       ^
            [javac] /lucene/lucene.osgi/contrib/highlighter/src/java/org/apache/lucene/search/highlight/WeightedSpanTermExtractor.java:312: cannot find symbol
            [javac] symbol  : class MemoryIndex
            [javac] location: class org.apache.lucene.search.highlight.WeightedSpanTermExtractor
            [javac]       MemoryIndex indexer = new MemoryIndex();
            [javac]                                 ^
            [javac] 3 errors
        
        BUILD FAILED
        /lucene/lucene.osgi/build.xml:562: The following error occurred while executing this line:
        /lucene/lucene.osgi/build.xml:552: The following error occurred while executing this line:
        /lucene/lucene.osgi/contrib/benchmark/build.xml:173: The following error occurred while executing this line:
        /lucene/lucene.osgi/contrib/highlighter/build.xml:41: The following error occurred while executing this line:
        /lucene/lucene.osgi/common-build.xml:229: The following error occurred while executing this line:
        /lucene/lucene.osgi/common-build.xml:505: Compile failed; see the compiler error output for details.
        
        Show
        Michael McCandless added a comment - Gunnar, when I apply the patch and run a toplevel "ant clean" followed by "ant test", I hit an error when trying to compile/test contrib/highlighter. Are you seeing this too? compile-highlighter: [echo] Building highlighter... build-memory: [echo] Highlighter building dependency /lucene/lucene.osgi/build/contrib/memory/lucene-memory-2.4-dev.jar [echo] Building memory... javacc-uptodate-check: javacc-notice: jflex-uptodate-check: jflex-notice: common.init: build-lucene: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: compile-core: [mkdir] Created dir: /lucene/lucene.osgi/build/contrib/highlighter/classes/java [javac] Compiling 22 source files to /lucene/lucene.osgi/build/contrib/highlighter/classes/java [javac] /lucene/lucene.osgi/contrib/highlighter/src/java/org/apache/lucene/search/highlight/WeightedSpanTermExtractor.java˘:35: package org.apache.lucene.index.memory does not exist [javac] import org.apache.lucene.index.memory.MemoryIndex; [javac] ^ [javac] /lucene/lucene.osgi/contrib/highlighter/src/java/org/apache/lucene/search/highlight/WeightedSpanTermExtractor.java:312: cannot find symbol [javac] symbol : class MemoryIndex [javac] location: class org.apache.lucene.search.highlight.WeightedSpanTermExtractor [javac] MemoryIndex indexer = new MemoryIndex(); [javac] ^ [javac] /lucene/lucene.osgi/contrib/highlighter/src/java/org/apache/lucene/search/highlight/WeightedSpanTermExtractor.java:312: cannot find symbol [javac] symbol : class MemoryIndex [javac] location: class org.apache.lucene.search.highlight.WeightedSpanTermExtractor [javac] MemoryIndex indexer = new MemoryIndex(); [javac] ^ [javac] 3 errors BUILD FAILED /lucene/lucene.osgi/build.xml:562: The following error occurred while executing this line: /lucene/lucene.osgi/build.xml:552: The following error occurred while executing this line: /lucene/lucene.osgi/contrib/benchmark/build.xml:173: The following error occurred while executing this line: /lucene/lucene.osgi/contrib/highlighter/build.xml:41: The following error occurred while executing this line: /lucene/lucene.osgi/common-build.xml:229: The following error occurred while executing this line: /lucene/lucene.osgi/common-build.xml:505: Compile failed; see the compiler error output for details.
        Hide
        Gunnar Wagenknecht added a comment -

        I haven't tried this sequence but it looks like a general compile error.

        Show
        Gunnar Wagenknecht added a comment - I haven't tried this sequence but it looks like a general compile error.
        Hide
        Michael McCandless added a comment -

        I haven't tried this sequence but it looks like a general compile error.

        Right, but a clean checkout runs fine, so it's something in the patch that somehow caused highlighter to no longer see the lucene-memory-2.4-dev.jar I think.

        Show
        Michael McCandless added a comment - I haven't tried this sequence but it looks like a general compile error. Right, but a clean checkout runs fine, so it's something in the patch that somehow caused highlighter to no longer see the lucene-memory-2.4-dev.jar I think.
        Hide
        Mark Miller added a comment -

        I think there is an unresolved issue with this anyway...I can't remember exactly, but I think one target that should work does not because it doesn't cooperate with the memory stuff (even though the overall build target does work). This may be another manifestation of that issue.

        Show
        Mark Miller added a comment - I think there is an unresolved issue with this anyway...I can't remember exactly, but I think one target that should work does not because it doesn't cooperate with the memory stuff (even though the overall build target does work). This may be another manifestation of that issue.
        Hide
        Michael McCandless added a comment -

        Hmm – if I revert this part of the patch:

        @@ -218,7 +225,7 @@
           <target name="compile-core" depends="init, clover"
                   description="Compiles core classes">
             <compile
        -      srcdir="src/java"
        +      srcdir="${src.dir}"
               destdir="${build.dir}/classes/java">
               <classpath refid="classpath"/>
             </compile>
        

        Then I'm able to "ant clean" and then "ant test" just fine. I don't yet understand why that fixes it, though.

        Show
        Michael McCandless added a comment - Hmm – if I revert this part of the patch: @@ -218,7 +225,7 @@ <target name= "compile-core" depends= "init, clover" description= "Compiles core classes" > <compile - srcdir= "src/java" + srcdir= "${src.dir}" destdir= "${build.dir}/classes/java" > <classpath refid= "classpath" /> </compile> Then I'm able to "ant clean" and then "ant test" just fine. I don't yet understand why that fixes it, though.
        Hide
        Gunnar Wagenknecht added a comment -

        Here is an updated patch which adds OSGi templates for highlighter and memory as well.

        I did a test using ant -Dversion=2.4.0 clean test dist dist-src generate-osgi-bundles. However, it fails because of some failing tests. I also noticed some OutOfMemoryErrors.

        If I just run ant -Dversion=2.4.0 clean generate-osgi-bundles it doesn't compile and quits with the error you mentioned. However, that's in the build file area which I didn't touch.

        Show
        Gunnar Wagenknecht added a comment - Here is an updated patch which adds OSGi templates for highlighter and memory as well. I did a test using ant -Dversion=2.4.0 clean test dist dist-src generate-osgi-bundles . However, it fails because of some failing tests. I also noticed some OutOfMemoryErrors. If I just run ant -Dversion=2.4.0 clean generate-osgi-bundles it doesn't compile and quits with the error you mentioned. However, that's in the build file area which I didn't touch.
        Hide
        Gunnar Wagenknecht added a comment -

        Ahh .. that makes sense. So it's caused by the patch. I changed it for consistency reasons but I guess it's better to revert that. It's related to how Ant resolves paths and overwrites/inherits properties.

        Show
        Gunnar Wagenknecht added a comment - Ahh .. that makes sense. So it's caused by the patch. I changed it for consistency reasons but I guess it's better to revert that. It's related to how Ant resolves paths and overwrites/inherits properties.
        Hide
        Gunnar Wagenknecht added a comment -

        Here is the latest patch which reverts that. Now it compiles fine after a clean.

        Show
        Gunnar Wagenknecht added a comment - Here is the latest patch which reverts that. Now it compiles fine after a clean.
        Hide
        Gunnar Wagenknecht added a comment -

        Michael, I solved the issue with {{$

        {src.dir}}}.

        The property is initially set the following way:
        { <property name="src.dir" location="src/java"/> }

        This resolves the path and sets the property to the actually path. It is then inherited to all sub ant calls. Thus, whenever you refer to {{${src.dir}

        }} it actually was already set to the outer most. Thus, when compile-core is invoked it actually compiles highlight instead of memory.

        If the property is defined the following way, it will resolve at reference time and not at definition time.
        {{

        { <property name="src.dir" value="src/java"/> }

        }}

        Show
        Gunnar Wagenknecht added a comment - Michael, I solved the issue with {{$ {src.dir}}}. The property is initially set the following way: { <property name="src.dir" location="src/java"/> } This resolves the path and sets the property to the actually path. It is then inherited to all sub ant calls. Thus, whenever you refer to {{${src.dir} }} it actually was already set to the outer most. Thus, when compile-core is invoked it actually compiles highlight instead of memory. If the property is defined the following way, it will resolve at reference time and not at definition time. {{ { <property name="src.dir" value="src/java"/> } }}
        Hide
        Michael McCandless added a comment -

        Super, I'll make that change locally and test.

        Show
        Michael McCandless added a comment - Super, I'll make that change locally and test.
        Hide
        Michael McCandless added a comment -

        OK I was able to generate the OSGI bundles. But, a few questions.

        Under dist/osgi I see these files:

        -rw-rw-rw-  1 mike  staff    5408 Sep 18 12:08 org.apache.lucene.core_2.4.0.200809181201.jar
        -rw-rw-rw-  1 mike  staff  770986 Sep 18 12:08 org.apache.lucene.core.source_2.4.0.200809181201.jar
        -rw-rw-rw-  1 mike  staff    5412 Sep 18 12:08 org.apache.lucene.analyzers_2.4.0.200809181208.jar
        -rw-rw-rw-  1 mike  staff  431926 Sep 18 12:08 org.apache.lucene.analyzers.source_2.4.0.200809181208.jar
        -rw-rw-rw-  1 mike  staff    5410 Sep 18 12:08 org.apache.lucene.memory_2.4.0.200809181208.jar
        -rw-rw-rw-  1 mike  staff   37197 Sep 18 12:08 org.apache.lucene.memory.source_2.4.0.200809181208.jar
        -rw-rw-rw-  1 mike  staff    5414 Sep 18 12:08 org.apache.lucene.highlighter_2.4.0.200809181208.jar
        -rw-rw-rw-  1 mike  staff   45676 Sep 18 12:08 org.apache.lucene.highlighter.source_2.4.0.200809181208.jar
        

        Shouldn't we make OSGI bundles for all contrib packages, and core & demo?

        The source jar actually has .java sources, but the binary jars only have META-INF subdir, eg org.apache.lucene.core_2.4.0.200809181201.jar unzips to:

        Archive:  dist/osgi/org.apache.lucene.core_2.4.0.200809181201.jar
          inflating: META-INF/MANIFEST.MF    
          inflating: META-INF/LICENSE.txt    
          inflating: META-INF/NOTICE.txt     
        

        Is that right? Shouldn't this jar have the .class files?

        At a higher level, can't we have the normal JARs produced by the build simply include the necessary OSGI headers in the manifest? (Why make new JARs?).

        Finally, during the release process, what should we do with the OSGI bundles? EG the Maven artifacts are copied to a distribution directory so that they are pushed to the central Maven repositories.

        Show
        Michael McCandless added a comment - OK I was able to generate the OSGI bundles. But, a few questions. Under dist/osgi I see these files: -rw-rw-rw- 1 mike staff 5408 Sep 18 12:08 org.apache.lucene.core_2.4.0.200809181201.jar -rw-rw-rw- 1 mike staff 770986 Sep 18 12:08 org.apache.lucene.core.source_2.4.0.200809181201.jar -rw-rw-rw- 1 mike staff 5412 Sep 18 12:08 org.apache.lucene.analyzers_2.4.0.200809181208.jar -rw-rw-rw- 1 mike staff 431926 Sep 18 12:08 org.apache.lucene.analyzers.source_2.4.0.200809181208.jar -rw-rw-rw- 1 mike staff 5410 Sep 18 12:08 org.apache.lucene.memory_2.4.0.200809181208.jar -rw-rw-rw- 1 mike staff 37197 Sep 18 12:08 org.apache.lucene.memory.source_2.4.0.200809181208.jar -rw-rw-rw- 1 mike staff 5414 Sep 18 12:08 org.apache.lucene.highlighter_2.4.0.200809181208.jar -rw-rw-rw- 1 mike staff 45676 Sep 18 12:08 org.apache.lucene.highlighter.source_2.4.0.200809181208.jar Shouldn't we make OSGI bundles for all contrib packages, and core & demo? The source jar actually has .java sources, but the binary jars only have META-INF subdir, eg org.apache.lucene.core_2.4.0.200809181201.jar unzips to: Archive: dist/osgi/org.apache.lucene.core_2.4.0.200809181201.jar inflating: META-INF/MANIFEST.MF inflating: META-INF/LICENSE.txt inflating: META-INF/NOTICE.txt Is that right? Shouldn't this jar have the .class files? At a higher level, can't we have the normal JARs produced by the build simply include the necessary OSGI headers in the manifest? (Why make new JARs?). Finally, during the release process, what should we do with the OSGI bundles? EG the Maven artifacts are copied to a distribution directory so that they are pushed to the central Maven repositories.
        Hide
        Michael McCandless added a comment -

        One more confusion on my part. The manifest for the core source jar (org.apache.lucene.core.source_2.4.0.200809181201.jar) is this:

        Manifest-Version: 1.0
        Ant-Version: Apache Ant 1.7.0
        Created-By: 1.6.0_05-b13-52 (Apple Inc.)
        Bundle-SymbolicName: org.apache.lucene.core.source
        Bundle-ManifestVersion: 2
        Bundle-Name: Lucene Search Engine: core source
        Bundle-Version: 2.4.0.200809181201
        Eclipse-SourceBundle: org.apache.lucene.core;version="2.4.0.2008091812
         01"
        Bundle-Vendor: The Apache Software Foundation
        Specification-Title: Lucene Search Engine: core
        Specification-Version: 2.4.0
        Specification-Vendor: The Apache Software Foundation
        Implementation-Title: org.apache.lucene
        Implementation-Version: 2.4.0 696661M - 2008-09-18 12:01:47
        Implementation-Vendor: The Apache Software Foundation
        X-Compile-Source-JDK: 1.4
        X-Compile-Target-JDK: 1.4
        

        (Note the newline inside the timestamp on the Eclipse-SourceBundle – is that OK?).

        Whereas the manifest for the binary jar (org.apache.lucene.core_2.4.0.200809181201.jar) is much smaller:

        Manifest-Version: 1.0
        Bundle-Vendor: The Apache Software Foundation
        Bundle-Version: 2.4.0.200809181201
        Bundle-Name: Lucene Search Engine: core
        Bundle-ManifestVersion: 2
        Bundle-License: http://www.apache.org/licenses/LICENSE-2.0
        Bundle-SymbolicName: org.apache.lucene.core
        Bundle-RequiredExecutionEnvironment: J2SE-1.5,J2SE-1.4
        

        Is that expected? And the manifest for the source jar is missing at least Bundle-License?

        Show
        Michael McCandless added a comment - One more confusion on my part. The manifest for the core source jar (org.apache.lucene.core.source_2.4.0.200809181201.jar) is this: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 1.6.0_05-b13-52 (Apple Inc.) Bundle-SymbolicName: org.apache.lucene.core.source Bundle-ManifestVersion: 2 Bundle-Name: Lucene Search Engine: core source Bundle-Version: 2.4.0.200809181201 Eclipse-SourceBundle: org.apache.lucene.core;version="2.4.0.2008091812 01" Bundle-Vendor: The Apache Software Foundation Specification-Title: Lucene Search Engine: core Specification-Version: 2.4.0 Specification-Vendor: The Apache Software Foundation Implementation-Title: org.apache.lucene Implementation-Version: 2.4.0 696661M - 2008-09-18 12:01:47 Implementation-Vendor: The Apache Software Foundation X-Compile-Source-JDK: 1.4 X-Compile-Target-JDK: 1.4 (Note the newline inside the timestamp on the Eclipse-SourceBundle – is that OK?). Whereas the manifest for the binary jar (org.apache.lucene.core_2.4.0.200809181201.jar) is much smaller: Manifest-Version: 1.0 Bundle-Vendor: The Apache Software Foundation Bundle-Version: 2.4.0.200809181201 Bundle-Name: Lucene Search Engine: core Bundle-ManifestVersion: 2 Bundle-License: http: //www.apache.org/licenses/LICENSE-2.0 Bundle-SymbolicName: org.apache.lucene.core Bundle-RequiredExecutionEnvironment: J2SE-1.5,J2SE-1.4 Is that expected? And the manifest for the source jar is missing at least Bundle-License?
        Hide
        Nicolas Lalevée added a comment -

        I have fixed my patch so the maven jar does contain the OSGi manifest, even if I don't understand really why the jar are generated twice.
        This new patch contains improvements.

        • as suggested by Gunnar, the bundle version will be 2.9.0.$TIMESTAMP-dev.
        • the version of the export package in the header are now controlled by the ant task

        So the command to build a rc version will be:

        ant -Dspec.version=2.4.0 -Dqualifier.version=rc1 clean dist dist-src generate-maven-artifacts

        will generate:

        • a lucene-core-2.4.0-rc1.jar
        • a lucene-core-2.4.0-rc1.zip
        • a maven artifact in org/apache/lucene/lucene-core/2.4.0-rc1/lucene-core-2.4.0-rc1.jar
        • the jars will contain the bundle version: 2.4.0.20080918220130-rc1

        For a final version:

        ant -Dspec.version=2.4.0 -Dqualifier.version=final clean dist dist-src generate-maven-artifacts

        will generate:

        • a lucene-core-2.4.0-final.jar
        • a lucene-core-2.4.0-final.zip
        • a maven artifact in org/apache/lucene/lucene-core/2.4.0-final/lucene-core-2.4.0-final.jar
        • the jars will contain the bundle version: 2.4.0.20080918220130-final

        I know that Lucene distrib used to not add qualifier to the final release, it can still be done with:

        ant -Dspec.version=2.4.0 -Dqualifier.version=final -Dversion=2.4.0 clean dist dist-src generate-maven-artifacts

        will generate:

        • a lucene-core-2.4.0.jar
        • a lucene-core-2.4.0.zip
        • a maven artifact in org/apache/lucene/lucene-core/2.4.0/lucene-core-2.4.0.jar
        • the jars will contain the bundle version: 2.4.0.20080918220130-final
        Show
        Nicolas Lalevée added a comment - I have fixed my patch so the maven jar does contain the OSGi manifest, even if I don't understand really why the jar are generated twice. This new patch contains improvements. as suggested by Gunnar, the bundle version will be 2.9.0.$TIMESTAMP-dev. the version of the export package in the header are now controlled by the ant task So the command to build a rc version will be: ant -Dspec.version=2.4.0 -Dqualifier.version=rc1 clean dist dist-src generate-maven-artifacts will generate: a lucene-core-2.4.0-rc1.jar a lucene-core-2.4.0-rc1.zip a maven artifact in org/apache/lucene/lucene-core/2.4.0-rc1/lucene-core-2.4.0-rc1.jar the jars will contain the bundle version: 2.4.0.20080918220130-rc1 For a final version: ant -Dspec.version=2.4.0 -Dqualifier.version=final clean dist dist-src generate-maven-artifacts will generate: a lucene-core-2.4.0-final.jar a lucene-core-2.4.0-final.zip a maven artifact in org/apache/lucene/lucene-core/2.4.0-final/lucene-core-2.4.0-final.jar the jars will contain the bundle version: 2.4.0.20080918220130-final I know that Lucene distrib used to not add qualifier to the final release, it can still be done with: ant -Dspec.version=2.4.0 -Dqualifier.version=final -Dversion=2.4.0 clean dist dist-src generate-maven-artifacts will generate: a lucene-core-2.4.0.jar a lucene-core-2.4.0.zip a maven artifact in org/apache/lucene/lucene-core/2.4.0/lucene-core-2.4.0.jar the jars will contain the bundle version: 2.4.0.20080918220130-final
        Hide
        Gunnar Wagenknecht added a comment -

        Michael, the attached patch adds the bundle license header for the source bundles. I also started to add descriptors for two more contrib jars (queries and xml parser). It gets a bit messy now because of split-packages, i.e. the queries jar exports the same package (org.apache.lucene.search) as Lucene core. This requires to add split packages headers to the manifests. Additional, the "-" (dash) is invalid so I had to override the default bundle symbolic name for the xml-query-parser jar. I use the package name.

        The OSGi JARs don't need to be uploaded somewhere. It's enough to just put them on the FTP mirrors next to the regular distribution.

        Nicholas, we generate different JARs for OSGi because I don't like to mix and match things. OSGi should be separated from Maven. They are different. For example, in OSGi it's a good practice to name the JAR like the bundle symbolic name and to include the version. Otherwise you'll run into problems because bundle repositories are usually not hierarchically organized like Maven repos.

        Michael, do we need a "-final" or "-dev" indicator on the JAR names and bundle versions?

        Show
        Gunnar Wagenknecht added a comment - Michael, the attached patch adds the bundle license header for the source bundles. I also started to add descriptors for two more contrib jars (queries and xml parser). It gets a bit messy now because of split-packages, i.e. the queries jar exports the same package (org.apache.lucene.search) as Lucene core. This requires to add split packages headers to the manifests. Additional, the "-" (dash) is invalid so I had to override the default bundle symbolic name for the xml-query-parser jar. I use the package name. The OSGi JARs don't need to be uploaded somewhere. It's enough to just put them on the FTP mirrors next to the regular distribution. Nicholas, we generate different JARs for OSGi because I don't like to mix and match things. OSGi should be separated from Maven. They are different. For example, in OSGi it's a good practice to name the JAR like the bundle symbolic name and to include the version. Otherwise you'll run into problems because bundle repositories are usually not hierarchically organized like Maven repos. Michael, do we need a "-final" or "-dev" indicator on the JAR names and bundle versions?
        Hide
        Nicolas Lalevée added a comment -

        Nicholas, we generate different JARs for OSGi because I don't like to mix and match things. OSGi should be separated from Maven.

        Maven is about building and resolving dependencies, OSGi is about a running environement. And they can be mixed with no worry, it even exists a maven plugin to handle OSGi headers, and a maven repository full of OSGi bundles.

        They are different. For example, in OSGi it's a good practice to name the JAR like the bundle symbolic name and to include the version. Otherwise you'll run into problems because bundle repositories are usually not hierarchically organized like Maven repos.

        I don't think the purpose here is to make Lucene have its own OSGi repository. And nothing here prevents you to build a pure OSGi repository with those jars with the name convention you like.

        Show
        Nicolas Lalevée added a comment - Nicholas, we generate different JARs for OSGi because I don't like to mix and match things. OSGi should be separated from Maven. Maven is about building and resolving dependencies, OSGi is about a running environement. And they can be mixed with no worry, it even exists a maven plugin to handle OSGi headers, and a maven repository full of OSGi bundles. They are different. For example, in OSGi it's a good practice to name the JAR like the bundle symbolic name and to include the version. Otherwise you'll run into problems because bundle repositories are usually not hierarchically organized like Maven repos. I don't think the purpose here is to make Lucene have its own OSGi repository. And nothing here prevents you to build a pure OSGi repository with those jars with the name convention you like.
        Hide
        Gunnar Wagenknecht added a comment -

        I've updated the patch to include more descriptors for other contrib jars. Should be complete now (except for the ant libs, benchmarks and bdb which can be added later if necessary).

        It's also possible to set the OSGi qualifier using property osgi.version.qualifier. The default is .yyyyMMddHHmm

        Show
        Gunnar Wagenknecht added a comment - I've updated the patch to include more descriptors for other contrib jars. Should be complete now (except for the ant libs, benchmarks and bdb which can be added later if necessary). It's also possible to set the OSGi qualifier using property osgi.version.qualifier . The default is .yyyyMMddHHmm
        Hide
        Michael McCandless added a comment -

        Thanks Gunnar.

        Can you and Nicolas work together to reconcile your two different patches here? I really know very little about the specifics involved here and am involved more or less as a "catalyst" to try to move things along... thanks.

        Show
        Michael McCandless added a comment - Thanks Gunnar. Can you and Nicolas work together to reconcile your two different patches here? I really know very little about the specifics involved here and am involved more or less as a "catalyst" to try to move things along... thanks.
        Hide
        Gunnar Wagenknecht added a comment -

        I'll collect feedback on the developers list on what way they prefer.

        Show
        Gunnar Wagenknecht added a comment - I'll collect feedback on the developers list on what way they prefer.
        Hide
        Enrico Schnepel added a comment -

        Is there any progress on this issue?

        Show
        Enrico Schnepel added a comment - Is there any progress on this issue?
        Hide
        Kirby Bohling added a comment -

        Attaching a patch that generates a sibling jar file (hopefully it will replace the original Jar files before it is actually committed) that includes all of the OSGi Manifest requirements.

        All the regular unit tests appear to pass if I use the OSGi bundles instead of the standard jar files (by removing the <jar> task in the <jarify> macro defined in commons-build.xml, and modifying the <bnd> task to use output="@

        {destfile}

        ". The backward compat tests appear to fail, but I haven't gotten to the bottom of that just yet.

        It requires that the biz.aQute.bnd.jar be in the lib/ directory.

        From this site:
        http://www.aqute.biz/Bnd/Download

        I grabbed it off of this link:
        http://dl.dropbox.com/u/2590603/bnd/biz.aQute.bnd.jar

        The bnd jar is a standard tool for generating valid and up-to-date OSGi headers with minimal problems.

        I downloaded the commons-math jar file to see the set of headers the commons projects added to their bundles.

        I have not tested any of the contrib bundles in an OSGi environment, but I am using the Lucene Core bundle generated by this. It is also likely that the $

        {Name}

        value should be set in all of the sub-directories to generate better human consumable names for the bundles, currently they are all set to "Lucene". Potentially a better description would be useful also. I believe a couple will have problems (lucli being the most obvious because it isn't in the org.apache.lucene package structure). I can do more testing and ensure as much as I can works if this patch would be applied.

        I can port and update this to the 4.0 branch if desirable, and it should be simple to modify to just generate the final Jar files.

        Show
        Kirby Bohling added a comment - Attaching a patch that generates a sibling jar file (hopefully it will replace the original Jar files before it is actually committed) that includes all of the OSGi Manifest requirements. All the regular unit tests appear to pass if I use the OSGi bundles instead of the standard jar files (by removing the <jar> task in the <jarify> macro defined in commons-build.xml, and modifying the <bnd> task to use output="@ {destfile} ". The backward compat tests appear to fail, but I haven't gotten to the bottom of that just yet. It requires that the biz.aQute.bnd.jar be in the lib/ directory. From this site: http://www.aqute.biz/Bnd/Download I grabbed it off of this link: http://dl.dropbox.com/u/2590603/bnd/biz.aQute.bnd.jar The bnd jar is a standard tool for generating valid and up-to-date OSGi headers with minimal problems. I downloaded the commons-math jar file to see the set of headers the commons projects added to their bundles. I have not tested any of the contrib bundles in an OSGi environment, but I am using the Lucene Core bundle generated by this. It is also likely that the $ {Name} value should be set in all of the sub-directories to generate better human consumable names for the bundles, currently they are all set to "Lucene". Potentially a better description would be useful also. I believe a couple will have problems (lucli being the most obvious because it isn't in the org.apache.lucene package structure). I can do more testing and ensure as much as I can works if this patch would be applied. I can port and update this to the 4.0 branch if desirable, and it should be simple to modify to just generate the final Jar files.
        Hide
        Luca Stancapiano added a comment -

        I'm interested to this feauture too. Is it committed?

        Show
        Luca Stancapiano added a comment - I'm interested to this feauture too. Is it committed?
        Hide
        Ryan McKinley added a comment -

        I have not followed this patch and don't know how it works... but this may be pretty easy to add to the (officially unsupported) maven build:

                  <plugin>
                      <groupId>org.apache.felix</groupId>
                      <artifactId>maven-bundle-plugin</artifactId>
                      <version>1.4.0</version>
                      <extensions>true</extensions>
                      <configuration>
                          <instructions>
                              <Bundle-SymbolicName>${pom.groupId}.${pom.artifactId}</Bundle-SymbolicName>
                              <Bundle-Name>${pom.name}</Bundle-Name>
                              <Bundle-Version>${pom.version}</Bundle-Version>
                              <Bundle-Activator>org.wso2.mbp.sample01.Activator</Bundle-Activator>
                              <Private-Package>org.wso2.mbp.sample01</Private-Package>
                          </instructions>
                      </configuration>
                  </plugin>
        

        http://wso2.org/library/tutorials/develop-osgi-bundles-using-maven-bundle-plugin

        Show
        Ryan McKinley added a comment - I have not followed this patch and don't know how it works... but this may be pretty easy to add to the (officially unsupported) maven build: <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>1.4.0</version> <extensions> true </extensions> <configuration> <instructions> <Bundle-SymbolicName>${pom.groupId}.${pom.artifactId}</Bundle-SymbolicName> <Bundle-Name>${pom.name}</Bundle-Name> <Bundle-Version>${pom.version}</Bundle-Version> <Bundle-Activator>org.wso2.mbp.sample01.Activator</Bundle-Activator> <Private-Package>org.wso2.mbp.sample01</Private-Package> </instructions> </configuration> </plugin> http://wso2.org/library/tutorials/develop-osgi-bundles-using-maven-bundle-plugin
        Hide
        Daniele added a comment -

        The solution is almost that one, just a few corrections:

        <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <version>2.3.4</version>
        <extensions>true</extensions>
        <configuration>
        <instructions>
        <Bundle-SymbolicName>$

        {project.groupId}

        .$

        {project.artifactId}

        </Bundle-SymbolicName>
        <Bundle-Name>$

        {project.name}

        </Bundle-Name>
        <Bundle-Version>$

        {project.version}

        </Bundle-Version>
        </instructions>
        </configuration>
        </plugin>

        I'd also add a executions block (direct child of the plugin block)

        <executions>
        <execution>
        <id>bundle-manifest</id>
        <phase>process-classes</phase>
        <goals>
        <goal>manifest</goal>
        </goals>
        </execution>
        </executions>

        so that is not needed to change the packaging type to bundle to make the MANIFEST information to be attached.

        Show
        Daniele added a comment - The solution is almost that one, just a few corrections: <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>2.3.4</version> <extensions>true</extensions> <configuration> <instructions> <Bundle-SymbolicName>$ {project.groupId} .$ {project.artifactId} </Bundle-SymbolicName> <Bundle-Name>$ {project.name} </Bundle-Name> <Bundle-Version>$ {project.version} </Bundle-Version> </instructions> </configuration> </plugin> I'd also add a executions block (direct child of the plugin block) <executions> <execution> <id>bundle-manifest</id> <phase>process-classes</phase> <goals> <goal>manifest</goal> </goals> </execution> </executions> so that is not needed to change the packaging type to bundle to make the MANIFEST information to be attached.
        Hide
        Ryan McKinley added a comment -

        Thanks Daniele – can you make a patch for this?

        I don't use OSGi so I have no idea if the results are valid or not, but would happily commit changes to the maven poms if someone verifies the changes work.

        Show
        Ryan McKinley added a comment - Thanks Daniele – can you make a patch for this? I don't use OSGi so I have no idea if the results are valid or not, but would happily commit changes to the maven poms if someone verifies the changes work.
        Hide
        Luca Stancapiano added a comment -

        I don't see maven in the lucene sources. It is built with ant. The first solution seems ok....why it was not committed?

        Show
        Luca Stancapiano added a comment - I don't see maven in the lucene sources. It is built with ant. The first solution seems ok....why it was not committed?
        Hide
        Ryan McKinley added a comment -

        Hi Luca – maven support is in the dev-tools folder:
        https://svn.apache.org/repos/asf/lucene/dev/trunk/dev-tools/maven

        My understanding is that OSGi needs to know about the dependencies – i don't know how (or if) our ant build can support that.

        Show
        Ryan McKinley added a comment - Hi Luca – maven support is in the dev-tools folder: https://svn.apache.org/repos/asf/lucene/dev/trunk/dev-tools/maven My understanding is that OSGi needs to know about the dependencies – i don't know how (or if) our ant build can support that.
        Hide
        Daniele added a comment -

        oh, well, the maven plugin just automatically generates the Manifest.mf information bases on the actual code base. It works nice but is not the only solution.
        You can run http://bndtools.org/ against the jar to make a new jar with correct Manifest OSGi instructions, that's what I did to make the 3.1.0 release work on an OSGi environment. I think you can also integrate bnd with an ant script.
        Or you can just keep the source Manifest file up to date, but you have to keep exported packages (and version) aligned manually.

        In the end is just a matter of releasing a jar with a few more meta information in the standard Manifest.MF file, nothing more.

        Show
        Daniele added a comment - oh, well, the maven plugin just automatically generates the Manifest.mf information bases on the actual code base. It works nice but is not the only solution. You can run http://bndtools.org/ against the jar to make a new jar with correct Manifest OSGi instructions, that's what I did to make the 3.1.0 release work on an OSGi environment. I think you can also integrate bnd with an ant script. Or you can just keep the source Manifest file up to date, but you have to keep exported packages (and version) aligned manually. In the end is just a matter of releasing a jar with a few more meta information in the standard Manifest.MF file, nothing more.
        Hide
        Ryan Hill added a comment -

        The bndtools approach works for me – I believe that is that the Jackson (JSON) project does as well.

        Show
        Ryan Hill added a comment - The bndtools approach works for me – I believe that is that the Jackson (JSON) project does as well.
        Hide
        Luca Stancapiano added a comment -

        Ok ....I created a patch according the pom configuration seen before. It creates osgi bundles for lucene-core and the other modules. I tested them inside felix and they are installed correctly. There are not mainteinance problems because the packages are generated dinamically by the maven-bundle-plugin configured in this patch

        Show
        Luca Stancapiano added a comment - Ok ....I created a patch according the pom configuration seen before. It creates osgi bundles for lucene-core and the other modules. I tested them inside felix and they are installed correctly. There are not mainteinance problems because the packages are generated dinamically by the maven-bundle-plugin configured in this patch
        Hide
        Ryan McKinley added a comment -

        Thanks Luca!

        When you upload a patch, can you click the "Grant license to ASF for inclusion in ASF works" button? It seems a little silly for this small patch, but that is ASF policy.

        thanks

        Show
        Ryan McKinley added a comment - Thanks Luca! When you upload a patch, can you click the "Grant license to ASF for inclusion in ASF works" button? It seems a little silly for this small patch, but that is ASF policy. thanks
        Hide
        Ryan McKinley added a comment -

        This is the same patch, but moved to the lucene parent pom – this way it applies to all artifacts rather then just the lucene core.jar

        The output manifest now looks like:

        Manifest-Version: 1.0
        Archiver-Version: Plexus Archiver
        Created-By: Apache Maven Bundle Plugin
        Built-By: ryan
        Build-Jdk: 1.6.0_13
        Implementation-Vendor-Id: org.apache.lucene
        Extension-Name: org.apache.lucene
        Implementation-Title: org.apache.lucene
        Implementation-Vendor: The Apache Software Foundation
        Implementation-Version: 4.0-SNAPSHOT 1130132 - ryan - 2011-06-01 09:12
         :35
        Specification-Title: Lucene Core
        Specification-Vendor: The Apache Software Foundation
        Specification-Version: 4.0.0.2011.06.01.09.12.35
        X-Compile-Source-JDK: 1.5
        X-Compile-Target-JDK: 1.5
        Export-Package: org.apache.lucene.analysis;uses:="org.apache.lucene.ut
         il,org.apache.lucene.store,org.apache.lucene.document,org.apache.luce
         ne.analysis.tokenattributes,org.apache.lucene.index",org.apache.lucen
         e.analysis.tokenattributes;uses:="org.apache.lucene.util,org.apache.l
         ucene.index",org.apache.lucene.document;uses:="org.apache.lucene.util
         ,org.apache.lucene.analysis",org.apache.lucene.index;uses:="org.apach
         e.lucene.search,org.apache.lucene.util,org.apache.lucene.store,org.ap
         ache.lucene.document,org.apache.lucene.index.codecs,org.apache.lucene
         .analysis.tokenattributes,org.apache.lucene.analysis",org.apache.luce
         ne.index.codecs;uses:="org.apache.lucene.index,org.apache.lucene.util
         ,org.apache.lucene.store,org.apache.lucene.index.codecs.standard,org.
         apache.lucene.index.codecs.pulsing,org.apache.lucene.index.codecs.sim
         pletext,org.apache.lucene.index.codecs.preflex,org.apache.lucene.util
         .packed,org.apache.lucene.util.fst",org.apache.lucene.index.codecs.in
         tblock;uses:="org.apache.lucene.store,org.apache.lucene.index.codecs.
         sep,org.apache.lucene.util",org.apache.lucene.index.codecs.preflex;us
         es:="org.apache.lucene.store,org.apache.lucene.index.codecs,org.apach
         e.lucene.index,org.apache.lucene.util,org.apache.lucene.index.codecs.
         standard",org.apache.lucene.index.codecs.pulsing;uses:="org.apache.lu
         cene.index.codecs.standard,org.apache.lucene.util,org.apache.lucene.s
         tore,org.apache.lucene.index.codecs,org.apache.lucene.index",org.apac
         he.lucene.index.codecs.sep;uses:="org.apache.lucene.store,org.apache.
         lucene.util,org.apache.lucene.index,org.apache.lucene.index.codecs",o
         rg.apache.lucene.index.codecs.simpletext;uses:="org.apache.lucene.sto
         re,org.apache.lucene.index.codecs,org.apache.lucene.index,org.apache.
         lucene.util,org.apache.lucene.util.fst",org.apache.lucene.index.codec
         s.standard;uses:="org.apache.lucene.store,org.apache.lucene.index.cod
         ecs,org.apache.lucene.index,org.apache.lucene.util",org.apache.lucene
         ,org.apache.lucene.messages,org.apache.lucene.queryParser;uses:="org.
         apache.lucene.util,org.apache.lucene.search,org.apache.lucene.analysi
         s,org.apache.lucene.analysis.tokenattributes,org.apache.lucene.docume
         nt,org.apache.lucene.index",org.apache.lucene.search;uses:="org.apach
         e.lucene.util,org.apache.lucene.util.automaton,org.apache.lucene.inde
         x,org.apache.lucene.util.packed,org.apache.lucene.search.cache,org.ap
         ache.lucene.store,org.apache.lucene.document,org.apache.lucene.analys
         is.tokenattributes,org.apache.lucene.analysis,org.apache.lucene.searc
         h.spans",org.apache.lucene.search.cache;uses:="org.apache.lucene.util
         ,org.apache.lucene.search,org.apache.lucene.index,org.apache.lucene.u
         til.packed",org.apache.lucene.search.function;uses:="org.apache.lucen
         e.search,org.apache.lucene.index,org.apache.lucene.util",org.apache.l
         ucene.search.payloads;uses:="org.apache.lucene.search,org.apache.luce
         ne.search.spans,org.apache.lucene.index,org.apache.lucene.util",org.a
         pache.lucene.search.spans;uses:="org.apache.lucene.util,org.apache.lu
         cene.search,org.apache.lucene.index",org.apache.lucene.store;uses:="o
         rg.apache.lucene.util",org.apache.lucene.util;uses:="org.apache.lucen
         e.store,org.apache.lucene.index,org.apache.lucene,org.apache.lucene.s
         earch",org.apache.lucene.util.automaton;uses:="org.apache.lucene.util
         ",org.apache.lucene.util.fst;uses:="org.apache.lucene.util,org.apache
         .lucene.store",org.apache.lucene.util.packed;uses:="org.apache.lucene
         .util,org.apache.lucene.store"
        Tool: Bnd-1.15.0
        Bundle-Name: Lucene Core
        Bundle-Vendor: The Apache Software Foundation
        Bundle-Version: 4.0.0.SNAPSHOT
        Bnd-LastModified: 1306934011182
        Bundle-ManifestVersion: 2
        Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
        Bundle-Description: Apache Lucene Java Core
        Bundle-SymbolicName: org.apache.lucene.core
        Bundle-DocURL: http://www.apache.org/
        
        Show
        Ryan McKinley added a comment - This is the same patch, but moved to the lucene parent pom – this way it applies to all artifacts rather then just the lucene core.jar The output manifest now looks like: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Bundle Plugin Built-By: ryan Build-Jdk: 1.6.0_13 Implementation-Vendor-Id: org.apache.lucene Extension-Name: org.apache.lucene Implementation-Title: org.apache.lucene Implementation-Vendor: The Apache Software Foundation Implementation-Version: 4.0-SNAPSHOT 1130132 - ryan - 2011-06-01 09:12 :35 Specification-Title: Lucene Core Specification-Vendor: The Apache Software Foundation Specification-Version: 4.0.0.2011.06.01.09.12.35 X-Compile-Source-JDK: 1.5 X-Compile-Target-JDK: 1.5 Export-Package: org.apache.lucene.analysis;uses:="org.apache.lucene.ut il,org.apache.lucene.store,org.apache.lucene.document,org.apache.luce ne.analysis.tokenattributes,org.apache.lucene.index",org.apache.lucen e.analysis.tokenattributes;uses:="org.apache.lucene.util,org.apache.l ucene.index ",org.apache.lucene.document;uses:=" org.apache.lucene.util ,org.apache.lucene.analysis ",org.apache.lucene.index;uses:=" org.apach e.lucene.search,org.apache.lucene.util,org.apache.lucene.store,org.ap ache.lucene.document,org.apache.lucene.index.codecs,org.apache.lucene .analysis.tokenattributes,org.apache.lucene.analysis",org.apache.luce ne.index.codecs;uses:="org.apache.lucene.index,org.apache.lucene.util ,org.apache.lucene.store,org.apache.lucene.index.codecs.standard,org. apache.lucene.index.codecs.pulsing,org.apache.lucene.index.codecs.sim pletext,org.apache.lucene.index.codecs.preflex,org.apache.lucene.util .packed,org.apache.lucene.util.fst",org.apache.lucene.index.codecs.in tblock;uses:="org.apache.lucene.store,org.apache.lucene.index.codecs. sep,org.apache.lucene.util",org.apache.lucene.index.codecs.preflex;us es:="org.apache.lucene.store,org.apache.lucene.index.codecs,org.apach e.lucene.index,org.apache.lucene.util,org.apache.lucene.index.codecs. standard ",org.apache.lucene.index.codecs.pulsing;uses:=" org.apache.lu cene.index.codecs.standard,org.apache.lucene.util,org.apache.lucene.s tore,org.apache.lucene.index.codecs,org.apache.lucene.index",org.apac he.lucene.index.codecs.sep;uses:="org.apache.lucene.store,org.apache. lucene.util,org.apache.lucene.index,org.apache.lucene.index.codecs",o rg.apache.lucene.index.codecs.simpletext;uses:="org.apache.lucene.sto re,org.apache.lucene.index.codecs,org.apache.lucene.index,org.apache. lucene.util,org.apache.lucene.util.fst",org.apache.lucene.index.codec s.standard;uses:="org.apache.lucene.store,org.apache.lucene.index.cod ecs,org.apache.lucene.index,org.apache.lucene.util",org.apache.lucene ,org.apache.lucene.messages,org.apache.lucene.queryParser;uses:="org. apache.lucene.util,org.apache.lucene.search,org.apache.lucene.analysi s,org.apache.lucene.analysis.tokenattributes,org.apache.lucene.docume nt,org.apache.lucene.index ",org.apache.lucene.search;uses:=" org.apach e.lucene.util,org.apache.lucene.util.automaton,org.apache.lucene.inde x,org.apache.lucene.util.packed,org.apache.lucene.search.cache,org.ap ache.lucene.store,org.apache.lucene.document,org.apache.lucene.analys is.tokenattributes,org.apache.lucene.analysis,org.apache.lucene.searc h.spans ",org.apache.lucene.search.cache;uses:=" org.apache.lucene.util ,org.apache.lucene.search,org.apache.lucene.index,org.apache.lucene.u til.packed ",org.apache.lucene.search.function;uses:=" org.apache.lucen e.search,org.apache.lucene.index,org.apache.lucene.util",org.apache.l ucene.search.payloads;uses:="org.apache.lucene.search,org.apache.luce ne.search.spans,org.apache.lucene.index,org.apache.lucene.util",org.a pache.lucene.search.spans;uses:="org.apache.lucene.util,org.apache.lu cene.search,org.apache.lucene.index ",org.apache.lucene.store;uses:=" o rg.apache.lucene.util ",org.apache.lucene.util;uses:=" org.apache.lucen e.store,org.apache.lucene.index,org.apache.lucene,org.apache.lucene.s earch ",org.apache.lucene.util.automaton;uses:=" org.apache.lucene.util ",org.apache.lucene.util.fst;uses:=" org.apache.lucene.util,org.apache .lucene.store ",org.apache.lucene.util.packed;uses:=" org.apache.lucene .util,org.apache.lucene.store" Tool: Bnd-1.15.0 Bundle-Name: Lucene Core Bundle-Vendor: The Apache Software Foundation Bundle-Version: 4.0.0.SNAPSHOT Bnd-LastModified: 1306934011182 Bundle-ManifestVersion: 2 Bundle-License: http: //www.apache.org/licenses/LICENSE-2.0.txt Bundle-Description: Apache Lucene Java Core Bundle-SymbolicName: org.apache.lucene.core Bundle-DocURL: http: //www.apache.org/
        Hide
        Ryan McKinley added a comment -

        committed to trunk in r1130150

        Can someone verify that this makes useful OSGi artifacts before I resolve the issue?

        Show
        Ryan McKinley added a comment - committed to trunk in r1130150 Can someone verify that this makes useful OSGi artifacts before I resolve the issue?
        Hide
        Luca Stancapiano added a comment -

        Ryan.... the lucene core is the parent for all modules poms, so this fixing could be not important

        Show
        Luca Stancapiano added a comment - Ryan.... the lucene core is the parent for all modules poms, so this fixing could be not important
        Hide
        Ryan McKinley added a comment -

        lucene core is the parent for all modules poms

        lucene yes, but not solr

        Show
        Ryan McKinley added a comment - lucene core is the parent for all modules poms lucene yes, but not solr
        Hide
        Luca Stancapiano added a comment -

        Ok....I tested....it's ok.... now Solr packages too are OSGI bundle

        Show
        Luca Stancapiano added a comment - Ok....I tested....it's ok.... now Solr packages too are OSGI bundle
        Hide
        Ryan McKinley added a comment -

        merged with 3.x in r1130173

        However this still does not have OSGi support in the official build.

        For that, it seems like the right approach would be with bndtools. I will resolve this issue, and we can make a new issue if someone wants to bite off integrating with the ant build. The one thing i am against is somethign that needs manual maintance everytime something changes.

        Show
        Ryan McKinley added a comment - merged with 3.x in r1130173 However this still does not have OSGi support in the official build. For that, it seems like the right approach would be with bndtools. I will resolve this issue, and we can make a new issue if someone wants to bite off integrating with the ant build. The one thing i am against is somethign that needs manual maintance everytime something changes.
        Hide
        Luca Stancapiano added a comment -

        Can you maintain two different binaries, one from ant and one from maven for each module? It would very useful for who don't develope with lucene/solr

        Show
        Luca Stancapiano added a comment - Can you maintain two different binaries, one from ant and one from maven for each module? It would very useful for who don't develope with lucene/solr
        Hide
        Ryan McKinley added a comment -

        Can you maintain two different binaries

        Not sure what that means... are you asking if Apache will release two versions of the same thing? If so, no.

        The maven integration is an officially unsupported developer build tool, so will not be part of the official release – but it does let someone easily build OSGi bundles, so it is a good step forward. If there is an ant way to do this, that could become part of the official release process.

        Show
        Ryan McKinley added a comment - Can you maintain two different binaries Not sure what that means... are you asking if Apache will release two versions of the same thing? If so, no. The maven integration is an officially unsupported developer build tool, so will not be part of the official release – but it does let someone easily build OSGi bundles, so it is a good step forward. If there is an ant way to do this, that could become part of the official release process.
        Hide
        Luca Stancapiano added a comment -

        yes it is... so I open a new ticket

        Show
        Luca Stancapiano added a comment - yes it is... so I open a new ticket
        Hide
        Ryan McKinley added a comment -

        ok – my assumption was that integrating with ant is difficult (and requires knowing all the dependencies) – we can keep using this ticket if you want. simply hit the 'reopen issue' button at the top

        Show
        Ryan McKinley added a comment - ok – my assumption was that integrating with ant is difficult (and requires knowing all the dependencies) – we can keep using this ticket if you want. simply hit the 'reopen issue' button at the top
        Hide
        Luca Stancapiano added a comment -
        Show
        Luca Stancapiano added a comment - I've just created: https://issues.apache.org/jira/browse/LUCENE-3167
        Hide
        Gunnar Wagenknecht added a comment -

        Just curious, how did you solve the split packages issues and invalid symbolic names with some Lucene modules? I can't see it in the parent pom.

        Show
        Gunnar Wagenknecht added a comment - Just curious, how did you solve the split packages issues and invalid symbolic names with some Lucene modules? I can't see it in the parent pom.
        Hide
        Ryan McKinley added a comment -

        take a look at:
        https://issues.apache.org/jira/browse/LUCENE-3172

        I don't use OSGi so i can't verify it works, but i the descriptio seems relevant to your question

        Show
        Ryan McKinley added a comment - take a look at: https://issues.apache.org/jira/browse/LUCENE-3172 I don't use OSGi so i can't verify it works, but i the descriptio seems relevant to your question
        Hide
        Luca Stancapiano added a comment -

        The problem was resolved here:

        https://issues.apache.org/jira/browse/LUCENE-3172

        It was enough to add the property in the maven-bundle-plugin in the pom.xml.template:

        Export-Package: *;-split-package:=merge-first

        Show
        Luca Stancapiano added a comment - The problem was resolved here: https://issues.apache.org/jira/browse/LUCENE-3172 It was enough to add the property in the maven-bundle-plugin in the pom.xml.template: Export-Package: *;-split-package:=merge-first
        Hide
        Robert Muir added a comment -

        bulk close for 3.3

        Show
        Robert Muir added a comment - bulk close for 3.3
        Hide
        Philipp Nanz added a comment -

        Can someone explain this to me: This issue is marked as resolved in 3.3, it's even listed in the changelog for 3.3, yet the lucene-core.jar file is clearly not OSGI-enabled... What's up with that?!

        Show
        Philipp Nanz added a comment - Can someone explain this to me: This issue is marked as resolved in 3.3, it's even listed in the changelog for 3.3, yet the lucene-core.jar file is clearly not OSGI-enabled... What's up with that?!
        Hide
        Luca Stancapiano added a comment -

        This task resolves only the maven version of lucene. So you are forced to download the 3.3 lucene version and compile it with maven. The official release is compiled with Ant so the online binaries are not released for OSGI.
        Actually there is a open task to create an OSGI bundle through ant. It is under work:

        https://issues.apache.org/jira/browse/LUCENE-3167

        Show
        Luca Stancapiano added a comment - This task resolves only the maven version of lucene. So you are forced to download the 3.3 lucene version and compile it with maven. The official release is compiled with Ant so the online binaries are not released for OSGI. Actually there is a open task to create an OSGI bundle through ant. It is under work: https://issues.apache.org/jira/browse/LUCENE-3167

          People

          • Assignee:
            Ryan McKinley
            Reporter:
            Nicolas Lalevée
          • Votes:
            12 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development