I just want to see the SolrJ source inside of the main tree as a
package, such that we didn't have this circular dependency stuff and
then I was thinking an ANT task could then generate the current SolrJ
jar file from the main tree, just as it does from the client tree
now. No need to change JAR names, etc. This way, all patches against
SolrJ just need to have a simple search/replace run on them to work
against the move. This also doesn't require any other reworking of
the source trees, which, as you point out, will likely break some
patches.
On Dec 4, 2008, at 4:12 PM, Ryan McKinley wrote:
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
