moved to maven

[John Wang]

Hi guys:

I have moved bobo to maven and will be doing a release shortly.

Only module I have not moved is bobo-contrib, which I will need
some help with.

-John

[Ken McCracken]

So can we link bobo-contrib to a different lucene-core version in maven?  My guess is its build would remain standalone until the lucene versions can converge.  From the perspective of bobo-contrib it potentially gets a lot cleaner with 4.0 because we can inject ourselves into merge properly, rather than rewrite IndexWriter to add beforeMergeAfterSetup(..).

-Ken

-John

--
You received this message because you are subscribed to the Google Groups "bobo-browse" group.
To post to this group, send email to bobo-...@googlegroups.com.
To unsubscribe from this group, send email to bobo-browse...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bobo-browse?hl=en.

[John Wang]

I think so. Bobo-contrib still uses ant, so you can control which version of any jar you are using.

-John

[Roman_Garcia]

Hi,

I've no idea what are the issues or needs for bobo-contrib in particular.

I just went ahead and "tried" an initial version for a Maven POM for it.

It might be just broken, but just in case it helps create a final version, its there.

https://github.com/romangarcia/bobo

Not sure how you guys expect to package this project. Specially those org/lucene packages.

Let me know if there's something else I can do for this

Roman

[John Wang]

The change looks great, thanks Roman!

Ken, if this looks ok with you, I am gonna pull this patch. Please let me know soon.

-John

--

You received this message because you are subscribed to the Google Groups "bobo-browse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/bobo-browse/-/FjSs7RQ_1okJ.

[Ken McCracken]

So in our projects we pull lucene-3.5 and patch with that IndexWriter class ahead in the classpath.  Will take a look tomorrow or the next at your version.

-Ken

Sent from my Windows Phone

---

From: Roman_Garcia
Sent: 1/17/2012 1:59 PM
To: bobo-...@googlegroups.com
Subject: Re: [bobo-browse] moved to maven

[John Wang]

Cool...

Ken, any thoughts on submit this patch to lucene?

-john

[Roman Garcia]

Right. I just package all sources under the same bobo-contrib-3.0.0-SNAPSHOT.jar. So I guess, what you would need to do, is to make sure you define this artifact "first" in your classpath.

A few notes:

1) I wasn't able to run the ANT build. For some reason, it failed to find a lib/master, lib/test path. So I can't compare both outputs.

2) For some reason, one test is failing (GeoScorerTest) only from Maven (I'm using version 3.0.2 w/ JRE 1.6.0_22). Doesn't fail using Eclipse JUnit runner. Couldn't find anything particular that would make it fail. I'll keep looking...

[Ken McCracken]

I guess we didn't try really hard.  It's not a big change, and it's not really a lucene bug, it's more like a lucene limitation.  It seems to be the only way we could inject ourselves into the index merge stack to manage a secondary index for every segment (we track docids as offsets within a segment).  I will try this question as well tomorrow.

Cheers,

-Ken

Sent from my Windows Phone

---

From: John Wang
Sent: 1/17/2012 8:22 PM

To: bobo-...@googlegroups.com
Subject: Re: [bobo-browse] moved to maven

Cool...

Ken, any thoughts on submit this patch to lucene?

-john

On Tue, Jan 17, 2012 at 4:06 PM, Ken McCracken <ken.mc...@gmail.com> wrote:

[John Wang]

Hi Roman:

     I am pretty sure I broke ant build when I moved to maven :)

-John

[Ken McCracken]

I tried this out, all I can say is I get the same results as Roman.  I don't understand why Eclipse running JUnit4 works, maybe it is the maven Surefire runner causing issues (or Eclipse JUnit4 masking issues)??  It is failing on an "assert" which is present only in certain modes, is that related?

I think this is close but with maven being what it is, we can't switch to maven until it reports that it is successful.  I don't think dropping tests is a good idea either.

-Ken

[Ken McCracken]

you can vote for https://issues.apache.org/jira/browse/LUCENE-3704 if you want.
submitted as a proposed patch.

-Ken

[Geoff Cooney]

Seeing as there's still no hard date for lucene 4.0, it's worth at least asking about having the patch accepted into lucene core.  I think there's a reasonable chance the lucene guys are open to a patch for merging custom segment files but not exactly how we implemented it.  One of our main objectives intiailly was to minimize the divergence from core lucene.  I'd be glad to help if some additional work was required to get the patch accepted to lucene.

It also makes sense to look into creating a patch for custom segment file deletion, as the way we handle that now could strand some geo files, depending on your lucene configuration.

Cheers,

Geoff

[Roman_Garcia]

Ok, the problem was obvious (and I didn't realized until a co-worker pointer me in the right direction)

Eclipse doesn't have assertions enabled by default. Once enabled, tests fail on both environments.

Could this be something related to classpath? Maybe the dependencies I resolved were not the right ones?

For instance, the ANT build had:

lucene-core-3.5-LUCENE-3627.jar

But I only found:

<dependency>
	<groupId>org.apache.lucene</groupId>
	<artifactId>lucene-core</artifactId>
	<version>3.5.0</version>
</dependency>

[Geoff Cooney]

The default test setup in eclipse(I'm pretty sure for the java command-line in general), is to run with assertions off.  If I add the vm argument -ea to eclipse, I can reproduce these test failures.

Cheers,

Geoff

[Roman_Garcia]

Ok, I have no idea what this is all about, but as far as I can tell, that assertion is checking "docid" is never < 0, but the initial state is docid = -1, and I don't see anyone doing a change there.

Silly question: did these tests pass before, with assertions enabled?

[Geoff Cooney]

Hi Roman,

I should've been more clear.  I can reproduce this issue in eclipse on master so this is definitely not a maven issue.  I don't think the tests were previously run with assertions enabled.

In my opinion, the bug is in the assertion itself.  The assertion assumes that at least one document has been read with nextDoc() before advance() is called to skip ahead.  I don't think this is a valid assumption.  Advancing before a docId is read seems like reasonable behavior to me.

Cheers,

Geoff

On Wed, Jan 18, 2012 at 9:59 AM, Roman_Garcia <romang...@gmail.com> wrote:

Ok, I have no idea what this is all about, but as far as I can tell, that assertion is checking "docid" is never < 0, but the initial state is docid = -1, and I don't see anyone doing a change there.

Silly question: did these tests pass before, with assertions enabled?

--

You received this message because you are subscribed to the Google Groups "bobo-browse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/bobo-browse/-/KL7g3TeyBIwJ.

[Roman_Garcia]

Right, got it.

What shall I do about it? Do you want me to fix that?

The change would be:

- assert (NO_MORE_DOCS == docid || target >= docid) && docid >= 0;

+ assert (NO_MORE_DOCS == docid || DOCID_CURSOR_NONE_YET == docid || target >= docid);

Please, let me know

[Roman Garcia]

Ok, I just went ahead and did the change on my fork.

https://github.com/romangarcia/bobo/commit/cb0d824d69487026ea45c525bf1de2069ef43912 

Roman

--
You received this message because you are subscribed to the Google Groups "bobo-browse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/bobo-browse/-/Vj-lBLgXJ1wJ.

[John Wang]

Thanks Roman!

Just pull your changes and pushed to my master. Everything works great!

-John

[Roman Garcia]

Great, glad I could help!

[Ken McCracken]

Since Roman, John, Geoff and I all +1 this fix, I've pushed Roman's fix to http://github.com/senseidb/bobo.git

Thank you Roman!
-Ken

[John Wang]

Awesome! Thanks everyone!

-John