Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.2
    • Component/s: None
    • Labels:
      None

      Description

      Please provide javadoc & source jars for lucene-core. Also, please provide the rest of lucene (the jars inside of "contrib" in the download bundle) if possible.

      1. LUCENE-622_NEW.patch
        49 kB
        Michael Busch
      2. test-project.tar.gz
        1 kB
        Sami Siren
      3. lucene-maven.tar.bz2
        20 kB
        Karl Wettin
      4. lucene-622.txt
        33 kB
        Sami Siren
      5. lucene-maven.patch
        5 kB
        Jörg Hohwiller
      6. lucene-highlighter-2.0.0.pom
        0.9 kB
        Jörg Hohwiller
      7. lucene-core.pom
        2 kB
        Otis Gospodnetic

        Issue Links

          Activity

          Hide
          Otis Gospodnetic added a comment -

          Here is the POM for Maven boys and girls who want lucene-core.

          Stephen:
          What would the contrib POM look like?
          I don't think we'd have 1 POM, because each project in Lucene contrib is a separate project and a separate jar with its own dependencies. But maybe one can construct a single POM for the whole Lucene contrib - I haven't touched Maven in a few years.

          Show
          Otis Gospodnetic added a comment - Here is the POM for Maven boys and girls who want lucene-core. Stephen: What would the contrib POM look like? I don't think we'd have 1 POM, because each project in Lucene contrib is a separate project and a separate jar with its own dependencies. But maybe one can construct a single POM for the whole Lucene contrib - I haven't touched Maven in a few years.
          Hide
          Stephen Duncan Jr added a comment -

          Because they are separate projects & jars, they would each have their own POM.

          Show
          Stephen Duncan Jr added a comment - Because they are separate projects & jars, they would each have their own POM.
          Hide
          Otis Gospodnetic added a comment -

          Right, that's what I was trying to say.
          Can you provide POMs for contrib projects, or maybe just the ones that you use/need?

          Show
          Otis Gospodnetic added a comment - Right, that's what I was trying to say. Can you provide POMs for contrib projects, or maybe just the ones that you use/need?
          Hide
          Stephen Duncan Jr added a comment -

          I'm no longer doing any work with Lucene, and I'm not even sure which contrib project I wanted at the time I filed this request. While I'm sure that having poms for the contrib releases would be helpful to many people using Maven, this is no longer something that's a priority for me.

          Show
          Stephen Duncan Jr added a comment - I'm no longer doing any work with Lucene, and I'm not even sure which contrib project I wanted at the time I filed this request. While I'm sure that having poms for the contrib releases would be helpful to many people using Maven, this is no longer something that's a priority for me.
          Hide
          Jörg Hohwiller added a comment -

          pom for lucene-highlighter

          Show
          Jörg Hohwiller added a comment - pom for lucene-highlighter
          Hide
          Jörg Hohwiller added a comment -

          patch for partial mavenization of lucene

          Show
          Jörg Hohwiller added a comment - patch for partial mavenization of lucene
          Hide
          Jörg Hohwiller added a comment -

          If you apply this patch to svn (http://svn.apache.org/repos/asf/lucene/java/trunk), you can easily use maven for building and deploying artifacts for the maven repository.
          I did NOT modify your structure in any way because it seems the majority of the lucene community is not interested in maven and wants to keep going with ant. So all the patch does is adding some pom.xml files. Further I only added POMs for toplevel, core, demo and highlighter.
          From the highlighter POM you can easily create the POMs for the other contribs via cut&past and add them to the toplevel pom (contrib/pom.xml).
          If you need further assistance do NOT hesitate to ask me.

          Somehow the tests do NOT work, when I build with maven. Maybe they are currently broken. If you want to build (package), install or deploy anyways call maven (mvn) with the option "-Dmaven.test.skip=true". E.g.:
          mvn install -Dmaven.test.skip=true

          I did not spent the time to dig into the problem with the tests. If you are loading resources from the classpath please consider this:
          http://jira.codehaus.org/browse/SUREFIRE-106

          Show
          Jörg Hohwiller added a comment - If you apply this patch to svn ( http://svn.apache.org/repos/asf/lucene/java/trunk ), you can easily use maven for building and deploying artifacts for the maven repository. I did NOT modify your structure in any way because it seems the majority of the lucene community is not interested in maven and wants to keep going with ant. So all the patch does is adding some pom.xml files. Further I only added POMs for toplevel, core, demo and highlighter. From the highlighter POM you can easily create the POMs for the other contribs via cut&past and add them to the toplevel pom (contrib/pom.xml). If you need further assistance do NOT hesitate to ask me. Somehow the tests do NOT work, when I build with maven. Maybe they are currently broken. If you want to build (package), install or deploy anyways call maven (mvn) with the option "-Dmaven.test.skip=true". E.g.: mvn install -Dmaven.test.skip=true I did not spent the time to dig into the problem with the tests. If you are loading resources from the classpath please consider this: http://jira.codehaus.org/browse/SUREFIRE-106
          Hide
          Larry Hamel added a comment -

          Please update maven repo for 2.1

          Show
          Larry Hamel added a comment - Please update maven repo for 2.1
          Hide
          Sami Siren added a comment -

          Attached is a patch to existing ant based build system to generate directory tree of maven artifacts to be deployed to maven2 repository. poms are organized inside one dir instead of polluting source tree and they poms contain only minimal amount of information so they can not actually be used to build lucene-java.

          artifacts still need to be signed by hand before pushing them to repository, md5 and sha1 checksums are calculated.

          Show
          Sami Siren added a comment - Attached is a patch to existing ant based build system to generate directory tree of maven artifacts to be deployed to maven2 repository. poms are organized inside one dir instead of polluting source tree and they poms contain only minimal amount of information so they can not actually be used to build lucene-java. artifacts still need to be signed by hand before pushing them to repository, md5 and sha1 checksums are calculated.
          Hide
          Sami Siren added a comment -

          I here by grant license to ASF for inclusion in ASF works (as per the Apache Software License §5)
          (a.k.a doh! forgot to check the box)

          Show
          Sami Siren added a comment - I here by grant license to ASF for inclusion in ASF works (as per the Apache Software License §5) (a.k.a doh! forgot to check the box)
          Hide
          Karl Wettin added a comment -

          This is my attempt on Mavifying Lucene:

          tar xvfz lucene-maven.tar.gz
          cd lucene-maven
          find ./ -type d -name \.svn -execdir svn update {} \;
          mvn install

          A top level POM, and one project per contrib-module. There are two or three that is commented out due to not finding public repositories for the dependencies. There are comments in pom.xml:s

          Due to some dependency cross references (at least I think so) I ended up with seperating tests to a project by it self:

          lucene-core
          lucene-demo, depends on core
          lucene-tests, depends on demo and core

          Except for that, I think it's all pretty much clear.

          I have not spent any time with extensive ant-script convertion. This is for building, testing and deploying, not running benchmarker from CLI, et c.

          Show
          Karl Wettin added a comment - This is my attempt on Mavifying Lucene: tar xvfz lucene-maven.tar.gz cd lucene-maven find ./ -type d -name \.svn -execdir svn update {} \; mvn install A top level POM, and one project per contrib-module. There are two or three that is commented out due to not finding public repositories for the dependencies. There are comments in pom.xml:s Due to some dependency cross references (at least I think so) I ended up with seperating tests to a project by it self: lucene-core lucene-demo, depends on core lucene-tests, depends on demo and core Except for that, I think it's all pretty much clear. I have not spent any time with extensive ant-script convertion. This is for building, testing and deploying, not running benchmarker from CLI, et c.
          Hide
          Hoss Man added a comment -

          i just skimmed Sami's patch (did not test it) ... i can't help but think that the enumerated list of all contribs in the "generate-maven-artifacts" task seems like it will easily become just as hard to maintain as the related list in the javadocs macro. it seems like a more maintainable approach would be to...
          1) put the maven files for each contrib in the respective contrib dirs.
          2) put this new m2-deploy macro in common-build.xml
          3) add a "dist-maven" task to contrib/contrib-build.xml where it can be inherited by each contrib
          and calls m2-deploy using hte project name as the artifactId
          4) change generate-maven-artifacts to use contrib-crawl to take care of the pom's for the contribs.

          some other questions:
          a) it doesn't seem like all contribs are accounted for ... were some excluded intentionally?
          b) if we're going to start officially releasing "POMs" for lucene and the contribs, we should probably have a way of validating they are correct ... is there an easy mechanism for doing that? (my worry is that overtime a contrib changes, it's POM doesn't get updated, and we have a "release" in which the maven artifacts are incorrect (which in my opinion is worse then not having any maven artifacts at all)

          final minor note: using <copy> immediately followed by a <replace> on the file that was just copied can be done more cleanly using a <filterset> on the <copy>

          Show
          Hoss Man added a comment - i just skimmed Sami's patch (did not test it) ... i can't help but think that the enumerated list of all contribs in the "generate-maven-artifacts" task seems like it will easily become just as hard to maintain as the related list in the javadocs macro. it seems like a more maintainable approach would be to... 1) put the maven files for each contrib in the respective contrib dirs. 2) put this new m2-deploy macro in common-build.xml 3) add a "dist-maven" task to contrib/contrib-build.xml where it can be inherited by each contrib and calls m2-deploy using hte project name as the artifactId 4) change generate-maven-artifacts to use contrib-crawl to take care of the pom's for the contribs. some other questions: a) it doesn't seem like all contribs are accounted for ... were some excluded intentionally? b) if we're going to start officially releasing "POMs" for lucene and the contribs, we should probably have a way of validating they are correct ... is there an easy mechanism for doing that? (my worry is that overtime a contrib changes, it's POM doesn't get updated, and we have a "release" in which the maven artifacts are incorrect (which in my opinion is worse then not having any maven artifacts at all) final minor note: using <copy> immediately followed by a <replace> on the file that was just copied can be done more cleanly using a <filterset> on the <copy>
          Hide
          Grant Ingersoll added a comment -

          How does Karl's patch compare to Sami's? I haven't looked in-depth at either yet. I will try to at some point. Karl seems to be saying it has poms for each of the contribs, etc. which is probably easier to maintain. This whole bolting on of Maven to ANT just seems a little weird to me.

          FYI, Hoss, the way to validate the POM is by using Maven! It does it for you.

          I am beginning to think we should try having a parallel build for a little bit in order for people to test out the different approaches. I think the committers doing releases will see the biggest win from Maven, but I am not 100% sure. If Karl's patch achieves this, then I think we could use it as the basis for doing the evaluation.

          Show
          Grant Ingersoll added a comment - How does Karl's patch compare to Sami's? I haven't looked in-depth at either yet. I will try to at some point. Karl seems to be saying it has poms for each of the contribs, etc. which is probably easier to maintain. This whole bolting on of Maven to ANT just seems a little weird to me. FYI, Hoss, the way to validate the POM is by using Maven! It does it for you. I am beginning to think we should try having a parallel build for a little bit in order for people to test out the different approaches. I think the committers doing releases will see the biggest win from Maven, but I am not 100% sure. If Karl's patch achieves this, then I think we could use it as the basis for doing the evaluation.
          Hide
          Hoss Man added a comment -

          I didn't review Karl's attachemnt (the nice thing about patch's is that you can read them easily in a web browser, tgz files need to be downloaded and uncompressed)

          "This whole bolting on of Maven to ANT just seems a little weird to me" ... that's kind of funny Grant, it was your suggestion that prompted the approach in Sami's patch...

          http://www.nabble.com/Maven-artifacts-for-Lucene.*-tf3551707.html#a9941458
          "Couldn't we just add various ANT targets that package the jars per
          the Maven way, and even copy them to the appropriate places? I
          wonder how hard it would be to have ANT output the POM and
          create Maven Jars."

          Personally I'm much more in favor of baby steps (add an ant task to prepare the maven artifacts) then completely throwing out the build system and starting over from scratch with maven. ... if we have maven artifacts and people really start using them, then it might make sense to revist the "migrate to maven" issue ... for now though it seems like everyone is comfortable with ant, and not every one knows/understands maven.

          Show
          Hoss Man added a comment - I didn't review Karl's attachemnt (the nice thing about patch's is that you can read them easily in a web browser, tgz files need to be downloaded and uncompressed) "This whole bolting on of Maven to ANT just seems a little weird to me" ... that's kind of funny Grant, it was your suggestion that prompted the approach in Sami's patch... http://www.nabble.com/Maven-artifacts-for-Lucene.*-tf3551707.html#a9941458 "Couldn't we just add various ANT targets that package the jars per the Maven way, and even copy them to the appropriate places? I wonder how hard it would be to have ANT output the POM and create Maven Jars." Personally I'm much more in favor of baby steps (add an ant task to prepare the maven artifacts) then completely throwing out the build system and starting over from scratch with maven. ... if we have maven artifacts and people really start using them, then it might make sense to revist the "migrate to maven" issue ... for now though it seems like everyone is comfortable with ant, and not every one knows/understands maven.
          Hide
          Sami Siren added a comment -

          thanks Hoss for the feedback in general. I am now a bit confused - is there a consensus how to proceed with this (in other words should I change things as suggested or are we going to take the maven approach to this?)

          > some other questions:
          > a) it doesn't seem like all contribs are accounted for ... were some excluded intentionally?

          Some were excluded intentionally as their dependencies are not available in public repos (gdata, db), some were just excluded(javascript, lucli, ant)

          > (my worry is that overtime a contrib
          > changes, it's POM doesn't get updated, and we have a "release" in which the maven artifacts are incorrect (which
          > in my opinion is worse then not having any maven artifacts at all)

          for 1.9.1 the jar itself was faulty http://jira.codehaus.org/browse/MEV-449

          Show
          Sami Siren added a comment - thanks Hoss for the feedback in general. I am now a bit confused - is there a consensus how to proceed with this (in other words should I change things as suggested or are we going to take the maven approach to this?) > some other questions: > a) it doesn't seem like all contribs are accounted for ... were some excluded intentionally? Some were excluded intentionally as their dependencies are not available in public repos (gdata, db), some were just excluded(javascript, lucli, ant) > (my worry is that overtime a contrib > changes, it's POM doesn't get updated, and we have a "release" in which the maven artifacts are incorrect (which > in my opinion is worse then not having any maven artifacts at all) for 1.9.1 the jar itself was faulty http://jira.codehaus.org/browse/MEV-449
          Hide
          Michael Busch added a comment -

          > Personally I'm much more in favor of baby steps (add an ant task to prepare
          > the maven artifacts) then completely throwing out the build system and starting
          > over from scratch with maven.

          I agree with Hoss here. I strongly discourage from switching from ant to maven
          now before 2.2 is out. I would like to keep the ant build for now and add a target
          that generates the pom files for the maven upload.

          After 2.2 is out though we should discuss again whether is makes sense to switch
          to maven. Then we would have enough time to thoroughly test the new build system
          before the next release.

          Show
          Michael Busch added a comment - > Personally I'm much more in favor of baby steps (add an ant task to prepare > the maven artifacts) then completely throwing out the build system and starting > over from scratch with maven. I agree with Hoss here. I strongly discourage from switching from ant to maven now before 2.2 is out. I would like to keep the ant build for now and add a target that generates the pom files for the maven upload. After 2.2 is out though we should discuss again whether is makes sense to switch to maven. Then we would have enough time to thoroughly test the new build system before the next release.
          Hide
          Karl Wettin added a comment -

          Grant Ingersoll - [04/Jun/07 08:05 AM ]
          > How does Karl's patch compare to Sami's?

          I didn't look in to Samis, I just cleaned up mine and poped it in here as an alternative when I saw the action.

          His deploys jars built by Ant to a Maven repository. Mine is a bunch of POM skeletons that gathers the code from the Ant-structured SVN trunk so that one can use Maven to build, test and deploy (and itegrate with my development environment and all the other things it does for me).

          There are most probably some problem with some test. Mavens test plugin require a bit of configuration to avoid all automagic things it does. The lucene-tests/pom.xml contains comments on that.

          lucene-demo shoudl probably be worked a bit more, it really only contains the source code that some other things depends on (tests mostly). Perhaps someone that knows webthings could fix the resource dir and all so it could build a deployable war-file or something. I don't know.

          The only thing I can think of that can be a major pain is to apply a trunk patch that span multiple projects. Never had to do that though.

          It is running smooth over here.

          Show
          Karl Wettin added a comment - Grant Ingersoll - [04/Jun/07 08:05 AM ] > How does Karl's patch compare to Sami's? I didn't look in to Samis, I just cleaned up mine and poped it in here as an alternative when I saw the action. His deploys jars built by Ant to a Maven repository. Mine is a bunch of POM skeletons that gathers the code from the Ant-structured SVN trunk so that one can use Maven to build, test and deploy (and itegrate with my development environment and all the other things it does for me). There are most probably some problem with some test. Mavens test plugin require a bit of configuration to avoid all automagic things it does. The lucene-tests/pom.xml contains comments on that. lucene-demo shoudl probably be worked a bit more, it really only contains the source code that some other things depends on (tests mostly). Perhaps someone that knows webthings could fix the resource dir and all so it could build a deployable war-file or something. I don't know. The only thing I can think of that can be a major pain is to apply a trunk patch that span multiple projects. Never had to do that though. It is running smooth over here.
          Hide
          Michael Busch added a comment -

          Sami,

          I applied your patch to my local checkout and uploaded the directory tree with the generated
          artifacts to http://people.apache.org/~buschmi/staging_area/lucene/.

          (I admitted already that I'm a maven newbie, so the following question hopefully won't be
          too embarrassing ) How do we test if the generated artifacts are ok?

          Show
          Michael Busch added a comment - Sami, I applied your patch to my local checkout and uploaded the directory tree with the generated artifacts to http://people.apache.org/~buschmi/staging_area/lucene/ . (I admitted already that I'm a maven newbie, so the following question hopefully won't be too embarrassing ) How do we test if the generated artifacts are ok?
          Hide
          Hoss Man added a comment -

          Seeing Michael's update to this issue reminded me that a few days ago when looking in the archives to see some of the discussion that happened during the 2.1 release I was realized that was when the last really big discussion about using maven came up, and one of the ideas put forth was to use the "maven antlib" (some custom ant tasks provided by the maven project) to deal with fetching remote dependencies for contribs (that have them) and publishing our jars (and their pom files) to the main maven repository. thinking about it more now, this also solves our "how do we communicate contrib dependencies to people who download binary distributions?" problem – we can inlcude the pom.xml files in the release, and people can easily read them even if they don't use maven.

          between Sami's patch and Karl's tarball it seems like we already have some good pom files for all of the projects, the hard parts are making sure they stay up to date with reality as contribs evolve, and publishing them to the maven repository correctly. it seems maven't ant tasks can trivially solve the second problem, and easily solve the first if we make some changes to use it for fetching dependencies....

          http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a9014632
          http://maven.apache.org/ant-tasks.html

          thoughts?

          Show
          Hoss Man added a comment - Seeing Michael's update to this issue reminded me that a few days ago when looking in the archives to see some of the discussion that happened during the 2.1 release I was realized that was when the last really big discussion about using maven came up, and one of the ideas put forth was to use the "maven antlib" (some custom ant tasks provided by the maven project) to deal with fetching remote dependencies for contribs (that have them) and publishing our jars (and their pom files) to the main maven repository. thinking about it more now, this also solves our "how do we communicate contrib dependencies to people who download binary distributions?" problem – we can inlcude the pom.xml files in the release, and people can easily read them even if they don't use maven. between Sami's patch and Karl's tarball it seems like we already have some good pom files for all of the projects, the hard parts are making sure they stay up to date with reality as contribs evolve, and publishing them to the maven repository correctly. it seems maven't ant tasks can trivially solve the second problem, and easily solve the first if we make some changes to use it for fetching dependencies.... http://www.nabble.com/-VOTE--release-Lucene-2.1-tf3228536.html#a9014632 http://maven.apache.org/ant-tasks.html thoughts?
          Hide
          Sami Siren added a comment -

          The file attached contains a very simple maven2 project that uses few of the artifacts that Michael put on staging area. (for showing the obvious way how to test them)

          On the root dir just enter "mvn test" to see dependencies get fetched, project compiled and junit tests run.

          Show
          Sami Siren added a comment - The file attached contains a very simple maven2 project that uses few of the artifacts that Michael put on staging area. (for showing the obvious way how to test them) On the root dir just enter "mvn test" to see dependencies get fetched, project compiled and junit tests run.
          Hide
          Michael Busch added a comment -

          This new patch combines the pom.xml files from Sami and Karl with some modifications
          to make them consistent, as well as Hoss' recommendations regarding the maven ant
          tasks.

          Details:

          • We now have pom.xml files for all contribs except javascript (which has no
            build.xml) and gdata.
          • I added the following four poms to the root directory: "lucene-contrib-pom.xml",
            "lucene-core-pom.xml", "lucene-demos-pom.xml" and "lucene-parent-pom.xml".
            Each contrib directory contains a file "pom.xml".
          • Added the "m2-deploy" macro to common-build.xml. It now uses the maven ant tasks
            to deploy the pom and jar files to a local repository located in dist/maven.
          • Added a new target "dist-maven" to contrib-build.xml that is only executed if
            a pom.xml is present in the contrib dir.
          • Added the target "generate-maven-artifacts" to build.xml which calls "m2-deploy"
            for the parent, core, demos, and contrib poms. Then it does a contrib crawl
            with target "dist-maven".

          This works quite well. However there are probably some things that can be
          simplified or improved:

          • I copy the pom.xml to the build dir first so that I can replace the @version@
            placeholder with the actual value. There's probably a way to do this with
            the maven ant tasks without having to copy the file first.
          • This might be a hack but I couldn't figure out a way to do this differently
            yet: In the "dist-maven" target I read the parent, core and contrib pom.xml
            using the <artifact:pom> task. I don't actually need to load those poms
            but if I don't do it the build fails, because the contrib artifacts have the
            "lucene-contrib" artifact as parent. Even if I specify the local repository
            where those artifacts are located or if I add them as dependencies it doesn't
            work. A hint here is appreciated.
          • The new lucene-checksum macro is not used yet for md5 computation of the
            artifact files.

          I will spend more time on this patch during the next days for testing. Some feedback
          and help with testing is highly appreciated. It would also be helpful if the contrib
          owners could take a look at the particular pom.xml files.

          For testing purposes I uploaded the artifacts generated by this patch to
          http://people.apache.org/~buschmi/staging_area/lucene

          Show
          Michael Busch added a comment - This new patch combines the pom.xml files from Sami and Karl with some modifications to make them consistent, as well as Hoss' recommendations regarding the maven ant tasks. Details: We now have pom.xml files for all contribs except javascript (which has no build.xml) and gdata. I added the following four poms to the root directory: "lucene-contrib-pom.xml", "lucene-core-pom.xml", "lucene-demos-pom.xml" and "lucene-parent-pom.xml". Each contrib directory contains a file "pom.xml". Added the "m2-deploy" macro to common-build.xml. It now uses the maven ant tasks to deploy the pom and jar files to a local repository located in dist/maven. Added a new target "dist-maven" to contrib-build.xml that is only executed if a pom.xml is present in the contrib dir. Added the target "generate-maven-artifacts" to build.xml which calls "m2-deploy" for the parent, core, demos, and contrib poms. Then it does a contrib crawl with target "dist-maven". This works quite well. However there are probably some things that can be simplified or improved: I copy the pom.xml to the build dir first so that I can replace the @version@ placeholder with the actual value. There's probably a way to do this with the maven ant tasks without having to copy the file first. This might be a hack but I couldn't figure out a way to do this differently yet: In the "dist-maven" target I read the parent, core and contrib pom.xml using the <artifact:pom> task. I don't actually need to load those poms but if I don't do it the build fails, because the contrib artifacts have the "lucene-contrib" artifact as parent. Even if I specify the local repository where those artifacts are located or if I add them as dependencies it doesn't work. A hint here is appreciated. The new lucene-checksum macro is not used yet for md5 computation of the artifact files. I will spend more time on this patch during the next days for testing. Some feedback and help with testing is highly appreciated. It would also be helpful if the contrib owners could take a look at the particular pom.xml files. For testing purposes I uploaded the artifacts generated by this patch to http://people.apache.org/~buschmi/staging_area/lucene
          Hide
          Sami Siren added a comment -

          Michael, thank you very much for pushing this further. I briefly tested building some stuff against the artifacts you have deployed on staging area and everything worked as expected.

          Show
          Sami Siren added a comment - Michael, thank you very much for pushing this further. I briefly tested building some stuff against the artifacts you have deployed on staging area and everything worked as expected.
          Hide
          Michael Busch added a comment -

          Sami, thanks for your testing efforts!
          I also ran some tests and all artifacts seem to be fine except "lucene-bdb".
          It has "sleepycat je 1.7" as a dependency, but actually it needs the
          "http://downloads.osafoundation.org/db/db-4.3.29.jar" to compile. Couldn't
          find that one in a maven repository though.

          Show
          Michael Busch added a comment - Sami, thanks for your testing efforts! I also ran some tests and all artifacts seem to be fine except "lucene-bdb". It has "sleepycat je 1.7" as a dependency, but actually it needs the "http://downloads.osafoundation.org/db/db-4.3.29.jar" to compile. Couldn't find that one in a maven repository though.
          Hide
          Karl Wettin added a comment -

          Michael Busch - [15/Jun/07 12:41 AM ]
          > It has "sleepycat je 1.7" as a dependency, but actually it needs the
          > "http://downloads.osafoundation.org/db/db-4.3.29.jar" to compile. Couldn't
          > find that one in a maven repository though.

          I don't know what the Apache foundations thinks about it, but hosting a maven
          repo is a peice of cake. Also, I would not mind at all if the Hudson or something
          would publish a nightly snapshot of the Lucene projects to that repo.

          Show
          Karl Wettin added a comment - Michael Busch - [15/Jun/07 12:41 AM ] > It has "sleepycat je 1.7" as a dependency, but actually it needs the > "http://downloads.osafoundation.org/db/db-4.3.29.jar" to compile. Couldn't > find that one in a maven repository though. I don't know what the Apache foundations thinks about it, but hosting a maven repo is a peice of cake. Also, I would not mind at all if the Hudson or something would publish a nightly snapshot of the Lucene projects to that repo.
          Hide
          Michael Busch added a comment -

          > Also, I would not mind at all if the Hudson or something
          > would publish a nightly snapshot of the Lucene projects to that repo.

          Yes, we could think about doing that in the future.

          For now I'm planning to commit this patch shortly for 2.2 unless there
          are objections.

          Show
          Michael Busch added a comment - > Also, I would not mind at all if the Hudson or something > would publish a nightly snapshot of the Lucene projects to that repo. Yes, we could think about doing that in the future. For now I'm planning to commit this patch shortly for 2.2 unless there are objections.
          Hide
          Michael Busch added a comment -

          Committed to trunk & 2.2 branch with a little change:
          I removed the "sleepycat je 1.7" dependency from the
          pom.xml of "lucene-bdb".

          Phew!

          Show
          Michael Busch added a comment - Committed to trunk & 2.2 branch with a little change: I removed the "sleepycat je 1.7" dependency from the pom.xml of "lucene-bdb". Phew!

            People

            • Assignee:
              Michael Busch
              Reporter:
              Stephen Duncan Jr
            • Votes:
              4 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development