Hi Murray, thanks for looking into it :-)
My findings so far: Lucene index related test are already in the main build, so that part should be covered, and regarding the Tika-related ones, they don't interact with Lucene, they only parse a couple of files, and check the extracted information (which is afterwards sent to Lucene, but that's outside the scope of the test). I was suspecting of something weird on the node in which the build kept running and made a new Jenkins job to do some tests (and avoid spamming dev@j.a.o) at https://builds.apache.org/job/jspwiki-test/ Funnily now I'm getting 7 test failures on jspwiki-main, from tests long untouched, on: * CommandResolverTest.java:59 * PageCommandTest.java:53 Both lines perform the same action: TestEngine.deletePage(..), so I'm testing other nodes right now, because it seems I get different exceptions on different nodes. Also, maybe unrelated, but given that the maven build is running with -up, the jacoco plugin should always be 0.8.3 (the latest one), but I get different versions on different nodes, which makes me suspect of the environment.. In any case, I'm still digging.. best regards, juan pablo On Sun, May 5, 2019 at 12:49 AM Murray Altheim <murra...@altheim.com> wrote: > Hi Juan Pablo, > > I'll possibly be able to look into this early this work week, but my > suspicion is that Lucene itself is having trouble being instantiated. > As we already have Lucene in the mix, you'll have to be sure that > both Lucene engines are the same version and that you can actually > create both an Indexer and a Finder. I'd suggest creating a unit > test that does that, then tries to create both JSPWiki's normal > search provider, then in the same test try creating the Tika version. > If that works generally you'd be good to go. > > Hope that helps. > > Cheers, > > Murray > > On 5/05/19 10:14 AM, Juan Pablo Santos Rodríguez wrote: > > Hi, > > > > latest commits on master brought a TikaSearchProvider, contributed by Ulf > > Dittmer (JSPWIKI-469). I've added some tests to it, but somehow I'm not > > getting them passing at builds.apache.org. Given that I've been able to > > deploy a snapshot from my local pc, with those tests successfully > running, > > I'm a bit blind on what is happening at builds.a.o. At first I thought > > there were some concurrency issues which prevented the test from running > at > > builds.a.o, but right now the offending test really unit tests, and > doesn't > > rely on background threads finishing indexing attachment on time. > > > > More specifically, current build failure yields: > > > > [ERROR] testGetAttachmentContent Time elapsed: 5.163 s <<< ERROR! > > java.lang.NullPointerException > > at > org.apache.wiki.search.tika.TikaSearchProviderTest.testGetAttachmentContent(TikaSearchProviderTest.java:58) > > > > with line 58 on TikaSearchProviderTest being: > > String pdfIndexed = tsp.getAttachmentContent( attPdf ); > > > > So tsp is the only thing there capable of throwing a NPE. However, tsp is > > obtained as: > > TikaSearchProvider tsp = ( TikaSearchProvider > > )engine.getSearchManager().getSearchEngine(); > > > > and the execution log shows that tsp can't be null: > > > > 2019-05-04 20:59:01,355 [main] DEBUG > > org.apache.wiki.search.SearchManager - Loaded search provider > > org.apache.wiki.search.tika.TikaSearchProvider@7a63c618 > > > > so, what I'm missing? can anyone reproduce that NPE?? I could change the > > test so tsp gets instantiated and set up manually but that seems > > cumbersome, and shouldn't be needed > > > > > > thx in advance, > > juan pablo > > > > -- > > ........................................................................... > Murray Altheim <murray18 at altheim dot com> = = === > http://www.altheim.com/murray/ === > === > = = > === > In the evening > The rice leaves in the garden > Rustle in the autumn wind > That blows through my reed hut. > -- Minamoto no Tsunenobu > >
