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
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
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
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)
Yeah, -1 on Ant as a prerequisite, even though I use Ant to do this
kind of stuff all the time. java -jar start.jar is pretty nice.
On Nov 24, 2008, at 7:59 PM, Chris Hostetter wrote:
: Or we could switch to using an ant task to start/run the examples.
That would make ant a requirement
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
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
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
: The structure we had made some sense before solrj because a dependancy on
: core. Specifically I think we should have:
:
: src/solrj (this will have common client/src/solrj/*)
the name solrj seems odd in that case ... common seems like it would
make more sense, since it's code that is
On Nov 24, 2008, at 4:59 PM, Chris Hostetter wrote:
: The structure we had made some sense before solrj because a
dependancy on
: core. Specifically I think we should have:
:
: src/solrj (this will have common client/src/solrj/*)
the name solrj seems odd in that case ... common seems
On Nov 24, 2008, at 4:59 PM, Chris Hostetter wrote:
perhaps...
examples/README.txt
examples/start.jar
examples/post.jar
examples/simple/solr/conf
examples/simple/README.txt
examples/simple/raw-data
examples/multicore/...
examples/exampleAnalysis/...
...where each subdir of examples can be
: The dependency graph looks like:
: common solrj solr servlet
: (while EmbeddedSolrServer depend on solr)
:
: calling common+solrj common is a little strange because it would not be
: common to anything anymore: it is the client.
it would be common to clients and servers ... if you call it
: The only gotcha, I feel, is that I don't want people to have to type
: solr.solr.home (I hate to have to explain why it's solr.solr, too, but
: that's another day...) for the simple example. I know, it's not a big deal,
: but java -jar start.jar is brilliantly simple. I'm no Jetty wiz, but if
On Nov 24, 2008, at 7:11 PM, Chris Hostetter wrote:
: The only gotcha, I feel, is that I don't want people to have to type
: solr.solr.home (I hate to have to explain why it's solr.solr,
too, but
: that's another day...) for the simple example. I know, it's not a
big deal,
: but java
: Or we could switch to using an ant task to start/run the examples.
That would make ant a requirement for solr users, currently people who
download the binary distributions don't need to know about ant at all.
(i'm not saying we can't make it easy to pick confs with ant
run-example but it
15 matches
Mail list logo