[jira] [Commented] (SOLR-2573) Standard handler assumed as default in test breaks subclassing tests
[
https://issues.apache.org/jira/browse/SOLR-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1306#comment-1306
]
Gabriele Kahlout commented on SOLR-2573:
some test classes may have to be adjusted too? (I don't know how they currently
work).
{code}
public class AlternateDirectoryTest extends SolrTestCaseJ4 {
@BeforeClass
public static void beforeClass() throws Exception {
initCore("solrconfig-altdirectory.xml", "schema.xml");
}
/**
* Simple test to ensure that alternate IndexReaderFactory is being used.
*
* @throws Exception
*/
@Test
public void testAltDirectoryUsed() throws Exception {
assertQ(req("q","*:*","qt","standard")); //STANDARD DOESN'T EXIST ANYMORE
{code}
> Standard handler assumed as default in test breaks subclassing tests
>
>
> Key: SOLR-2573
> URL: https://issues.apache.org/jira/browse/SOLR-2573
> Project: Solr
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.4
>
> Attachments: SOLR-2573.patch
>
>
> 'standard' is still specified as default qtype in TestHarness and
> SolrTestCaseJ4, which makes tests that rely on the default fail.
--
This message is automatically generated by JIRA.
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] [Updated] (SOLR-2573) Standard handler assumed as default in test breaks subclassing tests
[ https://issues.apache.org/jira/browse/SOLR-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriele Kahlout updated SOLR-2573: --- Fix Version/s: 3.4 Affects Version/s: 3.2 > Standard handler assumed as default in test breaks subclassing tests > > > Key: SOLR-2573 > URL: https://issues.apache.org/jira/browse/SOLR-2573 > Project: Solr > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Gabriele Kahlout >Priority: Minor > Fix For: 3.4 > > Attachments: SOLR-2573.patch > > > 'standard' is still specified as default qtype in TestHarness and > SolrTestCaseJ4, which makes tests that rely on the default fail. -- This message is automatically generated by JIRA. 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] [Closed] (SOLR-2645) NullPointerException in StopFilter
[
https://issues.apache.org/jira/browse/SOLR-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriele Kahlout closed SOLR-2645.
--
Resolution: Invalid
> NullPointerException in StopFilter
> --
>
> Key: SOLR-2645
> URL: https://issues.apache.org/jira/browse/SOLR-2645
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 3.3
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.4
>
> Attachments: SolrAddBug.zip
>
>
> To reproduce:
> Download and unzip attached and from the extracted directory run: {code} mvn
> test {code}
> {code}
> java.lang.NullPointerException
> at org.apache.lucene.analysis.CharArraySet.(CharArraySet.java:91)
> at org.apache.lucene.analysis.StopFilter.(StopFilter.java:101)
> at org.apache.lucene.analysis.StopFilter.(StopFilter.java:93)
> at
> org.apache.solr.analysis.StopFilterFactory.create(StopFilterFactory.java:84)
> at
> org.apache.solr.analysis.StopFilterFactory.create(StopFilterFactory.java:43)
> at
> org.apache.solr.analysis.TokenizerChain.getStream(TokenizerChain.java:71)
> at
> org.apache.solr.analysis.SolrAnalyzer.reusableTokenStream(SolrAnalyzer.java:75)
> at
> org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.reusableTokenStream(IndexSchema.java:385)
> at
> org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:126)
> at
> org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:278)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:766)
> at
> org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2056)
> at
> org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2030)
> at com.mysimpatico.solraddbug.SolrTest.test(SolrTest.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
> at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1277)
> at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1195)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
> at $Proxy0.invoke(Unknown Source)
> at
> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
> at
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
> at
> org.apache.maven.surefire.booter.ForkedBo
[jira] [Commented] (SOLR-2645) NullPointerException in StopFilter
[
https://issues.apache.org/jira/browse/SOLR-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062745#comment-13062745
]
Gabriele Kahlout commented on SOLR-2645:
Well, then would you tell me what would be a full instance !strange setup?
I'm trying to test Solr using 'transparent' API classes from lucene (such as
IndexWriter), and the following is the starting point:
{code}
public class SolrTest extends SolrTestCaseJ4 {
public static String TEST_HOME() {
return new File("target/test-classes/solr").getPath(); //in here I've a
copy paste of solr default conf, and data (empty).
}
public SolrTest() {
try {
File conf = new File(TEST_HOME(), "conf");
initCore(new File(conf, "solrconfig.xml").getPath(), new File(conf,
"schema.xml").getPath());
} catch (Exception e) {
Logger.getLogger(SolrTest.class.getName()).log(Level.FINE,
"message", e);
fail(e.getLocalizedMessage());
}
}
@Test
public void test() throws IOException {
final IndexWriter writer = new IndexWriter(FSDirectory.open(new
File(dataDir,"index")), new IndexSchema(solrConfig,
schemaString).getAnalyzer(), IndexWriter.MaxFieldLength.LIMITED);
final Document doc = new Document();
doc.add(new Field("content", "essen fressen essen", Field.Store.YES,
Field.Index.ANALYZED)); //FIXME
writer.addDocument(doc);
writer.commit();
}
}
{code}
> NullPointerException in StopFilter
> --
>
> Key: SOLR-2645
> URL: https://issues.apache.org/jira/browse/SOLR-2645
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 3.3
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.4
>
> Attachments: SolrAddBug.zip
>
>
> To reproduce:
> Download and unzip attached and from the extracted directory run: {code} mvn
> test {code}
> {code}
> java.lang.NullPointerException
> at org.apache.lucene.analysis.CharArraySet.(CharArraySet.java:91)
> at org.apache.lucene.analysis.StopFilter.(StopFilter.java:101)
> at org.apache.lucene.analysis.StopFilter.(StopFilter.java:93)
> at
> org.apache.solr.analysis.StopFilterFactory.create(StopFilterFactory.java:84)
> at
> org.apache.solr.analysis.StopFilterFactory.create(StopFilterFactory.java:43)
> at
> org.apache.solr.analysis.TokenizerChain.getStream(TokenizerChain.java:71)
> at
> org.apache.solr.analysis.SolrAnalyzer.reusableTokenStream(SolrAnalyzer.java:75)
> at
> org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.reusableTokenStream(IndexSchema.java:385)
> at
> org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:126)
> at
> org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:278)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:766)
> at
> org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2056)
> at
> org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2030)
> at com.mysimpatico.solraddbug.SolrTest.test(SolrTest.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
> at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1277)
> at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1195)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runner
[jira] [Updated] (SOLR-2645) NullPointerException in StopFilter
[
https://issues.apache.org/jira/browse/SOLR-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriele Kahlout updated SOLR-2645:
---
Attachment: SolrAddBug.zip
runnable test with mvn test
> NullPointerException in StopFilter
> --
>
> Key: SOLR-2645
> URL: https://issues.apache.org/jira/browse/SOLR-2645
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 3.3
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.4
>
> Attachments: SolrAddBug.zip
>
>
> To reproduce:
> Download and unzip attached and from the extracted directory run: {code} mvn
> test {code}
> {code}
> java.lang.NullPointerException
> at org.apache.lucene.analysis.CharArraySet.(CharArraySet.java:91)
> at org.apache.lucene.analysis.StopFilter.(StopFilter.java:101)
> at org.apache.lucene.analysis.StopFilter.(StopFilter.java:93)
> at
> org.apache.solr.analysis.StopFilterFactory.create(StopFilterFactory.java:84)
> at
> org.apache.solr.analysis.StopFilterFactory.create(StopFilterFactory.java:43)
> at
> org.apache.solr.analysis.TokenizerChain.getStream(TokenizerChain.java:71)
> at
> org.apache.solr.analysis.SolrAnalyzer.reusableTokenStream(SolrAnalyzer.java:75)
> at
> org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.reusableTokenStream(IndexSchema.java:385)
> at
> org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:126)
> at
> org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:278)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:766)
> at
> org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2056)
> at
> org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2030)
> at com.mysimpatico.solraddbug.SolrTest.test(SolrTest.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
> at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1277)
> at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1195)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
> at $Proxy0.invoke(Unknown Source)
> at
> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
> at
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
> at
> or
[jira] [Created] (SOLR-2645) NullPointerException in StopFilter
NullPointerException in StopFilter
--
Key: SOLR-2645
URL: https://issues.apache.org/jira/browse/SOLR-2645
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 3.3
Reporter: Gabriele Kahlout
Priority: Minor
Fix For: 3.4
To reproduce:
Download and unzip attached and from the extracted directory run: {code} mvn
test {code}
{code}
java.lang.NullPointerException
at org.apache.lucene.analysis.CharArraySet.(CharArraySet.java:91)
at org.apache.lucene.analysis.StopFilter.(StopFilter.java:101)
at org.apache.lucene.analysis.StopFilter.(StopFilter.java:93)
at
org.apache.solr.analysis.StopFilterFactory.create(StopFilterFactory.java:84)
at
org.apache.solr.analysis.StopFilterFactory.create(StopFilterFactory.java:43)
at
org.apache.solr.analysis.TokenizerChain.getStream(TokenizerChain.java:71)
at
org.apache.solr.analysis.SolrAnalyzer.reusableTokenStream(SolrAnalyzer.java:75)
at
org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.reusableTokenStream(IndexSchema.java:385)
at
org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:126)
at
org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:278)
at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:766)
at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2056)
at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:2030)
at com.mysimpatico.solraddbug.SolrTest.test(SolrTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1277)
at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1195)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
{code}
--
This message is automatically generated by JIRA.
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...@lucen
[jira] [Commented] (SOLR-2574) Add SLF4J-nop dependency
[
https://issues.apache.org/jira/browse/SOLR-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048666#comment-13048666
]
Gabriele Kahlout commented on SOLR-2574:
thank you, what about 3_x branch?
> Add SLF4J-nop dependency
>
>
> Key: SOLR-2574
> URL: https://issues.apache.org/jira/browse/SOLR-2574
> Project: Solr
> Issue Type: Bug
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 4.0
>
> Attachments: solrjtest.zip
>
>
> Whatever the merits of slf4j, a quick solrj test should work.
> I've attached a sample 1-line project with dependency on solrj-3.2 on run it
> prints:
> {code}
> java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
> at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
> at com.mysimpatico.solrjtest.App.main(App.java:12)
> {code}
> Uncomment the nop dependency and it will work.
--
This message is automatically generated by JIRA.
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] (SOLR-2574) Add SLF4J-nop dependency
[
https://issues.apache.org/jira/browse/SOLR-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044635#comment-13044635
]
Gabriele Kahlout commented on SOLR-2574:
Nice, so the fix proposed would be to upgrade to SLF4J 1.6.
> Add SLF4J-nop dependency
>
>
> Key: SOLR-2574
> URL: https://issues.apache.org/jira/browse/SOLR-2574
> Project: Solr
> Issue Type: Bug
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 1.4
>
> Attachments: solrjtest.zip
>
>
> Whatever the merits of slf4j, a quick solrj test should work.
> I've attached a sample 1-line project with dependency on solrj-3.2 on run it
> prints:
> {code}
> java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
> at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
> at com.mysimpatico.solrjtest.App.main(App.java:12)
> {code}
> Uncomment the nop dependency and it will work.
--
This message is automatically generated by JIRA.
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] [Issue Comment Edited] (SOLR-2574) Add SLF4J-nop dependency
[
https://issues.apache.org/jira/browse/SOLR-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044592#comment-13044592
]
Gabriele Kahlout edited comment on SOLR-2574 at 6/5/11 6:00 PM:
{quoute} I'm not sure that is great behavior – the point of SLF4j to let people
choose what framework to use... {quote}
It'd make some sense if I'm re-building solrj, but as a client that (to me)
totally unacceptable. If slf4j is such a great thing, that's ! the way to
promote it, you get a build failure because of this slf4j and then go figure
out the 'simplest thing that could possible work'[Extreme Programming].
I'm !alone with the issue, others have posted about it (I'm the one taking the
time to post an issue).
was (Author: simpatico):
{quoute} I'm not sure that is great behavior – the point of SLF4j to let
people choose what framework to use... {quote}
It'd make some sense if I'm re-building solrj, but as a client that (to me)
totally unacceptable. If slf4j is such a great thing, that's ! the way to
promote it, you get a build failure because of this slf4j and then go figure
out the 'simplest thing that could possible work'[Extreme Programming].
I'm ! alone with the issue, others have posted about it (I'm the one taking the
time to post an issue).
> Add SLF4J-nop dependency
>
>
> Key: SOLR-2574
> URL: https://issues.apache.org/jira/browse/SOLR-2574
> Project: Solr
> Issue Type: Bug
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 1.4
>
> Attachments: solrjtest.zip
>
>
> Whatever the merits of slf4j, a quick solrj test should work.
> I've attached a sample 1-line project with dependency on solrj-3.2 on run it
> prints:
> {code}
> java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
> at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
> at com.mysimpatico.solrjtest.App.main(App.java:12)
> {code}
> Uncomment the nop dependency and it will work.
--
This message is automatically generated by JIRA.
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] (SOLR-2574) Add SLF4J-nop dependency
[
https://issues.apache.org/jira/browse/SOLR-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044592#comment-13044592
]
Gabriele Kahlout commented on SOLR-2574:
{quoute} I'm not sure that is great behavior – the point of SLF4j to let people
choose what framework to use... {quote}
It'd make some sense if I'm re-building solrj, but as a client that (to me)
totally unacceptable. If slf4j is such a great thing, that's ! the way to
promote it, you get a build failure because of this slf4j and then go figure
out the 'simplest thing that could possible work'[Extreme Programming].
I'm ! alone with the issue, others have posted about it (I'm the one taking the
time to post an issue).
> Add SLF4J-nop dependency
>
>
> Key: SOLR-2574
> URL: https://issues.apache.org/jira/browse/SOLR-2574
> Project: Solr
> Issue Type: Bug
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 1.4
>
> Attachments: solrjtest.zip
>
>
> Whatever the merits of slf4j, a quick solrj test should work.
> I've attached a sample 1-line project with dependency on solrj-3.2 on run it
> prints:
> {code}
> java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
> at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
> at com.mysimpatico.solrjtest.App.main(App.java:12)
> {code}
> Uncomment the nop dependency and it will work.
--
This message is automatically generated by JIRA.
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] [Updated] (SOLR-2574) Add SLF4J-nop dependency
[
https://issues.apache.org/jira/browse/SOLR-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriele Kahlout updated SOLR-2574:
---
Description:
Whatever the merits of slf4j, a quick solrj test should work.
I've attached a sample 1-line project with dependency on solrj-3.2 on run it
prints:
{code}
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
at com.mysimpatico.solrjtest.App.main(App.java:12)
{code}
Uncomment the nop dependency and it will work.
was:
Whatever the merits of slf4j, a quick solrj test should work. I've attached a
sample project with dependency on solrj-3.2 on run it prints:
{code}
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
at com.mysimpatico.solrjtest.App.main(App.java:12)
{code}
Uncomment the nop dependency and it will work.
> Add SLF4J-nop dependency
>
>
> Key: SOLR-2574
> URL: https://issues.apache.org/jira/browse/SOLR-2574
> Project: Solr
> Issue Type: Bug
>Reporter: Gabriele Kahlout
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 1.4
>
> Attachments: solrjtest.zip
>
>
> Whatever the merits of slf4j, a quick solrj test should work.
> I've attached a sample 1-line project with dependency on solrj-3.2 on run it
> prints:
> {code}
> java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
> at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
> at com.mysimpatico.solrjtest.App.main(App.java:12)
> {code}
> Uncomment the nop dependency and it will work.
--
This message is automatically generated by JIRA.
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] [Updated] (SOLR-2574) Add SLF4J-nop dependency
[
https://issues.apache.org/jira/browse/SOLR-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriele Kahlout updated SOLR-2574:
---
Attachment: solrjtest.zip
> Add SLF4J-nop dependency
>
>
> Key: SOLR-2574
> URL: https://issues.apache.org/jira/browse/SOLR-2574
> Project: Solr
> Issue Type: Bug
>Reporter: Gabriele Kahlout
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 1.4
>
> Attachments: solrjtest.zip
>
>
> Whatever the merits of slf4j, a quick solrj test should work. I've attached a
> sample project with dependency on solrj-3.2 on run it prints:
> {code}
> java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
> at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
> at com.mysimpatico.solrjtest.App.main(App.java:12)
> {code}
> Uncomment the nop dependency and it will work.
--
This message is automatically generated by JIRA.
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] [Updated] (SOLR-2574) Add SLF4J-nop dependency
[
https://issues.apache.org/jira/browse/SOLR-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriele Kahlout updated SOLR-2574:
---
Priority: Minor (was: Major)
Description:
Whatever the merits of slf4j, a quick solrj test should work. I've attached a
sample project with dependency on solrj-3.2 on run it prints:
{code}
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
at com.mysimpatico.solrjtest.App.main(App.java:12)
{code}
Uncomment the nop dependency and it will work.
was:
After lots of discussion, we should consider using SLF4j to enable more
flexibility in logging configuration.
See:
http://www.nabble.com/Solr-Logging-td16836646.html
http://www.nabble.com/logging-through-log4j-td13747253.html
Issue Type: Bug (was: Wish)
> Add SLF4J-nop dependency
>
>
> Key: SOLR-2574
> URL: https://issues.apache.org/jira/browse/SOLR-2574
> Project: Solr
> Issue Type: Bug
>Reporter: Gabriele Kahlout
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 1.4
>
>
> Whatever the merits of slf4j, a quick solrj test should work. I've attached a
> sample project with dependency on solrj-3.2 on run it prints:
> {code}
> java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
> at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:72)
> at com.mysimpatico.solrjtest.App.main(App.java:12)
> {code}
> Uncomment the nop dependency and it will work.
--
This message is automatically generated by JIRA.
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] [Created] (SOLR-2574) Add SLF4J-nop dependency
Add SLF4J-nop dependency Key: SOLR-2574 URL: https://issues.apache.org/jira/browse/SOLR-2574 Project: Solr Issue Type: Wish Reporter: Gabriele Kahlout Assignee: Ryan McKinley Fix For: 1.4 After lots of discussion, we should consider using SLF4j to enable more flexibility in logging configuration. See: http://www.nabble.com/Solr-Logging-td16836646.html http://www.nabble.com/logging-through-log4j-td13747253.html -- This message is automatically generated by JIRA. 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] [Updated] (SOLR-2573) Standard handler assumed as default in test breaks subclassing tests
[ https://issues.apache.org/jira/browse/SOLR-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriele Kahlout updated SOLR-2573: --- Attachment: SOLR-2573.patch Replaces qtype in affected test classes with StringUtils.EMPTY. Tested on own subclassing test (should probably have also added a test Solr case that indeed depends on the test value =( ) > Standard handler assumed as default in test breaks subclassing tests > > > Key: SOLR-2573 > URL: https://issues.apache.org/jira/browse/SOLR-2573 > Project: Solr > Issue Type: Bug >Reporter: Gabriele Kahlout >Priority: Minor > Attachments: SOLR-2573.patch > > > 'standard' is still specified as default qtype in TestHarness and > SolrTestCaseJ4, which makes tests that rely on the default fail. -- This message is automatically generated by JIRA. 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] [Created] (SOLR-2573) Standard handler assumed as default in test breaks subclassing tests
Standard handler assumed as default in test breaks subclassing tests Key: SOLR-2573 URL: https://issues.apache.org/jira/browse/SOLR-2573 Project: Solr Issue Type: Bug Reporter: Gabriele Kahlout Priority: Minor 'standard' is still specified as default qtype in TestHarness and SolrTestCaseJ4, which makes tests that rely on the default fail. -- This message is automatically generated by JIRA. 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] (SOLR-2537) Refactor Solr modules structure
[
https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038264#comment-13038264
]
Gabriele Kahlout commented on SOLR-2537:
{quote}I was able to reproduce{quote}
Could you please let it be know there?!
{quote}If I were you, I would copy/paste a similar test from Solr's source
tree, get that to succeed in your context, then tweak it to get to what you
want to test.{quote}
That's always the way to do! What I even try to do is modify the test write
there, because otherwise more often than not copy-pasting a method I end-up
needing to copy-paste the whole package, but then there's a dependency on
X-Y-Z, etc..
Looking at SolrBasicFunctionalityTest I was able to test what I want against r
1104120 + my structural refactoring. Now checking out without the refactoring
one of them complains about java.lang.NoSuchFieldError: core at
org.apache.lucene.index.SegmentTermDocs.(SegmentTermDocs.java:48).
I find it difficult to believe that the structural refactorings were
responsible for avoiding this though!
> Refactor Solr modules structure
> ---
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.1.1
>
>
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module
> is in the src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and
> Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST
> (Solr Search Server) since it's packaged as a war, to import
> EmbeddedSolrServer.java, for example. It has been discussed on the mailing
> list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which
> depend on Solr Core and on the Test Framework. The org burden of that extra
> module, versus the ease of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will
> build without passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the
> TestFramework module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the
> packages under Solr Core.
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr
> TestFramework declare it with tests, which packages
> only the tests, and the Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e
> [2] http://maven.apache.org/guides/mini/guide-attached-tests.html
> [3] I've successfully used it before.
> https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml
--
This message is automatically generated by JIRA.
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] (SOLR-2537) Refactor Solr modules structure
[
https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038248#comment-13038248
]
Gabriele Kahlout commented on SOLR-2537:
{quote}
Failed tests:
test(SolrConfigTest): ensure your setUp() calls super.setUp()!!!
{quote}
Please see LUCENE-3111, there probably is another bug. I've again posted
reproducable steps.
> Refactor Solr modules structure
> ---
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.1.1
>
>
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module
> is in the src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and
> Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST
> (Solr Search Server) since it's packaged as a war, to import
> EmbeddedSolrServer.java, for example. It has been discussed on the mailing
> list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which
> depend on Solr Core and on the Test Framework. The org burden of that extra
> module, versus the ease of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will
> build without passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the
> TestFramework module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the
> packages under Solr Core.
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr
> TestFramework declare it with tests, which packages
> only the tests, and the Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e
> [2] http://maven.apache.org/guides/mini/guide-attached-tests.html
> [3] I've successfully used it before.
> https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml
--
This message is automatically generated by JIRA.
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-3111) TestFSTs.testRandomWords failure
[
https://issues.apache.org/jira/browse/LUCENE-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038243#comment-13038243
]
Gabriele Kahlout commented on LUCENE-3111:
--
{quote}you just need to make sure your setup() calls super.setup() and your
tearDown() calls super.tearDown(){quoute}
But I am! Follows the code in the zipped project. Also, if I don't override
those methods I shouldn't get this problem, but I do.
{quote}
public class SolrConfigTest extends AbstractSolrTestCase {
@Override
public String getSolrHome() {
final String SOLR_HOME = System.getenv("SOLR_HOME");
if (SOLR_HOME == null) {
throw new RuntimeException("Set $SOLR_HOME env var to execute.");
}
return new File(SOLR_HOME).getAbsolutePath();
}
public String getSchemaFile() {
return getSolrHome() + "/conf/schema.xml";
}
public String getSolrConfigFile() {
return getSolrHome() + "/conf/solrconfig.xml";
}
private SolrServer server;
@Before
@Override
public void setUp() throws Exception {
super.setUp();
new EmbeddedSolrServer(h.getCoreContainer(), h.getCore().getName());
}
@Test
public void test() {
//just a dummy to have setUp() called
}
}
{quote}
> TestFSTs.testRandomWords failure
>
>
> Key: LUCENE-3111
> URL: https://issues.apache.org/jira/browse/LUCENE-3111
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: selckin
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-3111.patch
>
>
> Was running some while(1) tests on the docvalues branch (r1103705) and the
> following test failed:
> {code}
> [junit] Testsuite: org.apache.lucene.util.automaton.fst.TestFSTs
> [junit] Testcase:
> testRandomWords(org.apache.lucene.util.automaton.fst.TestFSTs): FAILED
> [junit] expected:<771> but was:
> [junit] junit.framework.AssertionFailedError: expected:<771> but
> was:
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.verifyUnPruned(TestFSTs.java:540)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:496)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:359)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs.doTest(TestFSTs.java:319)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs.testRandomWords(TestFSTs.java:940)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs.testRandomWords(TestFSTs.java:915)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1282)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211)
> [junit]
> [junit]
> [junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 7.628 sec
> [junit]
> [junit] - Standard Error -
> [junit] NOTE: Ignoring nightly-only test method 'testBigSet'
> [junit] NOTE: reproduce with: ant test -Dtestcase=TestFSTs
> -Dtestmethod=testRandomWords -Dtests.seed=-269475578956012681:0
> [junit] NOTE: test params are: codec=PreFlex, locale=ar,
> timezone=America/Blanc-Sablon
> [junit] NOTE: all tests run in this JVM:
> [junit] [TestToken, TestCodecs, TestIndexReaderReopen,
> TestIndexWriterMerging, TestNoDeletionPolicy, TestParallelReaderEmptyIndex,
> TestParallelTermEnum, TestPerSegmentDeletes, TestSegmentReader,
> TestSegmentTermDocs, TestStressAdvance, TestTermVectorsReader,
> TestSurrogates, TestMultiFieldQueryParser, TestAutomatonQuery,
> TestBooleanScorer, TestFuzzyQuery, TestMultiTermConstantScore,
> TestNumericRangeQuery64, TestPositiveScoresOnlyCollector, TestPrefixFilter,
> TestQueryTermVector, TestScorerPerf, TestSloppyPhraseQuery,
> TestSpansAdvanced, TestWindowsMMap, TestRamUsageEstimator, TestSmallFloat,
> TestUnicodeUtil, TestFSTs]
> [junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
> (64-bit)/cpus=8,threads=1,free=137329960,total=208207872
> [junit] - ---
> [junit] TEST org.apache.lucene.util.automaton.fst.TestFSTs FAILED
> {code}
> I am not able to reproduce
--
This message is automatically generated by JIRA.
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] (SOLR-2445) unknown handler: standard when using form.jsp
[
https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038185#comment-13038185
]
Gabriele Kahlout commented on SOLR-2445:
{quote} but that is really a very independent improvement from this bug {quote}
I'd not separate the tests from the issue.
{quoute}would you please open a new Jira issue?{quote}
I'm sure there's a $XB market opportunity for a solution to this common
forwarding problem. Has it been been better defined and named?
> unknown handler: standard when using form.jsp
> -
>
> Key: SOLR-2445
> URL: https://issues.apache.org/jira/browse/SOLR-2445
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4.1, 3.1, 3.2, 4.0
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 3.1.1, 3.2, 4.0
>
> Attachments: DefaultQTypeTest.java, SOLR-2445.patch,
> SOLR-2445_tests.patch, qt-form-jsp.patch
>
>
> To reproduce the problem using example config, go form.jsp, use standard for
> qt (it is default) then click Search.
--
This message is automatically generated by JIRA.
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] [Issue Comment Edited] (LUCENE-3111) TestFSTs.testRandomWords failure
[
https://issues.apache.org/jira/browse/LUCENE-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038160#comment-13038160
]
Gabriele Kahlout edited comment on LUCENE-3111 at 5/23/11 7:37 PM:
---
@rmuir: Why was this committed to the 3_X branch, and not only to the trunk, as
r 1104527?
Also, sorry for my ignorance, but why is it needed? Isn't there an
'inheritance/abstract/template method pattern' way to achive the same?
All I know is that it now breaks my Solr tests[1].
[1]
https://issues.apache.org/jira/browse/SOLR-2537?focusedCommentId=13038085&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13038085
Steps to reproduce:
{code}
svn co -r 1126620 http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/
cd branch_3x; ant get-maven-poms; mvn -N -Pbootstrap install; mvn -DskipTests
install
wget http://dp4j.sf.net/debug/embeddedServerTest.zip
unzip embeddedServerTest.zip
cd embeddedServerTest; mvn test
{code}
was (Author: simpatico):
@rmuir: Why was this committed to the 3_X branch, and not only to the
trunk, as r 1104527?
Also, sorry for my ignorance, but why is it needed? All I know is that it now
breaks my Solr tests[1].
[1]
https://issues.apache.org/jira/browse/SOLR-2537?focusedCommentId=13038085&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13038085
Steps to reproduce:
{code}
svn co -r 1126620 http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/
cd branch_3x; ant get-maven-poms; mvn -N -Pbootstrap install; mvn -DskipTests
install
wget http://dp4j.sf.net/debug/embeddedServerTest.zip
unzip embeddedServerTest.zip
cd embeddedServerTest; mvn test
{code}
> TestFSTs.testRandomWords failure
>
>
> Key: LUCENE-3111
> URL: https://issues.apache.org/jira/browse/LUCENE-3111
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: selckin
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-3111.patch
>
>
> Was running some while(1) tests on the docvalues branch (r1103705) and the
> following test failed:
> {code}
> [junit] Testsuite: org.apache.lucene.util.automaton.fst.TestFSTs
> [junit] Testcase:
> testRandomWords(org.apache.lucene.util.automaton.fst.TestFSTs): FAILED
> [junit] expected:<771> but was:
> [junit] junit.framework.AssertionFailedError: expected:<771> but
> was:
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.verifyUnPruned(TestFSTs.java:540)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:496)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:359)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs.doTest(TestFSTs.java:319)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs.testRandomWords(TestFSTs.java:940)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs.testRandomWords(TestFSTs.java:915)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1282)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211)
> [junit]
> [junit]
> [junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 7.628 sec
> [junit]
> [junit] - Standard Error -
> [junit] NOTE: Ignoring nightly-only test method 'testBigSet'
> [junit] NOTE: reproduce with: ant test -Dtestcase=TestFSTs
> -Dtestmethod=testRandomWords -Dtests.seed=-269475578956012681:0
> [junit] NOTE: test params are: codec=PreFlex, locale=ar,
> timezone=America/Blanc-Sablon
> [junit] NOTE: all tests run in this JVM:
> [junit] [TestToken, TestCodecs, TestIndexReaderReopen,
> TestIndexWriterMerging, TestNoDeletionPolicy, TestParallelReaderEmptyIndex,
> TestParallelTermEnum, TestPerSegmentDeletes, TestSegmentReader,
> TestSegmentTermDocs, TestStressAdvance, TestTermVectorsReader,
> TestSurrogates, TestMultiFieldQueryParser, TestAutomatonQuery,
> TestBooleanScorer, TestFuzzyQuery, TestMultiTermConstantScore,
> TestNumericRangeQuery64, TestPositiveScoresOnlyCollector, TestPrefixFilter,
> TestQueryTermVector, TestScorerPerf, TestSloppyPhraseQuery,
> TestSpansAdvanced, TestWindowsMMap, TestRamUsageEstimator, TestSmallFloat,
> TestUnicodeUtil, TestFSTs]
> [junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
> (64-bit)/cpus=8,threads=1,free=137329960,total=208207872
> [junit] - ---
> [junit] TEST org.apache.lucene.util.automaton.fst.TestFSTs FAILED
> {code}
> I am not able to reproduce
--
This message is automatically generated
[jira] [Commented] (LUCENE-3111) TestFSTs.testRandomWords failure
[
https://issues.apache.org/jira/browse/LUCENE-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038160#comment-13038160
]
Gabriele Kahlout commented on LUCENE-3111:
--
@rmuir: Why was this committed to the 3_X branch, and not only to the trunk, as
r 1104527?
Also, sorry for my ignorance, but why is it needed? All I know is that it now
breaks my Solr tests[1].
[1]
https://issues.apache.org/jira/browse/SOLR-2537?focusedCommentId=13038085&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13038085
Steps to reproduce:
{code}
svn co -r 1126620 http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/
cd branch_3x; ant get-maven-poms; mvn -N -Pbootstrap install; mvn -DskipTests
install
wget http://dp4j.sf.net/debug/embeddedServerTest.zip
unzip embeddedServerTest.zip
cd embeddedServerTest; mvn test
{code}
> TestFSTs.testRandomWords failure
>
>
> Key: LUCENE-3111
> URL: https://issues.apache.org/jira/browse/LUCENE-3111
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: selckin
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-3111.patch
>
>
> Was running some while(1) tests on the docvalues branch (r1103705) and the
> following test failed:
> {code}
> [junit] Testsuite: org.apache.lucene.util.automaton.fst.TestFSTs
> [junit] Testcase:
> testRandomWords(org.apache.lucene.util.automaton.fst.TestFSTs): FAILED
> [junit] expected:<771> but was:
> [junit] junit.framework.AssertionFailedError: expected:<771> but
> was:
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.verifyUnPruned(TestFSTs.java:540)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:496)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs$FSTTester.doTest(TestFSTs.java:359)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs.doTest(TestFSTs.java:319)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs.testRandomWords(TestFSTs.java:940)
> [junit] at
> org.apache.lucene.util.automaton.fst.TestFSTs.testRandomWords(TestFSTs.java:915)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1282)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211)
> [junit]
> [junit]
> [junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 7.628 sec
> [junit]
> [junit] - Standard Error -
> [junit] NOTE: Ignoring nightly-only test method 'testBigSet'
> [junit] NOTE: reproduce with: ant test -Dtestcase=TestFSTs
> -Dtestmethod=testRandomWords -Dtests.seed=-269475578956012681:0
> [junit] NOTE: test params are: codec=PreFlex, locale=ar,
> timezone=America/Blanc-Sablon
> [junit] NOTE: all tests run in this JVM:
> [junit] [TestToken, TestCodecs, TestIndexReaderReopen,
> TestIndexWriterMerging, TestNoDeletionPolicy, TestParallelReaderEmptyIndex,
> TestParallelTermEnum, TestPerSegmentDeletes, TestSegmentReader,
> TestSegmentTermDocs, TestStressAdvance, TestTermVectorsReader,
> TestSurrogates, TestMultiFieldQueryParser, TestAutomatonQuery,
> TestBooleanScorer, TestFuzzyQuery, TestMultiTermConstantScore,
> TestNumericRangeQuery64, TestPositiveScoresOnlyCollector, TestPrefixFilter,
> TestQueryTermVector, TestScorerPerf, TestSloppyPhraseQuery,
> TestSpansAdvanced, TestWindowsMMap, TestRamUsageEstimator, TestSmallFloat,
> TestUnicodeUtil, TestFSTs]
> [junit] NOTE: Linux 2.6.37-gentoo amd64/Sun Microsystems Inc. 1.6.0_25
> (64-bit)/cpus=8,threads=1,free=137329960,total=208207872
> [junit] - ---
> [junit] TEST org.apache.lucene.util.automaton.fst.TestFSTs FAILED
> {code}
> I am not able to reproduce
--
This message is automatically generated by JIRA.
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] [Issue Comment Edited] (SOLR-2537) Refactor Solr modules structure
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038108#comment-13038108 ] Gabriele Kahlout edited comment on SOLR-2537 at 5/23/11 6:20 PM: - Regarding the .zip it's indeed time-consuming to explore. I had summarized the the differences (essentially putting all children at the same level and changing the core pom.xml), and meant the zip just for extra reference. BTW solution 1. could be implemented w/o changing dirs structure. Solr core becomes an aggregator, the tests/src becomes a child module, and there we have the 3 modules w/o circular dependency as described above. I think this is a more 'maven-friendly' solution to the maven-helper copy-paste workaround. What do you think? I could try and patch that perhaps. BTW, thank you for dedicating time to look into my issue. was (Author: simpatico): Regarding the .zip it's indeed time-consuming to explore. I had summarized the the differences (essentially putting all children at the same level and changing the core pom.xml), and meant the zip just for extra reference. BTW solution 1. could be implemented w/o changing dirs structure. Solr core becomes an aggregator, the tests/src becomes a child module, and there we have the 3 modules w/o circular dependency as described above. I think this is a more 'maven-friendly' solution to the maven-helper copy-paste workaround. What do you think? I could try and patch that perhaps. > Refactor Solr modules structure > --- > > Key: SOLR-2537 > URL: https://issues.apache.org/jira/browse/SOLR-2537 > Project: Solr > Issue Type: Improvement >Reporter: Gabriele Kahlout >Priority: Minor > Fix For: 3.1.1 > > > Solr modules are nested in a non-standard archeotype (e.g. Solr Core module > is in the src dir of Solr parent). > Also, a workaround for avoiding maven dependencies between Solr Core and > Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST > (Solr Search Server) since it's packaged as a war, to import > EmbeddedSolrServer.java, for example. It has been discussed on the mailing > list[1]. > I've, in the mlist, suggested to "create yet one more module for Tests which > depend on Solr Core and on the Test Framework. The org burden of that extra > module, versus the ease of building configuration, I believe, outweights." > However I realize there's a major drawback in that, i.e. that Solr Core will > build without passing the tests in the other module. There're 2 solutions: > 1. Make Solr Core a parent module that encompasses a thin Solr Core, the > TestFramework module, and the Tests-only module; > 2. 'Downgrade' Testframework from being a fully-fledged module by moving the > packages under Solr Core. > 2a. Move them under Solr Core test packages. > 2b. move them under Solr Core src > To me 2a is most intuitive. Those that want a dependency on Solr > TestFramework declare it with tests, which packages > only the tests, and the Solr Core classes those require.[2][3] > The same refactoring applies to lucuene. > [1] > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e > [2] http://maven.apache.org/guides/mini/guide-attached-tests.html > [3] I've successfully used it before. > https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml -- This message is automatically generated by JIRA. 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] (SOLR-2537) Refactor Solr modules structure
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038108#comment-13038108 ] Gabriele Kahlout commented on SOLR-2537: Regarding the .zip it's indeed time-consuming to explore. I had summarized the the differences (essentially putting all children at the same level and changing the core pom.xml), and meant the zip just for extra reference. BTW solution 1. could be implemented w/o changing dirs structure. Solr core becomes an aggregator, the tests/src becomes a child module, and there we have the 3 modules w/o circular dependency as described above. I think this is a more 'maven-friendly' solution to the maven-helper copy-paste workaround. What do you think? I could try and patch that perhaps. > Refactor Solr modules structure > --- > > Key: SOLR-2537 > URL: https://issues.apache.org/jira/browse/SOLR-2537 > Project: Solr > Issue Type: Improvement >Reporter: Gabriele Kahlout >Priority: Minor > Fix For: 3.1.1 > > > Solr modules are nested in a non-standard archeotype (e.g. Solr Core module > is in the src dir of Solr parent). > Also, a workaround for avoiding maven dependencies between Solr Core and > Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST > (Solr Search Server) since it's packaged as a war, to import > EmbeddedSolrServer.java, for example. It has been discussed on the mailing > list[1]. > I've, in the mlist, suggested to "create yet one more module for Tests which > depend on Solr Core and on the Test Framework. The org burden of that extra > module, versus the ease of building configuration, I believe, outweights." > However I realize there's a major drawback in that, i.e. that Solr Core will > build without passing the tests in the other module. There're 2 solutions: > 1. Make Solr Core a parent module that encompasses a thin Solr Core, the > TestFramework module, and the Tests-only module; > 2. 'Downgrade' Testframework from being a fully-fledged module by moving the > packages under Solr Core. > 2a. Move them under Solr Core test packages. > 2b. move them under Solr Core src > To me 2a is most intuitive. Those that want a dependency on Solr > TestFramework declare it with tests, which packages > only the tests, and the Solr Core classes those require.[2][3] > The same refactoring applies to lucuene. > [1] > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e > [2] http://maven.apache.org/guides/mini/guide-attached-tests.html > [3] I've successfully used it before. > https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml -- This message is automatically generated by JIRA. 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] (SOLR-2537) Refactor Solr modules structure
[
https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038085#comment-13038085
]
Gabriele Kahlout commented on SOLR-2537:
{quote} What happens for you? {quote}
{code}
Running SolrConfigTest
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.28 sec <<<
FAILURE!
Results :
Failed tests:
test(SolrConfigTest): ensure your setUp() calls super.setUp()!!!
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
{code}
This is after adding an empty body dummy test method (sorry missed that, but
maven 3.0.3 doesn't complain about annotations) and checking the head (1126606).
The issue I had was that it used to complain about something with the
classpath. After svn -r 1104120 update and mvn test again:
{quote}
Results :
Tests in error:
test(SolrConfigTest): javax/servlet/ServletRequest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
[INFO]
[INFO] BUILD FAILURE
{quote}
NetBeans doesn't recognize super.setUp().
I'm okay solving the issue against the latest revision of course. Also, I'd
solved my test problem w/o EmbeddedSolrServer which seems redundant to
SolrTestCaseJ4, or is there an extra layer being tested in the
EmbeddedSolrServer?
> Refactor Solr modules structure
> ---
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.1.1
>
>
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module
> is in the src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and
> Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST
> (Solr Search Server) since it's packaged as a war, to import
> EmbeddedSolrServer.java, for example. It has been discussed on the mailing
> list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which
> depend on Solr Core and on the Test Framework. The org burden of that extra
> module, versus the ease of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will
> build without passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the
> TestFramework module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the
> packages under Solr Core.
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr
> TestFramework declare it with tests, which packages
> only the tests, and the Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e
> [2] http://maven.apache.org/guides/mini/guide-attached-tests.html
> [3] I've successfully used it before.
> https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml
--
This message is automatically generated by JIRA.
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] (SOLR-2537) Refactor Solr modules structure
[
https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037959#comment-13037959
]
Gabriele Kahlout commented on SOLR-2537:
{quote} without negatively impacting the official Ant build {quote}
That's the issue. Complicating the poms not to move folders is the status quo,
and doesn't seem to work (war/jar issue); But as you mention, we could
impact/influence SOLR-2537 so that the project lends itself to both ant and
maven builders.
{quote}The fact that they can be used to drive a build is a bonus.{quote}
My +1 for escalating to more than a bonus. The I've praised the exemplarey work
on dev-tools in NUTCH-892[1], essentially making it easier to build Solr allows
for easier adoption, contribution, and provides newbie documentation.
Where is this issue going to? I've provided re-producable steps to a build
(bonus!) issue, and recommended a simplyfing (bonus!) solution.
[1]
https://issues.apache.org/jira/browse/NUTCH-892?focusedCommentId=13037537&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13037537
> Refactor Solr modules structure
> ---
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.1.1
>
>
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module
> is in the src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and
> Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST
> (Solr Search Server) since it's packaged as a war, to import
> EmbeddedSolrServer.java, for example. It has been discussed on the mailing
> list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which
> depend on Solr Core and on the Test Framework. The org burden of that extra
> module, versus the ease of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will
> build without passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the
> TestFramework module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the
> packages under Solr Core.
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr
> TestFramework declare it with tests, which packages
> only the tests, and the Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e
> [2] http://maven.apache.org/guides/mini/guide-attached-tests.html
> [3] I've successfully used it before.
> https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml
--
This message is automatically generated by JIRA.
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] (SOLR-2537) Refactor Solr modules structure
[
https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037944#comment-13037944
]
Gabriele Kahlout commented on SOLR-2537:
and those things in poms:
{code}
../../pom.xml
{code}
{code}
org.apache.maven.plugins
maven-surefire-plugin
true
{code}
> Refactor Solr modules structure
> ---
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.1.1
>
>
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module
> is in the src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and
> Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST
> (Solr Search Server) since it's packaged as a war, to import
> EmbeddedSolrServer.java, for example. It has been discussed on the mailing
> list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which
> depend on Solr Core and on the Test Framework. The org burden of that extra
> module, versus the ease of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will
> build without passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the
> TestFramework module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the
> packages under Solr Core.
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr
> TestFramework declare it with tests, which packages
> only the tests, and the Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e
> [2] http://maven.apache.org/guides/mini/guide-attached-tests.html
> [3] I've successfully used it before.
> https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml
--
This message is automatically generated by JIRA.
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] [Issue Comment Edited] (SOLR-2537) Refactor Solr modules structure
[
https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037937#comment-13037937
]
Gabriele Kahlout edited comment on SOLR-2537 at 5/23/11 1:32 PM:
-
{quote}
I don't think it makes sense to roll that back - let's try to figure out how to
make the Maven stuff work without changing the official Ant build.{quote}
The issue is that we increase complexity trying with complex maven
configuration (and then people say that maven is complicated), unless we go for
option 1 (parent solr-core with solr-core-src module, tesframework module,
solr-core-tests-src).
The good of SOLR-2061 was to define the Testframework (content); I've had
problems with its delivery.
The TestFramework module on its own is a pretty 'lazy module'/interface. It
reminds me of the 'lazy class' refactoring.
{quote}can you take a step back and describe more fully why the current setup
is a problem?{quote}
A maven project is not expected to contain other maven projects inside it,
unless a parent. Solr-core (solr/src) has 'webapp' inside it (under src?). This
is non-standard complying, but most importantly very confusing for new-comers.
Then the copy-paste trick (done by the maven-helper?) adds to the complication.
Beside, the issues mentioned in the previous comment.
{quote}But this would expose a bunch of Solr tests, which aren't usable outside
of Solr, to consumers of the test-jar. The solr test framework classes need to
be separate from the other solr test classes.{quote}
Agreed. I've not come across any other 'maven design' approach. I hope it's
possible to unwanted packages.
was (Author: simpatico):
{quote}
I don't think it makes sense to roll that back - let's try to figure out how to
make the Maven stuff work without changing the official Ant build.{quote}
The issue is that we increase complexity trying with complex maven
configuration (and then people say that maven is complicated), unless we go for
option 1 (parent solr-core with solr-core-src module, tesframework module,
solr-core-tests-src).
The good of SOLR-2061 was to create the Testframework (content); I've had
problems with its delivery.
The TestFramework module on its own is a pretty 'lazy module'/interface. It
reminds me of the 'lazy class' refactoring.
{quote}can you take a step back and describe more fully why the current setup
is a problem?{quote}
A maven project is not expected to contain other maven projects inside it,
unless a parent. Solr-core (solr/src) has 'webapp' inside it (under src?). This
is non-standard complying, but most importantly very confusing for new-comers.
Then the copy-paste trick (done by the maven-helper?) adds to the complication.
Beside, the issues mentioned in the previous comment.
{quote}But this would expose a bunch of Solr tests, which aren't usable outside
of Solr, to consumers of the test-jar. The solr test framework classes need to
be separate from the other solr test classes.{quote}
Agreed. I've not come across any other 'maven design' approach. I hope it's
possible to unwanted packages.
> Refactor Solr modules structure
> ---
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.1.1
>
>
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module
> is in the src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and
> Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST
> (Solr Search Server) since it's packaged as a war, to import
> EmbeddedSolrServer.java, for example. It has been discussed on the mailing
> list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which
> depend on Solr Core and on the Test Framework. The org burden of that extra
> module, versus the ease of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will
> build without passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the
> TestFramework module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the
> packages under Solr Core.
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr
> TestFramework declare it with tests, which packages
> only the tests, and the Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d
[jira] [Issue Comment Edited] (SOLR-2537) Refactor Solr modules structure
[
https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037937#comment-13037937
]
Gabriele Kahlout edited comment on SOLR-2537 at 5/23/11 1:32 PM:
-
{quote}
I don't think it makes sense to roll that back - let's try to figure out how to
make the Maven stuff work without changing the official Ant build.{quote}
The issue is that we increase complexity trying with complex maven
configuration (and then people say that maven is complicated), unless we go for
option 1 (parent solr-core with solr-core-src module, tesframework module,
solr-core-tests-src).
The good of SOLR-2061 was to create the Testframework (content); I've had
problems with its delivery.
The TestFramework module on its own is a pretty 'lazy module'/interface. It
reminds me of the 'lazy class' refactoring.
{quote}can you take a step back and describe more fully why the current setup
is a problem?{quote}
A maven project is not expected to contain other maven projects inside it,
unless a parent. Solr-core (solr/src) has 'webapp' inside it (under src?). This
is non-standard complying, but most importantly very confusing for new-comers.
Then the copy-paste trick (done by the maven-helper?) adds to the complication.
Beside, the issues mentioned in the previous comment.
{quote}But this would expose a bunch of Solr tests, which aren't usable outside
of Solr, to consumers of the test-jar. The solr test framework classes need to
be separate from the other solr test classes.{quote}
Agreed. I've not come across any other 'maven design' approach. I hope it's
possible to unwanted packages.
was (Author: simpatico):
{quote}
I don't think it makes sense to roll that back - let's try to figure out how to
make the Maven stuff work without changing the official Ant build.{quote}
The issue is that we increase complexity trying with complex maven
configuration (and then people say that maven is complicated). Unless we go for
option 1 (parent solr-core with solr-core-src module, tesframework module,
solr-core-tests-src).
The good of SOLR-2061 was to create the Testframework (content); I've had
problems with its delivery.
The TestFramework module on its own is a pretty 'lazy module'/interface. It
reminds me of the 'lazy class' refactoring.
{quote}can you take a step back and describe more fully why the current setup
is a problem?{quote}
A maven project is not expected to contain other maven projects inside it,
unless a parent. Solr-core (solr/src) has 'webapp' inside it (under src?). This
is non-standard complying, but most importantly very confusing for new-comers.
Then the copy-paste trick (done by the maven-helper?) adds to the complication.
Beside, the issues mentioned in the previous comment.
{quote}But this would expose a bunch of Solr tests, which aren't usable outside
of Solr, to consumers of the test-jar. The solr test framework classes need to
be separate from the other solr test classes.{quote}
Agreed. I've not come across any other 'maven design' approach. I hope it's
possible to unwanted packages.
> Refactor Solr modules structure
> ---
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.1.1
>
>
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module
> is in the src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and
> Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST
> (Solr Search Server) since it's packaged as a war, to import
> EmbeddedSolrServer.java, for example. It has been discussed on the mailing
> list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which
> depend on Solr Core and on the Test Framework. The org burden of that extra
> module, versus the ease of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will
> build without passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the
> TestFramework module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the
> packages under Solr Core.
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr
> TestFramework declare it with tests, which packages
> only the tests, and the Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d
[jira] [Commented] (SOLR-2537) Refactor Solr modules structure
[
https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037937#comment-13037937
]
Gabriele Kahlout commented on SOLR-2537:
{quote}
I don't think it makes sense to roll that back - let's try to figure out how to
make the Maven stuff work without changing the official Ant build.{quote}
The issue is that we increase complexity trying with complex maven
configuration (and then people say that maven is complicated). Unless we go for
option 1 (parent solr-core with solr-core-src module, tesframework module,
solr-core-tests-src).
The good of SOLR-2061 was to create the Testframework (content); I've had
problems with its delivery.
The TestFramework module on its own is a pretty 'lazy module'/interface. It
reminds me of the 'lazy class' refactoring.
{quote}can you take a step back and describe more fully why the current setup
is a problem?{quote}
A maven project is not expected to contain other maven projects inside it,
unless a parent. Solr-core (solr/src) has 'webapp' inside it (under src?). This
is non-standard complying, but most importantly very confusing for new-comers.
Then the copy-paste trick (done by the maven-helper?) adds to the complication.
Beside, the issues mentioned in the previous comment.
{quote}But this would expose a bunch of Solr tests, which aren't usable outside
of Solr, to consumers of the test-jar. The solr test framework classes need to
be separate from the other solr test classes.{quote}
Agreed. I've not come across any other 'maven design' approach. I hope it's
possible to unwanted packages.
> Refactor Solr modules structure
> ---
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.1.1
>
>
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module
> is in the src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and
> Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST
> (Solr Search Server) since it's packaged as a war, to import
> EmbeddedSolrServer.java, for example. It has been discussed on the mailing
> list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which
> depend on Solr Core and on the Test Framework. The org burden of that extra
> module, versus the ease of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will
> build without passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the
> TestFramework module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the
> packages under Solr Core.
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr
> TestFramework declare it with tests, which packages
> only the tests, and the Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e
> [2] http://maven.apache.org/guides/mini/guide-attached-tests.html
> [3] I've successfully used it before.
> https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml
--
This message is automatically generated by JIRA.
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] (SOLR-2537) Refactor Solr modules structure
[
https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037930#comment-13037930
]
Gabriele Kahlout commented on SOLR-2537:
{quote}
I get a 403 error code when I follow this link:
http://dp4j.sourceforge.net/debug/SOLR-2537/ {quote}
try http://dp4j.sourceforge.net/debug/SOLR-2537.zip
{quote} 1. Can you explain why the workaround makes it impossible to add a
dependency on the Solr war? This makes no sense to me.{quote}
Sorry, I meant 'jar'. The project Solr Search Server (the one in
solr/src/webapp which contains EmbeddedSolrServer) is packaged as a war. But in
a Solr plugin I need to depend on the class files packaged in a jar. How do I
do that? Attempts were mentioned here[1].
{quote}
2. EmbeddedSolrServer.java is included in the solr-core jar - why not depend
on this smaller jar instead of the war?
{quote}
When building it locally it won't work, probably because it's under the webapp
project. Steps to reproduce mentioned in the mlist[1]:
{code}
svn co -r 1104120
http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/ solr
cd solr; ant get-maven-poms; mvn -N -Pbootstrap install; mvn -DskipTests install
wget http://dp4j.sf.net/debug/embeddedServerTest.zip
unzip embeddedServerTest.zip
cd embeddedServerTest; mvn -X test
{code}
[1]
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3cbanlktinhw3vm9djgpvmsrwxhs8mwjoy...@mail.gmail.com%3e
> Refactor Solr modules structure
> ---
>
> Key: SOLR-2537
> URL: https://issues.apache.org/jira/browse/SOLR-2537
> Project: Solr
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Priority: Minor
> Fix For: 3.1.1
>
>
> Solr modules are nested in a non-standard archeotype (e.g. Solr Core module
> is in the src dir of Solr parent).
> Also, a workaround for avoiding maven dependencies between Solr Core and
> Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST
> (Solr Search Server) since it's packaged as a war, to import
> EmbeddedSolrServer.java, for example. It has been discussed on the mailing
> list[1].
> I've, in the mlist, suggested to "create yet one more module for Tests which
> depend on Solr Core and on the Test Framework. The org burden of that extra
> module, versus the ease of building configuration, I believe, outweights."
> However I realize there's a major drawback in that, i.e. that Solr Core will
> build without passing the tests in the other module. There're 2 solutions:
> 1. Make Solr Core a parent module that encompasses a thin Solr Core, the
> TestFramework module, and the Tests-only module;
> 2. 'Downgrade' Testframework from being a fully-fledged module by moving the
> packages under Solr Core.
> 2a. Move them under Solr Core test packages.
> 2b. move them under Solr Core src
> To me 2a is most intuitive. Those that want a dependency on Solr
> TestFramework declare it with tests, which packages
> only the tests, and the Solr Core classes those require.[2][3]
> The same refactoring applies to lucuene.
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e
> [2] http://maven.apache.org/guides/mini/guide-attached-tests.html
> [3] I've successfully used it before.
> https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml
--
This message is automatically generated by JIRA.
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] (SOLR-2537) Refactor Solr modules structure
[ https://issues.apache.org/jira/browse/SOLR-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037814#comment-13037814 ] Gabriele Kahlout commented on SOLR-2537: svn diff would complain about missing directories. I've uploaded the stripped project here[1]. Essentially there's no more test-framework under both lucene and solr (classes moved under the cores packages), Solr Core has been moved out of solr/src into a solr/core, and webapp has been moved to solr/webapp a la par with core. >From the core's pom.xml I've commented: and replaced it with: org.apache.maven.plugins maven-jar-plugin test-jar I've run the tests of solr core and lucene core they passed (some had errors but they had them even before, expecting Jetty). I hope you consider this refactoring. [1] http://dp4j.sf.net/debug/SOLR-2537 > Refactor Solr modules structure > --- > > Key: SOLR-2537 > URL: https://issues.apache.org/jira/browse/SOLR-2537 > Project: Solr > Issue Type: Improvement >Reporter: Gabriele Kahlout >Priority: Minor > Fix For: 3.1.1 > > > Solr modules are nested in a non-standard archeotype (e.g. Solr Core module > is in the src dir of Solr parent). > Also, a workaround for avoiding maven dependencies between Solr Core and > Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST > (Solr Search Server) since it's packaged as a war, to import > EmbeddedSolrServer.java, for example. It has been discussed on the mailing > list[1]. > I've, in the mlist, suggested to "create yet one more module for Tests which > depend on Solr Core and on the Test Framework. The org burden of that extra > module, versus the ease of building configuration, I believe, outweights." > However I realize there's a major drawback in that, i.e. that Solr Core will > build without passing the tests in the other module. There're 2 solutions: > 1. Make Solr Core a parent module that encompasses a thin Solr Core, the > TestFramework module, and the Tests-only module; > 2. 'Downgrade' Testframework from being a fully-fledged module by moving the > packages under Solr Core. > 2a. Move them under Solr Core test packages. > 2b. move them under Solr Core src > To me 2a is most intuitive. Those that want a dependency on Solr > TestFramework declare it with tests, which packages > only the tests, and the Solr Core classes those require.[2][3] > The same refactoring applies to lucuene. > [1] > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e > [2] http://maven.apache.org/guides/mini/guide-attached-tests.html > [3] I've successfully used it before. > https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml -- This message is automatically generated by JIRA. 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] [Created] (SOLR-2537) Refactor Solr modules structure
Refactor Solr modules structure --- Key: SOLR-2537 URL: https://issues.apache.org/jira/browse/SOLR-2537 Project: Solr Issue Type: Improvement Reporter: Gabriele Kahlout Priority: Minor Fix For: 3.1.1 Solr modules are nested in a non-standard archeotype (e.g. Solr Core module is in the src dir of Solr parent). Also, a workaround for avoiding maven dependencies between Solr Core and Testframework makes it impossible to add a depenency on Solr-3.2-SNAPHOST (Solr Search Server) since it's packaged as a war, to import EmbeddedSolrServer.java, for example. It has been discussed on the mailing list[1]. I've, in the mlist, suggested to "create yet one more module for Tests which depend on Solr Core and on the Test Framework. The org burden of that extra module, versus the ease of building configuration, I believe, outweights." However I realize there's a major drawback in that, i.e. that Solr Core will build without passing the tests in the other module. There're 2 solutions: 1. Make Solr Core a parent module that encompasses a thin Solr Core, the TestFramework module, and the Tests-only module; 2. 'Downgrade' Testframework from being a fully-fledged module by moving the packages under Solr Core. 2a. Move them under Solr Core test packages. 2b. move them under Solr Core src To me 2a is most intuitive. Those that want a dependency on Solr TestFramework declare it with tests, which packages only the tests, and the Solr Core classes those require.[2][3] The same refactoring applies to lucuene. [1] http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c2d127f11dc79714e9b6a43ac9458147fbad42...@suex07-mbx-03.ad.syr.edu%3e [2] http://maven.apache.org/guides/mini/guide-attached-tests.html [3] I've successfully used it before. https://code.google.com/p/memorizeasy/source/browse/MemoPlatform/persistenceui/pom.xml -- This message is automatically generated by JIRA. 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] [Issue Comment Edited] (SOLR-2445) unknown handler: standard
[ https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037071#comment-13037071 ] Gabriele Kahlout edited comment on SOLR-2445 at 5/20/11 8:43 PM: - I don't know how/which tests pass when you build the project (is -DskipTests set?) or if none of the tests use defaults but 'standard' is still specified as default qtype in TestHarness and SolrTestCaseJ4. I've attached a minimal test that works from my own client app (at least it works for someone =)). Feel free to adapt it for test-framework tests. was (Author: simpatico): I don't know how/which tests pass when you build the project (is -DskipTests set?) or if none of the tests use defaults but 'standard' is still specified as default qtype in TestHarness and SolrTestCaseJ4. I've attached a minimal test that works from my own client app (at least it works for someone =)). Feel free to adapt it and to test-framework tests. > unknown handler: standard > - > > Key: SOLR-2445 > URL: https://issues.apache.org/jira/browse/SOLR-2445 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4.1, 3.1, 3.2, 4.0 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.1.1, 3.2, 4.0 > > Attachments: DefaultQTypeTest.java, SOLR-2445.patch, > SOLR-2445_tests.patch, qt-form-jsp.patch > > > To reproduce the problem using example config, go form.jsp, use standard for > qt (it is default) then click Search. -- This message is automatically generated by JIRA. 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] [Updated] (SOLR-2445) unknown handler: standard
[ https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriele Kahlout updated SOLR-2445: --- Attachment: DefaultQTypeTest.java SOLR-2445_tests.patch I don't know how/which tests pass when you build the project (is -DskipTests set?) or if none of the tests use defaults but 'standard' is still specified as default qtype in TestHarness and SolrTestCaseJ4. I've attached a minimal test that works from my own client app (at least it works for someone =)). Feel free to adapt it and to test-framework tests. > unknown handler: standard > - > > Key: SOLR-2445 > URL: https://issues.apache.org/jira/browse/SOLR-2445 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4.1, 3.1, 3.2, 4.0 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.1.1, 3.2, 4.0 > > Attachments: DefaultQTypeTest.java, SOLR-2445.patch, > SOLR-2445_tests.patch, qt-form-jsp.patch > > > To reproduce the problem using example config, go form.jsp, use standard for > qt (it is default) then click Search. -- This message is automatically generated by JIRA. 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] [Issue Comment Edited] (SOLR-2513) Allow to subclass org.apache.solr.response.XMLWriter
[ https://issues.apache.org/jira/browse/SOLR-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036993#comment-13036993 ] Gabriele Kahlout edited comment on SOLR-2513 at 5/20/11 6:56 PM: - why to 4.0 only? I think it can be applied to branch3-X too. Also hacking it in my local copy I'd make almost every field protected and remove the finals from the methods. Are you against that, or should I upload a suggested revision that does that? was (Author: simpatico): why to 4.0 only? I think it can be applied to trunk/branch3-X too. Also hacking it in my local copy I'd make almost every field protected and remove the finals from the methods. Are you against that, or should I upload a suggested revision that does that? > Allow to subclass org.apache.solr.response.XMLWriter > - > > Key: SOLR-2513 > URL: https://issues.apache.org/jira/browse/SOLR-2513 > Project: Solr > Issue Type: Improvement > Components: Response Writers >Reporter: Gabriele Kahlout >Assignee: Ryan McKinley >Priority: Trivial > Fix For: 4.0 > > Attachments: SOLR-2513-XMLWriter.patch, SOLR-2513.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > Hacking/debugging/extending Solr with one's own ResponseWriter one might want > to inherit functionality from XMLWriter. A trivial example is overriding > writeDate(..) to use a different calendar/format. > I asked about why it's made final on the mailing list[1]. > [1] > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3cbanlktin4mxiybzw3ck-k4gwq4o6nnc2...@mail.gmail.com%3E > -- This message is automatically generated by JIRA. 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] (SOLR-2513) Allow to subclass org.apache.solr.response.XMLWriter
[ https://issues.apache.org/jira/browse/SOLR-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036993#comment-13036993 ] Gabriele Kahlout commented on SOLR-2513: why to 4.0 only? I think it can be applied to trunk/branch3-X too. Also hacking it in my local copy I'd make almost every field protected and remove the finals from the methods. Are you against that, or should I upload a suggested revision that does that? > Allow to subclass org.apache.solr.response.XMLWriter > - > > Key: SOLR-2513 > URL: https://issues.apache.org/jira/browse/SOLR-2513 > Project: Solr > Issue Type: Improvement > Components: Response Writers >Reporter: Gabriele Kahlout >Assignee: Ryan McKinley >Priority: Trivial > Fix For: 4.0 > > Attachments: SOLR-2513-XMLWriter.patch, SOLR-2513.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > Hacking/debugging/extending Solr with one's own ResponseWriter one might want > to inherit functionality from XMLWriter. A trivial example is overriding > writeDate(..) to use a different calendar/format. > I asked about why it's made final on the mailing list[1]. > [1] > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3cbanlktin4mxiybzw3ck-k4gwq4o6nnc2...@mail.gmail.com%3E > -- This message is automatically generated by JIRA. 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] [Issue Comment Edited] (SOLR-2445) unknown handler: standard
[ https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1303#comment-1303 ] Gabriele Kahlout edited comment on SOLR-2445 at 5/16/11 8:48 PM: - trivial patch to form.jsp that leaves qt empty (useful for setup scripts and those that need to stick to a 3.1.0 revision). was (Author: simpatico): trivial patch to form.jsp that leaves qt empty (useful for setup scripts and those that need to stick to an 3.1.0 revision). > unknown handler: standard > - > > Key: SOLR-2445 > URL: https://issues.apache.org/jira/browse/SOLR-2445 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4.1, 3.1, 3.2, 4.0 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: SOLR-2445.patch, qt-form-jsp.patch > > > To reproduce the problem using example config, go form.jsp, use standard for > qt (it is default) then click Search. -- This message is automatically generated by JIRA. 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] [Updated] (SOLR-2518) Empty of so that it resolves the parent pom from the repositories
[ https://issues.apache.org/jira/browse/SOLR-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriele Kahlout updated SOLR-2518: --- Attachment: relativePath.patch > Empty of so that it resolves the parent pom from the > repositories > - > > Key: SOLR-2518 > URL: https://issues.apache.org/jira/browse/SOLR-2518 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Gabriele Kahlout >Priority: Trivial > Fix For: 3.1.1 > > Attachments: relativePath.patch > > > http://stackoverflow.com/questions/6003831/parent-relativepath-points-at-my-com-mycompanymyproject-instead-of-org-apache/6006098#6006098 -- This message is automatically generated by JIRA. 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] [Created] (SOLR-2518) Empty of so that it resolves the parent pom from the repositories
Empty of so that it resolves the parent pom from the repositories - Key: SOLR-2518 URL: https://issues.apache.org/jira/browse/SOLR-2518 Project: Solr Issue Type: Improvement Affects Versions: 3.1 Reporter: Gabriele Kahlout Priority: Trivial Fix For: 3.1.1 http://stackoverflow.com/questions/6003831/parent-relativepath-points-at-my-com-mycompanymyproject-instead-of-org-apache/6006098#6006098 -- This message is automatically generated by JIRA. 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] [Updated] (SOLR-2517) Use varargs for Field(String name, byte[] value)
[ https://issues.apache.org/jira/browse/SOLR-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriele Kahlout updated SOLR-2517: --- Attachment: SOLR-2517.patch > Use varargs for Field(String name, byte[] value) > > > Key: SOLR-2517 > URL: https://issues.apache.org/jira/browse/SOLR-2517 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Gabriele Kahlout >Priority: Trivial > Attachments: SOLR-2517.patch > > > Really trivial that it might not be worth the attention of an issue, but > since searcher.getSimilarity().encodeNormValue(..) returns a byte instead of > a byte[] it becomes handy (or is there extra info that needs to be put in the > array?). -- This message is automatically generated by JIRA. 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] [Created] (SOLR-2517) Use varargs for Field(String name, byte[] value)
Use varargs for Field(String name, byte[] value) Key: SOLR-2517 URL: https://issues.apache.org/jira/browse/SOLR-2517 Project: Solr Issue Type: Improvement Affects Versions: 3.1 Reporter: Gabriele Kahlout Priority: Trivial Really trivial that it might not be worth the attention of an issue, but since searcher.getSimilarity().encodeNormValue(..) returns a byte instead of a byte[] it becomes handy (or is there extra info that needs to be put in the array?). -- This message is automatically generated by JIRA. 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] (SOLR-2513) Allow to subclass org.apache.solr.response.XMLWriter
[ https://issues.apache.org/jira/browse/SOLR-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033227#comment-13033227 ] Gabriele Kahlout commented on SOLR-2513: +1 for @lucene.internal. I'd use language features such as final only if there was a 'technical' reason (@see http://download.oracle.com/javase/tutorial/java/IandI/final.html). > Allow to subclass org.apache.solr.response.XMLWriter > - > > Key: SOLR-2513 > URL: https://issues.apache.org/jira/browse/SOLR-2513 > Project: Solr > Issue Type: Improvement > Components: Response Writers >Reporter: Gabriele Kahlout >Assignee: Ryan McKinley >Priority: Trivial > Attachments: SOLR-2513.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > Hacking/debugging/extending Solr with one's own ResponseWriter one might want > to inherit functionality from XMLWriter. A trivial example is overriding > writeDate(..) to use a different calendar/format. > I asked about why it's made final on the mailing list[1]. > [1] > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3cbanlktin4mxiybzw3ck-k4gwq4o6nnc2...@mail.gmail.com%3E > -- This message is automatically generated by JIRA. 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] [Created] (SOLR-2513) Allow to subclass org.apache.solr.response.XMLWriter
Allow to subclass org.apache.solr.response.XMLWriter - Key: SOLR-2513 URL: https://issues.apache.org/jira/browse/SOLR-2513 Project: Solr Issue Type: Improvement Components: Response Writers Reporter: Gabriele Kahlout Priority: Trivial Hacking/debugging/extending Solr with one's own ResponseWriter one might want to inherit functionality from XMLWriter. A trivial example is overriding writeDate(..) to use a different calendar/format. I asked about why it's made final on the mailing list[1]. [1] http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3cbanlktin4mxiybzw3ck-k4gwq4o6nnc2...@mail.gmail.com%3E -- This message is automatically generated by JIRA. 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] [Updated] (SOLR-2445) unknown handler: standard
[ https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriele Kahlout updated SOLR-2445: --- Comment: was deleted (was: I've attached a trivial patch that just modifies the form.jsp (useful for scripts).) > unknown handler: standard > - > > Key: SOLR-2445 > URL: https://issues.apache.org/jira/browse/SOLR-2445 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4.1, 3.1, 3.2, 4.0 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: SOLR-2445.patch, qt-form-jsp.patch > > > To reproduce the problem using example config, go form.jsp, use standard for > qt (it is default) then click Search. -- This message is automatically generated by JIRA. 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] [Updated] (SOLR-2445) unknown handler: standard
[ https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriele Kahlout updated SOLR-2445: --- Attachment: qt-form-jsp.patch trivial patch to form.jsp that leaves qt empty (useful for setup scripts and those that need to stick to an 3.1.0 revision). > unknown handler: standard > - > > Key: SOLR-2445 > URL: https://issues.apache.org/jira/browse/SOLR-2445 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4.1, 3.1, 3.2, 4.0 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: SOLR-2445.patch, qt-form-jsp.patch > > > To reproduce the problem using example config, go form.jsp, use standard for > qt (it is default) then click Search. -- This message is automatically generated by JIRA. 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] (SOLR-2445) unknown handler: standard
[ https://issues.apache.org/jira/browse/SOLR-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032216#comment-13032216 ] Gabriele Kahlout commented on SOLR-2445: I've attached a trivial patch that just modifies the form.jsp (useful for scripts). > unknown handler: standard > - > > Key: SOLR-2445 > URL: https://issues.apache.org/jira/browse/SOLR-2445 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4.1, 3.1, 3.2, 4.0 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: SOLR-2445.patch > > > To reproduce the problem using example config, go form.jsp, use standard for > qt (it is default) then click Search. -- This message is automatically generated by JIRA. 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
