So do we want to move forward on this?

IIUC, we all agree it should happen, the issues are just what the specific names should be.

We have a few components:
1. 'common' code that does not depend on anything (even lucene)
2. 'client' (solrj) code that depends on 'common'
3. 'server' (solr) code that depends on #1 and #2
4. webapp code that depends on everything + javax.servlet
  4.a -- embedded solrj code

While we could separate this into 4 jar files (in maven that might be a good idea), I think two jar files makes the most sense:

solr-{solrj/client}.jar = #1 + #2
solr-{server?}.jar = #3 + #4

In my view the most reasonable jar file names would be:
 solr-solrj-1.x.jar
 solr-1.x.jar

Alternativly, this could be:
 solr-client-1.x.jar
 solr-server-1.x.jar

I like the names that avoid using 'client' and 'server' since it gets a bit strange when you say the server depends on the client.

Even if we package as two jar files, I think we should have 4 src directories to keep the dependancies clean:

Ideally this would be:
/src/main/java/common
/src/main/java/solrj
/src/main/java/solr
/src/main/java/web
/src/main/webapp/... jsp stuff here

However that my be more pain for existing patches then it is worth. With that in mind I suggest:
/src/common
/src/solrj
/src/java (no change)
/src/webapp/src (no change)

thoughts?

ryan





On Nov 24, 2008, at 3:16 PM, Grant Ingersoll wrote:

I was wondering what people thought of the following things that have been bothering me, off and on, for a while.

1. Let's bring SolrJ into the core and have, as part of the release packaging, a target that builds a standalone SolrJ jar for distribution. Right now, we have circular dependencies between the core and SolrJ such that I think it makes it painful to startup a project in Eclipse or IntelliJ which thus makes it just that little bit more difficult for new people to understand and contribute to Solr. Besides, SolrJ is used by distributed search and is thus "core"

2. Likewise, let's refactor the appropriate servlet dependencies such that it is in the core lib, but excluded from packaging, and then utilized/copied out to the example where needed. I think these are just the servlet apis used by the webapp part of the code.

The goal of both 1 and 2 is to have the core only depend on the lib directory for dependencies such that people need only point their IDE at the core/lib directory to get up and compiling/contributing, etc.

I also think we could stand to simplify the example directory quite a bit. Not quite sure what to do there just yet. While the original "example" is still pretty easy to use, I think it's confused by the proliferation (of which I am guilty) of other "examples" that are thrown into the directory.

Thoughts?

Cheers,
Grant

Reply via email to