You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-commits@lucene.apache.org by Apache Wiki <wi...@apache.org> on 2011/05/16 18:24:08 UTC

[Solr Wiki] Update of "HowToContribute" by VarunThacker

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "HowToContribute" page has been changed by VarunThacker.
The comment on this change is: Added howto import code style xml in eclipse helios.
http://wiki.apache.org/solr/HowToContribute?action=diff&rev1=60&rev2=61

--------------------------------------------------

   * New unit tests should be provided to demonstrate bugs and fixes (http://www.junit.org).
  
  == Notes for Eclipse and the New Merged Lucene/Solr checkout ==
- 
  Another issue you may see is character encoding, especially if you are including the lucene/contrib/analyzers package. On Eclipse, you can solve this by going to Project > Properties > Resources, and then changing the encoding on that page to UTF-8. Then let Eclipse rebuild the workspace (either automatically if you have that checked, or force a rebuild) and you should be golden!
  
  (thanks to Mark Miller and Erik Hatcher for contributing to this)
@@ -76, +75 @@

  {{{
  BUILD SUCCESSFUL
  }}}
+ all is ok.  but if you see
- all is ok. 
- but if you see
  
  {{{
  BUILD FAILED
  }}}
- 
  please, read carefully the errors messages and check your code. If the test fails you may want to repeatedly rerun a single test as you debug and sort out any problems. In which case you could run
  
  {{{
@@ -202, +199 @@

  Setting things up is actually very smooth when it's smooth, especially if the tests have run <G>.
  
  == Eclipse (Galileo, J2EE version 1.2.2.20100217-2310, but any relatively recent Eclipse should do): ==
- 
  Checkout the trunk with subclipse (location: https://svn.apache.org/repos/asf/lucene/dev/trunk), then run 'ant eclipse' and refresh your project.
  
  DO NOT BE SURPRISED IF SOME TESTS FAIL IN THE IDE. There are some anomalies when running Junit tests for these projects in an IDE. Some of them are already cleaned up, but others may still fail when run in an IDE. The definitive case for whether a test fails or not is running it as an Ant task.
  
  === Enabling Assertions for unit tests in Eclipse ===
- 
  By default, Eclipse does not run test with assertions enabled. This causes some tests to run incorrectly in Eclipse and excludes some checks in the source code.
  
  Change this by checking the box "Add '-ea' to VM arguments when creating a new JUnit launch configuration".
@@ -217, +212 @@

  
  === Installing the code style file ===
  Lucene and SOLR have a common code style preferences. Install one in your Eclipse and set it as the default for the project. Do this by:
+ 
-  *Getting the Eclipse code style xml files ([[http://people.apache.org/~rmuir/Eclipse-Lucene-Codestyle.xml|link]]).
+  * Getting the Eclipse code style xml files ([[http://people.apache.org/~rmuir/Eclipse-Lucene-Codestyle.xml|link]]).
-  *In Eclipse, click "Project>>Properties". In the dialog box, click "Java code style>>Formatter". Up in the upper right of the dialog box that comes, click "Configure Workspace Settings". NOTE: you can do this on an individual project basis if you prefer.
+  * In Eclipse, click "Project>>Properties". In the dialog box, click "Java code style>>Formatter". Up in the upper right of the dialog box that comes, click "Configure Workspace Settings". NOTE: you can do this on an individual project basis if you prefer.
  
  You should now be able to click the "import" button, and import the codestyle file you downloaded. Eclipse doesn't immediately show that the selected import is the new code style, but closing the dialog boxes and coming back to the formatter page should allow you to choose it.
  
  Tips:
+ 
+  * For importing code style xml in Eclipse Helios go to Window > Preferences > Java > Code Style > Formatter, Import to import the file.
-  *Under some conditions, I've seen this process have thousands of compile errors, something like "class XXX defined in multiple places". This went away when I highlighted the project and clicked "refresh".
+  * Under some conditions, I've seen this process have thousands of compile  errors, something like "class XXX defined in multiple places". This went  away when I highlighted the project and clicked "refresh".
-  *Think about installing the subclipse plugin, it'll allow you to update your source from within Eclipse. See: http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA
+  * Think about installing the subclipse plugin, it'll allow you to update your source from within Eclipse. See: http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA
-  *You can create patches for the committers to apply from within the IDE easily.
+  * You can create patches for the committers to apply from within the IDE easily.
-  *By and large, you won't "run" a Lucene program, you'll really run unit tests. (Others, please chime in here!!!). The general development cycle for Lucene is to add functionality, add unit tests, make sure all unit tests run and check in (actually, submit a patch to check in, preferably attached to a JIRA issue). There's no "program" that you start up in your IDE to test changes, just use unit tests.
+  * By and large, you won't "run" a Lucene program, you'll really run unit tests. (Others, please chime in here!!!). The general development cycle for Lucene is to add functionality, add unit tests, make sure all unit tests run and check in (actually, submit a patch to check in, preferably attached to a JIRA issue). There's no "program" that you start up in your IDE to test changes, just use unit tests.
  
- Running SOLR in Eclipse:
- See: http://www.lucidimagination.com/developers/articles/setting-up-apache-solr-in-eclipse.
+ Running SOLR in Eclipse: See: http://www.lucidimagination.com/developers/articles/setting-up-apache-solr-in-eclipse.
  
  == Eclipse (using Git) ==
- 
  Work has begun to maintain a Git repository with project settings. It allows a simple "File -> Import... -> Projects from Git" workflow using EGit (version >= 0.9). Currently it's a single Eclipse project compiling Lucene and Solr without errors. It's likely better to have separate projects for proper dependency management. Please contribute!
  
  The repository is available on GitHub (git://github.com/eclipseguru/lucene-solr.git). It can be easily kept in sync with Apache SVN using the Lucene & Solr Git mirror.
  
  == IntelliJ (9.0.X and 10.0.X) ==
- 
  See [[http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ|the Lucene wiki page on configuring IntelliJ]] - it also covers Solr configuration.
  
  == Maven ==
- 
  There is information about using Maven with Solr and Lucene in the source tree, at `dev-tools/maven/README.maven`.  The information differs slightly by code branch.  Here are links to this file for each Solr version:
- 
- ||'''Solr Version'''||'''Link to Lucene/Solr Maven build instructions'''||
+ ||'''Solr Version''' ||'''Link to Lucene/Solr Maven build instructions''' ||
- ||3.1.X||http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/dev-tools/maven/README.maven||
+ ||3.1.X ||http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/dev-tools/maven/README.maven ||
- ||3.2 (unreleased)||http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/dev-tools/maven/README.maven||
+ ||3.2 (unreleased) ||http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/dev-tools/maven/README.maven ||
- ||trunk/4.0 (unreleased)||http://svn.apache.org/repos/asf/lucene/dev/trunk/dev-tools/maven/README.maven||
+ ||trunk/4.0 (unreleased) ||http://svn.apache.org/repos/asf/lucene/dev/trunk/dev-tools/maven/README.maven ||
+ 
+ 
+ 
  
  == One final note ==
- 
  As always, there are gremlins out there.  If you find problems with the information here, and especially if you subsequently find solutions to the problems you find, please either write to the solr-user mailing list or update this page directly so others can benefit.