/lucene/queryParser/
> svn move
> lucene/contrib/surround/src/test/org/apache/lucene/queryParser/surround
> lucene/contrib/queryparser/src/test/org/apache/lucene/queryParser/
> svn move lucene/contrib/surround/README.txt lucene/contrib/queryparser
> svn delete lucene/c
/queryparser/src/test/org/apache/lucene/queryParser/
svn move lucene/contrib/surround/README.txt lucene/contrib/queryparser
svn delete lucene/contrib/surround
{noformat}
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
>
/lucene/analysis/wikipedia
svn rm lucene/contrib/wikipedia
{code}
if no one objects, I would like to commit this soon.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/bro
+1 for basic analyzers in core and TestAnalyzer. Though that's what I
suggested last time it was discussed and the response I got was that
Lucene should offer out of the box great analyzer and does not require
additional modules. If we move all useful ones to modules, users will
need to dow
On Fri, Mar 26, 2010 at 12:03 PM, Uwe Schindler wrote:
> And in my opinion we should fork a 3.1 branch before!
>
> Uwe
>
yeah we don't need to rush into it. we could create a module that is
contrib + solr as a first step.
this could also work for the spatial situation.
--
Robert Muir
rcm...@gma
a bundle...
On tests... I wouldn't mind if core tests (but not core itself)
depended on modules. I don't think that's bad... the tests will need
a query parser, queries, analyzers. Making test-only variants (eg a
TestAnalyzer) is OK but I worry that this'd promote homogeneity in o
And in my opinion we should fork a 3.1 branch before!
Uwe
> -Original Message-
> From: Mark Miller [mailto:markrmil...@gmail.com]
> Sent: Friday, March 26, 2010 4:59 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Modules
>
> I also like the idea of a very b
analyzer set (without Standard!!!).
Uwe
-Original Message-
From: Shai Erera [mailto:ser...@gmail.com]
Sent: Friday, March 26, 2010 4:16 PM
To: java-dev@lucene.apache.org
Subject: Re: Modules
+1 for moving modules up one level.
As for analyzers, I also prefer if lucene won't depe
That will be also heavy ANT build refactoring (oh no...). But I am also for a
basic analyzer set (without Standard!!!).
Uwe
> -Original Message-
> From: Shai Erera [mailto:ser...@gmail.com]
> Sent: Friday, March 26, 2010 4:16 PM
> To: java-dev@lucene.apache.org
> Subje
On Fri, Mar 26, 2010 at 18:24, Robert Muir wrote:
> I would really love to see them all in one place though, for the
> users. I think that the elegance of our tests should be second to the
> users ease.
> Perhaps we could just have a fast and dirty TestAnalyzer so the core
> tests don't need to de
n 3/26/10 7:16 AM, Grant Ingersoll wrote:
So, should we start thinking about a Modules dir at the same level as
Lucene/Solr where shared, non-core code lives?
For starters, I think spatial and analyzers could go there.
Proposal:
lucene/
solr/
modules/
analyzers
spatial
others
2010/3/26 Shai Erera :
> +1 for moving modules up one level.
>
> As for analyzers, I also prefer if lucene won't depend on modules even
> if just for the tests. That way one who doesn't use any module can
> check out lucene only. We can keep in lucene some basic analyzers
+1 for moving modules up one level.
As for analyzers, I also prefer if lucene won't depend on modules even
if just for the tests. That way one who doesn't use any module can
check out lucene only. We can keep in lucene some basic analyzers
(Whitespace, Simple) as well as a best out
> Sounds good to me. I guess one thing to think about is the analyzers
> in core (should they move to this module, too?).
> If so, perhaps we could make 'ant test' of lucene depend on this
> module, since core tests use analyzers.
> But you could use lucene without an analyzers module, it wouldnt b
On Fri, Mar 26, 2010 at 10:16 AM, Grant Ingersoll wrote:
> So, should we start thinking about a Modules dir at the same level as
> Lucene/Solr where shared, non-core code lives?
>
> For starters, I think spatial and analyzers could go there.
>
> Proposal:
>
> l
So, should we start thinking about a Modules dir at the same level as
Lucene/Solr where shared, non-core code lives?
For starters, I think spatial and analyzers could go there.
Proposal:
lucene/
solr/
modules/
analyzers
spatial
others (highlighter, faceting, ...)
I guess in some
solr piece).
Will keep the issue open and work on a patch for the next part.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
Hoss Man)
I really have no opinions, I was just trying to chime in with my memories of
hte past discussions -- i don't necessarily think one way or another is more
good/bad right/wrong.
go with your gut.
> reorganize contrib modules
> --
>
>
d to the query parsers, too?
Yes, I think we want to do this. I can do it in the second patch with the other
moves.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira
the query parsers, too?
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
> Issue Type: Improvement
>
e/contrib/queryparser/src/test/org/apache/lucene/queryParser
{noformat}
If no one objects, (especially including Hoss Man), I would like to commit in
a day or two, but keeping the issue open, and doing the more complex ones
next.
> reorganize contrib modules
> --
>
>
[
https://issues.apache.org/jira/browse/LUCENE-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir reassigned LUCENE-2323:
---
Assignee: Robert Muir
> reorganize contrib modu
b is to a certain degree of maturity, I feel we should
organize
it by functionality. Its easy for the users, and it invites the sort of
refactoring and
cleanup that some of this code needs.
{quote}
+1
> reorganize contrib modules
> --
>
>
vites the sort of
refactoring and
cleanup that some of this code needs.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
&g
nk of for that Locale. That's
(to me) a great service to our users, and I don't see how we can do that if all
analyzers are under different modules. Besides, analyzers are logically close
to each other because they perform a very specific task. Refactoring the
analysis API again would be ea
needs to be done first.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
> Issue Type: Improvement
> Componen
inking of...
http://old.nabble.com/New-flexible-query-parser-to22549684.html#a22637326
("kitchen sink" was the search term i was looking for)
...but i don't think that was the first time it came up.
> reorganize contrib modules
> --
>
trib IMO!
+1
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
> Issue Type: Improvement
>
this discussion was the have a lot more smaller
"modules", with a lot better defined/advertised dependencies, so that module
X,Y,Z might all depend on modules A, and B (which had the common refactored
code you speak of)
{quote}
I didn't know this was the goal, if what you say is true
ur 7 queryparsers or 2
highlighters or whatever, the only way I can do this is to shove stuff (shared
code) into core, I think this is bad.
agreed ... IIRC the idea in this discussion was the have a lot more smaller
"modules", with a lot better defined/advertised dependencies, so that
ged, this proposal was
supposed to be
a small step towards modules.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
>
n on this, but i wanted to point it out
for completeness:
the last time i remember a big discussion about reorging contribs, there seemed
to be a strong sentiment that we should be striving for more "small"
contribs/modules -- specificly in terms of artifact size/complexity. I think
o
olve Solr, too.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
> Issue Type: Improvement
> Components
eful to run by some jdepend
reports at - http://clarkware.com/software/JDepend.html , as a metric for the
stability of the packages.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org
ackage name.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
> Issue Type: Improvement
> Components:
ghts on this.
+1, I think this initial re-org is great Robert!
I think it'd be OK to rename XML QP and Wikipedia as well. Surround does seem
trickier... maybe leave that for now.
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
first part, which has no pkg naming changes?
> reorganize contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
> Issu
contrib modules
> --
>
> Key: LUCENE-2323
> URL: https://issues.apache.org/jira/browse/LUCENE-2323
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/*
>Report
[
https://issues.apache.org/jira/browse/LUCENE-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845115#action_12845115
]
Shai Erera commented on LUCENE-2323:
That'd be great !
> reorganize con
reorganize contrib modules
--
Key: LUCENE-2323
URL: https://issues.apache.org/jira/browse/LUCENE-2323
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/*
Reporter: Robert Muir
[
http://jira.nuxeo.org/browse/NXP-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéfane Fermigier updated NXP-2165:
---
Fix Version/s: (was: 5.1.4)
5.1.5
> Java6 -wrong modules dependec
If there is a policy, you can bet its a conservative one but this is ASF
software, so I think licenses aren't needed.
Otis
- Original Message
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Monday, October 23, 2006 8:45:50 PM
Subject: Cont
OK, I am putting finishing touches on benchmark contribution and was
wondering about 3rd party licenses. Namely, I used Digester for some
configuration stuff and was wondering if I need to include the
Digester license (and the other affiliated licenses) in the lib
directory or are these "s
43 matches
Mail list logo
