You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Ryan McKinley <ry...@gmail.com> on 2008/12/04 22:12:10 UTC
Re: Cleaning up a Few things
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
Re: Cleaning up a Few things
Posted by Ryan McKinley <ry...@gmail.com>.
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
>
>
>
>
>
>
>
>
>
>
Re: Cleaning up a Few things
Posted by Grant Ingersoll <gs...@apache.org>.
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
Re: Cleaning up a Few things
Posted by Ryan McKinley <ry...@gmail.com>.
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
>>
>
Re: Cleaning up a Few things
Posted by Grant Ingersoll <gs...@apache.org>.
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
>