lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Update of "HowToContribute" by VarunThacker
Date Mon, 16 May 2011 16:24:08 GMT
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.
  

Mime
View raw message