sounds good. Check:
https://issues.apache.org/jira/browse/SOLR-900
On Dec 6, 2008, at 7:30 PM, Grant Ingersoll wrote:
I was only suggesting SolrJ into core, b/c it is core. In other
words, distributed search doesn't work with out it and dist. search
is part of core, therefore SolrJ belongs in core.
That being said, I'm fine w/ 2 as well.
One other thing that is getting unwieldy, IMO, is the Analysis
package. Might make sense to create some subpackages.
On Dec 5, 2008, at 5:39 PM, Ryan McKinley wrote:
I suppose bunching it all together is easiest, but it makes the
dependencies less clear and makes it easy to accidently introduce
unwanted dependencies. This is why the webapp stuff is currently
in its own directory.
Moving solrj and common to a sibling directories would also just be
a simple search and replace to get 'update' patches. It would also
clearly segregate the dependencies.
I did suggest keeping the names as they are --however we could
possibly roll "common" into solrj.jar.
Essentially the question becomes:
1. Do we want everything together (except webapp)
2. Do we want each set of code with discrete dependencies to have
its own src folder.
Either way is fine my be, but option 2 seems 'cleaner'
ryan
On Dec 5, 2008, at 11:06 AM, Grant Ingersoll wrote:
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
--------------------------
Grant Ingersoll
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
