[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-09-17 Thread Martijn van Groningen (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456882#comment-13456882
 ] 

Martijn van Groningen commented on LUCENE-3997:
---

Steven, I think this is a good idea for the reasons you mentioned. I think the 
new shared module should be named 'parent-child'. This name describes the 
overlapping functionality both existing modules have.
 
Directory layout:
{code}
-- lucene
|
|--- parent-child
| |
| |--- grouping
| |
| |--- join
|
|--- ...
{code}  

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 4.0-ALPHA
Reporter: Robert Muir
 Fix For: 4.1

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-09-17 Thread Chris Male (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456892#comment-13456892
 ] 

Chris Male commented on LUCENE-3997:


bq. I propose, instead of using lucene-core as the location for code used by 
multiple modules, that we create a (single) new module that serves this 
purpose, something like lucene-shared or lucene-common (though common analyzers 
already use this name...)

I actually created lucene-common that when I first refactored out the 
FunctionQuery codebase.  After some time it was decided (in an issue I can't 
remember) that the code would go into lucene-core.  I agree with your 
assessment that we shouldn't use lucene-core as a dumping ground, but we should 
get a discussion about this going.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 4.0-ALPHA
Reporter: Robert Muir
 Fix For: 4.1

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-09-17 Thread Robert Muir (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456954#comment-13456954
 ] 

Robert Muir commented on LUCENE-3997:
-

Can we please not add more modules here. I'm against that, this is crazy: its 
only a few classes in question already. it doesnt need 3 modules...

the purpose of this issue was to help simplify modules and dependencies, not 
make it worse.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 4.0-ALPHA
Reporter: Robert Muir
 Fix For: 4.1

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-09-17 Thread Michael McCandless (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456966#comment-13456966
 ] 

Michael McCandless commented on LUCENE-3997:


I think moving TopGroups/GroupDocs to core is fine.  Pragmatism over purity.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 4.0-ALPHA
Reporter: Robert Muir
 Fix For: 4.1

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-09-14 Thread Steven Rowe (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455896#comment-13455896
 ] 

Steven Rowe commented on LUCENE-3997:
-

I propose, instead of using lucene-core as the location for code used by 
multiple modules, that we create a (single) new module that serves this 
purpose, something like lucene-shared or lucene-common (though common analyzers 
already use this name...).

That way the number of inter-module dependencies is limited, and lucene-core 
doesn't get roped into the act.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 4.0-ALPHA
Reporter: Robert Muir
 Fix For: 4.1

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-22 Thread Michael McCandless (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259074#comment-13259074
 ] 

Michael McCandless commented on LUCENE-3997:


I don't think we should combine the two modules.

While they do share a couple classes (to represent a 'grouped' result), the two 
functions (joining and grouping) are really orthogonal: you can join w/o doing 
grouping, and you can group w/o doing joining.

I think we should move TopGroups/GroupDocs to core.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-22 Thread Chris Male (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259075#comment-13259075
 ] 

Chris Male commented on LUCENE-3997:


To me they seem to share a lot of similarities and the fact they both use the 
'grouped' result notion is an illustration of that.  

While a group could consist of Documents with any kind of relationship, that 
kind of a relationship could be parent-child.  The nature of the relationship 
and what the result should consist of (if its a parent-child relationship, 
should the 'grouped' result be parent and children, just children or just the 
parent) seem to be what dictates the implementations used.  

I feel that having them as a single module would allow us to build some APIs 
which focus on user land concepts and perhaps hide some of the implementation 
details and differences in the joining and grouping algorithms.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-21 Thread Martijn van Groningen (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258822#comment-13258822
 ] 

Martijn van Groningen commented on LUCENE-3997:
---

The reason that joining and grouping are different modules is that these are 
different functionalities. However these functionalities do overlap a bit with 
each other. Both joining and grouping can be used for a parent child like 
search. I'm not sure what would be a good option. Joining does use grouping's 
TopGroups and GroupDocs... If we are going to have a combined module maybe we 
should name it relational module or parent child module?

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-19 Thread Chris Male (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257942#comment-13257942
 ] 

Chris Male commented on LUCENE-3997:


I do echo Yonik's concern here, I don't think we should prevent inter-module 
dependencies.  I think if we move something to lucene/core, it should be 
because we think its a core API/concept, not just because its used by multiple 
modules.  Analyzer fits into that category, it belongs in core because it is a 
core concept.  

Do we feel the same about TopGroups and GroupDocs? I kind of think we do.  But 
we should move them for that reason, not just to remove the dependency.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-19 Thread Chris Male (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257948#comment-13257948
 ] 

Chris Male commented on LUCENE-3997:


{quote}
Of course, another option is to combine grouping and join into one module, but
last time i brought that up nobody could agree on a name.
{quote}

If that is the better option, lets do that.  The name seems less important at 
this stage, we can call it grouping-join if needs be.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-18 Thread Robert Muir (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256577#comment-13256577
 ] 

Robert Muir commented on LUCENE-3997:
-

Sorry for the duplicate upload... jira was going nutso on me

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-18 Thread Martijn van Groningen (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256740#comment-13256740
 ] 

Martijn van Groningen commented on LUCENE-3997:
---

+1! Good idea. Maybe we can move FunctionValues and ValueSource from the 
queries modules to core? Then grouping module doesn't have to depend on the 
queries module.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-18 Thread Robert Muir (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256744#comment-13256744
 ] 

Robert Muir commented on LUCENE-3997:
-

{quote}
Maybe we can move FunctionValues and ValueSource from the queries modules to 
core? Then grouping module doesn't have to depend on the queries module.
{quote}

+1 (I didn't even think of that or investigate it yet though, but at a glance 
it looks like the right thing to do).


 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-18 Thread Yonik Seeley (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256765#comment-13256765
 ] 

Yonik Seeley commented on LUCENE-3997:
--

I think that if you try to make no modules depend on other modules, you'll end 
up just pulling pretty much everything into core.

Also, the function query stuff is supposed to be marked as experimental - the 
notice only got added to FunctionQuery (I think?), so it should be applied to 
FunctionValues and ValueSource if they are moved to core.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-18 Thread Robert Muir (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256772#comment-13256772
 ] 

Robert Muir commented on LUCENE-3997:
-

{quote}
I think that if you try to make no modules depend on other modules, you'll end 
up just pulling pretty much everything into core.
{quote}

I don't think we should pull everything into core, but if we pull in the simple 
abstract APIs we can 
have a more pluggable API: just like the abstract Analyzer api is in core, 
which Highlighter uses,
but you can highlight UIMA or Japanese or ICU or whatever analyzers this way...



 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-18 Thread Martijn van Groningen (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256931#comment-13256931
 ] 

Martijn van Groningen commented on LUCENE-3997:
---

I also think we can move these classes to core. These are small classes and we 
can mark these classes as experimental.   

Maybe we can even make this classes 'lighter' by only moving the public methods 
to core (maybe as interface?). E.g. ValueSource would have all the public 
methods in core and a BaseValueSource (Or AbstractValueSource) in the queries 
module that contains ValueSourceComparatorSource and ValueSourceComparator. 
Just an idea.

I'll create a new issue to not make grouping module depend on the queries 
module.

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module

2012-04-18 Thread Michael McCandless (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257191#comment-13257191
 ] 

Michael McCandless commented on LUCENE-3997:


+1

 join module should not depend on grouping module
 

 Key: LUCENE-3997
 URL: https://issues.apache.org/jira/browse/LUCENE-3997
 Project: Lucene - Java
  Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3997.patch, LUCENE-3997.patch


 I think TopGroups/GroupDocs should simply be in core? 
 Both grouping and join modules use these trivial classes, but join depends on 
 grouping just for them.
 I think its better that we try to minimize these inter-module dependencies.
 Of course, another option is to combine grouping and join into one module, but
 last time i brought that up nobody could agree on a name. 
 Anyway I think the change is pretty clean: its similar to having basic stuff 
 like Analyzer.java in core,
 so other things can work with Analyzer without depending on any specific 
 implementing modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org