开源纯JAVA全文搜索引擎，希望大家给点意见。 恩，不错~~~我马上把它加入http://www.jopener.com 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 有问题告诉我，我的EMAIL: [email protected] 我的英文不是很好，一开始申请因为是外国网站，担心不支持中文，死撑着做出英文的来的……中文的点jbox project旁边的CN就可以进了。 请问下楼主，您的这个作品和lucene比有什么优势或者特点？ 开发这个之前我也考虑过LUCENE，但在仔细看了LUCENE之后，有4个地方让我觉得不舒服，于是突然就萌生了想自己做一个这样的东西出来的想法。1. LUCENE本身只是一个检索框架，需要做成完整的搜索引擎的话还需要再去学NUTCH，然后再去研究两者之间的整合，这过程理解起来不容易；2. LUCENE对数据库的支持度不好，虽说有数据库扩展包，但LUCENE主页上的FAQ也说了，并不理想。而对于大规模数据我比较倾向于数据库，所以在当时在看LUCENE时第一想法其实是能不能开发一个更好的基于数据库扩展包，不过后来发现这个扩展好复杂。3. LUCENE对中文的支持度不够(虽然有很多人做了中文的扩展就是了）；4. 最后一点，也是让我最不舒服的一点，LUCENE的源代码，如果有看的人应该可以发现，很多地方并不是很符合面向对象的，看起来很费劲，也很难理解。例如，因为我英文语法不行，所以英文分析参照了LUCENE（org.apache.lucene.analysis.PorterStemmer这个类），发现LUCENE的处理方法是传入一个字符串后，定义全局变量做下标，利用全局下标在字符串之间移动处理（其中还有一些方法是单纯用于移动下标的，意义不明……）。很难表达我当时那种感觉，总之，感觉很别扭，不自在。或许这样做可以提高分词的性能，但我还是比较喜欢面向对象的处理方法；在之后做JBOX的时候，就是根据上面对LUCENE不满的地方做的。1. JBOX最首要的目的，是简单。要让开发变得更简单，个人认为，这是框架的首要责任。当然，或许目前我这个作品可能依然不够简单性，在后续的版本我会继续努力改进。2. JBOX第二个目的是纯粹的面向数据库。因为相信有很多人跟我一样，应用程序都习惯搭建在数据库上，由其是大规模的数据。目前的版本中，持久层是用HIBERNATE做的，这影响了存储索引时的效率，我在尝试写存储过程来代替HIBERNATE在存储的部分的功能，以提高效率，后续的版本会追加这一点；3. JBOX分词的出发点不是西方文字，而是中文（毕竟还是母语熟悉，其他语言的分词好难懂，呜呜……）。分词部分完整的我没有看LUCENE怎么实现，JBOX的实现方式是利用责任链对多语言文本进行切词，虽然目前仅实现了英文跟中文就是了。（德文的切法正在看LUCENE的实现中，就如上面所说的，难懂……）；4. JBOX的结构是尽量按面向对象的思想设计的，目前我还在继续改进中。其实如果单单只是要搜索引擎的功能，3个月前我就已经做好了。但为了让其结构更容易理解，更容易扩展，更加贴近面向对象，这个过程整整消耗了我3个月时间。（想想真很辛苦，我也要上班养活自己，时间都是挤出来的，唉。）；5. 最后，类似google那样相关词搜索的功能，LUCENE没有吧？这个就如我上面帖子里说的，我已经实现了，只是还没整理。相关算法的论文也在审稿中，9月15号后才能知道结果（编辑部回答时15号后在问，没说15号后多少，呜……）；最后，JBOX当然不可能代替LUCENE，我也没那么自大去做这种事。例如LUCENE在文件索引，数据库索引方面我是暂时没打算做的。JBOX的当前目的只是，网站上的搜索引擎，其他的检索还是要LUCENE。 不会重复劳动的，重复劳动的工作sourceforge也不会批了吧，呵。谢谢楼上的鼓励^_^ 我也离职了，呵呵。先谢谢了，如果有任何idea或意见记得要告诉我啊！ 重复劳动的工作sourceforge也会批...就和google code一样，没有什么门槛的不过支持一下，看到国内开源慢慢的开始有发展了已经加入开源介绍了http://www.jopener.com/category/search-engines/ 谢谢楼上的支持^_^PS:sourceforge的项目申请流程很复杂，我还以为很严格呢- -…… 先顶一下我使用sourceforge也感觉比较麻烦，如果有什么比较方便的管理方法，给一个。 没。那个CVS功能到现在我都还没开通，感觉太繁琐了…… google code好像即时开通的。不过gcode的权限控制不够细。。 LZ 真棒，下午在我自己电脑上配置了一下，老是显示找不到文件jbox.cfg.xml，狂晕~~~~~~~~~~~~~~~~~~~~~~~~~~ 啊，忘了说，谢谢楼上朋友帮我测试！非常感谢！因为我只有在公司跟自己的电脑上测试过（开发环境当然我也设置得差不多一样），所以不知道在别人的机器上运行会有可能出现什么BUG，所以才需要大家的帮忙啊！（再次感谢lovelygirl0316 MM ^_^) 楼上的朋友，应该说多一些开源的开发人员^_^有时候在憧憬，什么时候我们国内开源开发的氛围有sourceforge那样，那是多好啊…… 开发这个之前我也考虑过LUCENE，但在仔细看了LUCENE之后，有4个地方让我觉得不舒服，于是突然就萌生了想自己做一个这样的东西出来的想法。1. LUCENE本身只是一个检索框架，需要做成完整的搜索引擎的话还需要再去学NUTCH，然后再去研究两者之间的整合，这过程理解起来不容易；-------------------------------------------做完整的搜索没必要学习NUTCH,只有你会使用lucene提供的API就够了2. LUCENE对数据库的支持度不好，虽说有数据库扩展包，但LUCENE主页上的FAQ也说了，并不理想。而对于大规模数据我比较倾向于数据库，所以在当时在看LUCENE时第一想法其实是能不能开发一个更好的基于数据库扩展包，不过后来发现这个扩展好复杂。-------------------------------------------lucene的搜索都是针对索引，数据库方面有一个基于LUcene的compass，还蛮好用的3. LUCENE对中文的支持度不够(虽然有很多人做了中文的扩展就是了）；----------------------------------------------------------------似乎支持的很好了吧4. 最后一点，也是让我最不舒服的一点，LUCENE的源代码，如果有看的人应该可以发现，很多地方并不是很符合面向对象的，看起来很费劲，也很难理解。例如，因为我英文语法不行，所以英文分析参照了LUCENE（org.apache.lucene.analysis.PorterStemmer这个类），发现LUCENE的处理方法是传入一个字符串后，定义全局变量做下标，利用全局下标在字符串之间移动处理（其中还有一些方法是单纯用于移动下标的，意义不明……）。很难表达我当时那种感觉，总之，感觉很别扭，不自在。或许这样做可以提高分词的性能，但我还是比较喜欢面向对象的处理方法；不过LZ能自己做全文检索，让人佩服！ LZ 加你啦，程序中调用配置文件XML的路径有点问题，改了一点源代码，现在OK啦 *_@ mybaits 使用sqlMap如何知道update语句到底更新了数据没有? spring 高级查询 detached criteria EJB入门，求例子 快毕业了，想做java开发，各位给点意见啊？ spring 中定时器的设置 谁能给我struts2开发环境 如何使lucene全文检索到的结果在jsp页面上高亮显示？ spring + hibernate 的问题 *.pdg 用什么打开 （不是*.pdf） 求救.急! JBPM决策点问题 万分火急在线等!!!!!! jfreechart在linux下中文问题
中文的点jbox project旁边的CN就可以进了。
2. LUCENE对数据库的支持度不好，虽说有数据库扩展包，但LUCENE主页上的FAQ也说了，并不理想。而对于大规模数据我比较倾向于数据库，所以在当时在看LUCENE时第一想法其实是能不能开发一个更好的基于数据库扩展包，不过后来发现这个扩展好复杂。
3. LUCENE对中文的支持度不够(虽然有很多人做了中文的扩展就是了）；
4. 最后一点，也是让我最不舒服的一点，LUCENE的源代码，如果有看的人应该可以发现，很多地方并不是很符合面向对象的，看起来很费劲，也很难理解。例如，因为我英文语法不行，所以英文分析参照了LUCENE（org.apache.lucene.analysis.PorterStemmer这个类），发现LUCENE的处理方法是传入一个字符串后，定义全局变量做下标，利用全局下标在字符串之间移动处理（其中还有一些方法是单纯用于移动下标的，意义不明……）。很难表达我当时那种感觉，总之，感觉很别扭，不自在。或许这样做可以提高分词的性能，但我还是比较喜欢面向对象的处理方法；在之后做JBOX的时候，就是根据上面对LUCENE不满的地方做的。
1. JBOX最首要的目的，是简单。要让开发变得更简单，个人认为，这是框架的首要责任。当然，或许目前我这个作品可能依然不够简单性，在后续的版本我会继续努力改进。
2. JBOX第二个目的是纯粹的面向数据库。因为相信有很多人跟我一样，应用程序都习惯搭建在数据库上，由其是大规模的数据。目前的版本中，持久层是用HIBERNATE做的，这影响了存储索引时的效率，我在尝试写存储过程来代替HIBERNATE在存储的部分的功能，以提高效率，后续的版本会追加这一点；
3. JBOX分词的出发点不是西方文字，而是中文（毕竟还是母语熟悉，其他语言的分词好难懂，呜呜……）。分词部分完整的我没有看LUCENE怎么实现，JBOX的实现方式是利用责任链对多语言文本进行切词，虽然目前仅实现了英文跟中文就是了。（德文的切法正在看LUCENE的实现中，就如上面所说的，难懂……）；
4. JBOX的结构是尽量按面向对象的思想设计的，目前我还在继续改进中。其实如果单单只是要搜索引擎的功能，3个月前我就已经做好了。但为了让其结构更容易理解，更容易扩展，更加贴近面向对象，这个过程整整消耗了我3个月时间。（想想真很辛苦，我也要上班养活自己，时间都是挤出来的，唉。）；
5. 最后，类似google那样相关词搜索的功能，LUCENE没有吧？这个就如我上面帖子里说的，我已经实现了，只是还没整理。相关算法的论文也在审稿中，9月15号后才能知道结果（编辑部回答时15号后在问，没说15号后多少，呜……）；最后，JBOX当然不可能代替LUCENE，我也没那么自大去做这种事。例如LUCENE在文件索引，数据库索引方面我是暂时没打算做的。JBOX的当前目的只是，网站上的搜索引擎，其他的检索还是要LUCENE。
谢谢楼上的鼓励^_^
就和google code一样，没有什么门槛的不过支持一下，看到国内开源慢慢的开始有发展了
已经加入开源介绍了http://www.jopener.com/category/search-engines/
不过gcode的权限控制不够细。。
因为我只有在公司跟自己的电脑上测试过（开发环境当然我也设置得差不多一样），所以不知道在别人的机器上运行会有可能出现什么BUG，所以才需要大家的帮忙啊！（再次感谢lovelygirl0316 MM ^_^)
-------------------------------------------
做完整的搜索没必要学习NUTCH,只有你会使用lucene提供的API就够了2. LUCENE对数据库的支持度不好，虽说有数据库扩展包，但LUCENE主页上的FAQ也说了，并不理想。而对于大规模数据我比较倾向于数据库，所以在当时在看LUCENE时第一想法其实是能不能开发一个更好的基于数据库扩展包，不过后来发现这个扩展好复杂。
-------------------------------------------
lucene的搜索都是针对索引，数据库方面有一个基于LUcene的compass，还蛮好用的3. LUCENE对中文的支持度不够(虽然有很多人做了中文的扩展就是了）；
----------------------------------------------------------------
似乎支持的很好了吧4. 最后一点，也是让我最不舒服的一点，LUCENE的源代码，如果有看的人应该可以发现，很多地方并不是很符合面向对象的，看起来很费劲，也很难理解。例如，因为我英文语法不行，所以英文分析参照了LUCENE（org.apache.lucene.analysis.PorterStemmer这个类），发现LUCENE的处理方法是传入一个字符串后，定义全局变量做下标，利用全局下标在字符串之间移动处理（其中还有一些方法是单纯用于移动下标的，意义不明……）。很难表达我当时那种感觉，总之，感觉很别扭，不自在。或许这样做可以提高分词的性能，但我还是比较喜欢面向对象的处理方法；不过LZ能自己做全文检索，让人佩服！