I am just starting a student project for a lesson based on apache lucene and the data that i am going to process with this tool is critics about restaurants from yelp.
What version do you recommend as the most stable for this purpose?
I think that if you are starting from scratch there's no reason to use an old version. Use the latest version (8.0). Lucene releases are always very stable in my experience.
Related
I have updated the apache2 version form apache2.2.14 to apache2.4.7 and also apache-solr package form 1.4.x to 4.x.
Before upgradation, I have indexed all the content.
After upgradation, in apache configuration it showing 0% indexed.
is there any way to use old indexing?
Solr / Lucene only upgrades older index formats in smaller increments, so you'll have to at least stop by a 3.x release on the way to be able to use the 1.4 index formats.
I'd also recommend going from 4 to 5 as well, since you're already doing the upgrade now, and will be stuck in the past again if you don't do the 5.x upgrade as well (6.0 was just released).
My suggestion is to optimize for easy reindexing, and do that. You'll run into the same issue later, or after doing any major changes to your schema.
The index format is backward compatible between two consecutive major
Solr versions. So a Solr 3.x index is compatible with a Solr 4.x
index. However if you have a Solr 1.x index and want to upgrade to
Solr 4.x then you would need to first upgrade to Solr 3.x first.
upgrade between major Solr Versions
So you'll have to go via 3.x (as Mats says below) or reindex or use the IndexUpgrader tool on your index.
http://lucene.apache.org/core/4_0_0/core/org/apache/lucene/index/IndexUpgrader.html
I would like to distribute an application that depends on several PyPI-packaged libraries. I have carefully selected certain versions of some of these libraries as newer versions (in some cases) are incompatible. My installer downloads them (with pip) at install-time and sets up the environment for the application. But how long are those versions going to be available? 6 hours? 2 years? Anything in between?
I'm basically looking for some sort of policy that tells me how long those versions of libraries are going to be hosted on PyPI (and who makes that decision).
In-before-"distribute them yourself": That is an answer to a different question.
This is really about how PyPI works, not how I distribute my application.
The friendly people in #python tell me that authors can delete any version of their packages at any time.
The only way to indemnify yourself against a version of something becoming nuked is to (assuming their license allows it) ship it yourself.
There is an argument for continuous integration against the latest versions on PyPI but that does assume there will be a new version and that the author doesn't just delete the whole thing. CI is just a good practice here, not a panacea.
My standard route has been to go to confluence, find the docs sections, then navigate through to the install docs for the version, e.g. sakai 10:
https://confluence.sakaiproject.org/x/iYGLBQ
Through one means or another I happened across the source route to this too, so starting here....
http://source.sakaiproject.org/release/
You get redirected to the latest stuff, and appended version numbers to that url gives you other docs, e.g. adding 2.8.2 or 10 to the end of the url
But the links to what I should download are quite often not there, at the time of writing the 10 tar ball and zip in the confluence links are dead and the source.sakaiproject links doesn't have the 10 docs yet (redirects to 2.9.3) presumably this is because v10 is not released yet....
So, I'd like to evaluate a new version of a sakai source install, what's the best way to do this? (considering the official documentation for install is still being formed)
Do I download the latest SVN, or the latest RC or the latest beta or??? How do I know what's best to test against without being "too" bleeding edge? Is there a recommended tar ball/zip link to test against? Is there a "latest good" SVN branch?
The latest code is always in the Sakai trunk (currently svn):
https://source.sakaiproject.org/svn/sakai/trunk/
That code may very well not be stable though as it is where things are being actively developed. If you are not actively developing then you should stick to the releases as indicated on the project website here:
http://sakaiproject.org/current-release
If you want to use something in between (say an upcoming release) then you can grab the most recent tag or maybe use a recent branch (both currently in svn, latest shown below at the time I write this):
https://source.sakaiproject.org/svn/sakai/branches/sakai-10.x/
https://source.sakaiproject.org/svn/sakai/tags/sakai-10-rc02/
The reality of the situation is that if you want to use something other than the release then you should really participate in the dev community for Sakai. Joining the mailing lists and the weekly calls will provide the information you are asking about and much more.
I have installed a fresh install of XWiki on a Windows platform.
The XWiki instance was installed using hsql for data storage.
The XWiki instance is hosted on Apache Tomcat.
Some of my users entered an apostrophe into the title of a page as well as the page content.
I received the following error:
http://jira.xwiki.org/jira/browse/XE-767
What is my next step to fix my broken XWiki instance?
Is there a way to upgrade a XWiki instance to a version that works? How do I save my existing content?
From reviewing the developers comments, it appears that issue has been corrected.
I, however, do not have enough background in Java or XWiki to know how I can move forward.
Thank you in advance for your help.
Indeed, the best solution is to upgrade to a newer version. Don't worry, upgrades are not that difficult.
http://platform.xwiki.org/xwiki/bin/AdminGuide/Installation#HUpgradinganXWikiInstallation
There are two parts in an upgrade: the platform, meaning all the files on the filesystem, and the wiki content, since quite often things change in the default wiki documents. Your specific bug can be fixed by upgrading the platform part, so if you're not too confident about upgrading the wiki content, you can just leave the old content in place.
In order not to lose your current database, be sure to leave the old "database" folder in place, and just replace the "webapps\xwiki" part.
From the error report the versions that fix the issue are
2.7 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise27
2.6.1 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise261
You can upgrade to one of them or to any following version, like XE
3.0 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise30
All versions can be downloaded from http://forge.ow2.org/project/showfiles.php?group_id=170
In a project that has such a rapid development cycle is very good to upgrade often in order to benefit from the latest features and bug fixes.
I'm just starting out in Ruby (Rails actually) and the book I'm reading covers Ruby 1.8.6, RubyGems 1.0.1, Rails 2.0.2 and SQLite 3.5.4, but the current stable releases of these are 1.9.1, 2.3.8, 1.3.7 and 3.7.0 respectively, should I still proceed with the book or find another?
Also, I couldn't find a recent guide/tutorial to walk me through the installation of these latest versions, would be great if you could help with that too. I'm on Mac OSX Snow Leopard (10.6.4).
Many thanks!
There are a large number of projects with major release milestones just around the corner. These include Ruby 1.9.2 (the 2nd RC is already out), Rails 3.0 (the RC is already out), and a number of other libraries and plugins. Please note that Rails 3 does not support Ruby 1.9.1, although it does support 1.8.7 and 1.9.2.
I would start out with Ruby 1.9.2-rc2 and Rails 3.0.0.rc. These are what will be the current version over the next few years, starting within the next few weeks. Previous versions of Ruby and Rails will be legacy.
Look for new editions of books coming out, having been updated for Ruby 1.9.2 and Rails 3.0.
I were like you. Although Ruby is popular, they are very bad and inconsistent in such kinds of various versions. Firstly, I thought that the latest version is always the best, which holds the true for most languages. Later, in these days, due to the removal, re-structure and redesign of logic and underlying codes, the latest version is not always good for programmers who are used to writing codes in older version. See python case (2.x vs 3.x).
So, for ruby, if you're holding a book that teaches you in ruby 1.8.x, then just relax and adhere to 1.8.x. Install 1.8.x version and Practice. Same for 1.9.x and other versions. Or else you'll end up with frustration like "why doesn't my code run?".
The most important thing is RubyGem. RubyGem is also stick to ruby version. Gems that run in 1.8.x are not usually compatible with 1.9.x. So, keep that in mind. Or else you're unhappy that you install this gem and you can't call it - its objects.
Now, my practice is that I install every version. I exclude ruby path and its lib in PATH variable. When I want to switch between each version, I use BAT/bash file that set variable for each version like PATH=$PATH:/opt/ruby18 .
I've also asked many questions about this in many forums. As you know, the life and true aspect of programming is to (re)use libraries and objects. If certain libraries don't work with a certain version of ruby, then you have to switch to others. This is also my bad feeling about ruby. They really should have backward compatibility.
Maybe others can solve this problem smarter than me. But it really messed up with my programming life.
Checkout RVM, use it to install different versions of Ruby/Rails on your machine without root access. It will make your Rails development easier :)
railstutorial.org walks you through the installation of everything you need on OS X. It's also more recent than the book you're using.
Take your pick, the Rails book or the version that you specifically need to learn.
Once you decide on a book, install the versions of the language / gems as mentioned in the book. e.g. Rails 1.2 and Rails 2.0 had pretty big differences and the tutorials wouldn't work.
If you're learning Rails, pick a well known book, install the specific gems. Once you're done with the book, you'd be in a better position to look at the differences and migrate to higher versions with less hassle.
gem list rails --remote
gem install [gemname] --version [version]