-
Notifications
You must be signed in to change notification settings - Fork 20
Integrated Development Environment
Setting up a Development Environment for SolRDF is quite easy. The instructions here are specific for Eclipse but they can be easily translated to other IDEs.
I assume you have installed
- JDK 8
- a recent version of Eclipse, which comes with everything you need for working with SolRDF codebase
- in case you have an old version of Eclipse, you need m2e and eGit or similar plugins
First, if you want or plan to contribute, you should fork this project as a local repository in your GitHub account, otherwise you can simply clone this repository (using command line or eGit perspective facilities)
Once you have the project / repository locally, go to the Java perspective, right click in the project / package explorer and choose
Import >> Maven >> Existing Maven Projects
At the end (probably the very first time there's a bit to wait, Maven will download the required dependencies) you will see three projects in the workspace:
- solrdf: the top level project, which acts as a container for the others
- solrdf-core: this is SolRDF
- solrdf-client: the SolRDF (Java) client library
- solrdf-integration-tests: as the name suggests, this project contains integration tests.
Under the folder
solrdf/src/dev/eclipse
you can find some useful Eclipse launcher configurations:
- build-test-and-install.launch
- install-without-tests.launch
Just right click on one of them and choose
Run as >> ...
The test suite (or a test case) can be also run using
Run / Debug as >> JUnit test
Starting version 5.x (the current version used by SolRDF) Solr is no longer distributed as a .war file. That means it's not possible to run it using things like Cargo. A quick way to work with SolRDF is
- Create a class which extends org.gazzax.labs.solrdf.integration.IntegrationTestSupertypeLayer
- Create a test method
- Put some breakpoints within that method or using a dummy Thread.sleep(10000000L)
public class MyIntegrationTest extends IntegrationTestSupertypeLayer {
@Test
public void foo() throws Exception {
Thread.sleep(10000000000L);
}
}
Then, right click on that class and select
Debug as >> JUnit Test
As part of the test execution Solr will be (downloaded and) started. You should see something like this in the console:
13:37 INFO Looking for old index directories to cleanup for core store in /tmp/.../store/data/
13:37 INFO no updateRequestProcessorChain defined as default, creating implicit default
13:37 INFO Using default statsCache cache: org.apache.solr.search.stats.LocalStatsCache
13:37 INFO Hard AutoCommit: if uncommited for 15000ms;
...
13:37 INFO newest commit generation = 1
13:37 INFO [store] Registered new searcher Searcher@4b6c3178[store]
At this point SolRDF is running in debug mode, so that means you can index, search and put some breakpoints somewhere (in SolRDF or in Solr classes)
Follow the procedure described in this page on top of a forked repository; then, once your changes are ready, create a PullRequest and follow the procedure.
1. Introduction
2. User Guide
2.1 Get me up and running
2.2 Add Data
2.3 RDF Mode
2.3.1 SPARQL 1.1 Protocol
2.3.1.1 Query
2.3.1.2 Update
2.3.3 Graph Store Protocol
2.4 Hybrid mode
2.4.1 Querying
2.4.2 Faceted search
2.4.2.1 Fields
2.4.2.2 Objects queries
2.4.2.3 Objects ranges queries
2.5 Deployments
2.6.1 Standalone
2.6.2 SolrCloud
2.6 Message Catalog
3. Developer Guide
3.1 Development Environment
3.2 (Java) Client API
3.3 Solr Configuration
3.3.1 schema.xml
3.3.2 solrconfig.xml
3.4 Components
3.4.1 Stream Loader
3.4.2 Query Parser
3.4.3 Search Component
3.4.4 Facet Component
3.4.5 Response Writer
4. Continuous Integration
5. Roadmap
6. Mailing lists