Otis Gospodnetic | 1 Jun 01:12 2006
Picon

Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp

I saw this commit on trunk.  Did you simply make the same change in both branches/lucene_2_0 and in trunk?

How should 2.0 fixes be handled?  Should we fix things in branches/lucene_2_0 and then manually apply the
same change to trunk immediately, or are people using svn merge a la
http://svnbook.red-bean.com/en/1.0/re16.html ?

Thanks,
Otis

----- Original Message ----
From: dnaber <at> apache.org
To: java-commits <at> lucene.apache.org
Sent: Wednesday, May 31, 2006 5:58:01 PM
Subject: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp

Author: dnaber
Date: Wed May 31 14:58:01 2006
New Revision: 410680

URL: http://svn.apache.org/viewvc?rev=410680&view=rev
Log:
backport: make web application demo work again: don't use a QueryParser method that doesn't exist anymore

Modified:
    lucene/java/branches/lucene_2_0/CHANGES.txt
    lucene/java/branches/lucene_2_0/src/jsp/results.jsp

Modified: lucene/java/branches/lucene_2_0/CHANGES.txt
URL: http://svn.apache.org/viewvc/lucene/java/branches/lucene_2_0/CHANGES.txt?rev=410680&r1=410679&r2=410680&view=diff
==============================================================================
(Continue reading)

Ngo, Anh (ISS Southfield | 1 Jun 01:14 2006
Picon

Read Past EOF Exception


Hello,

I am constantly seeing the following exception in my application.  Would
you please show me how to fix this problem?

I am running a java application with java 1.5,lucene 2.0 on linux
operating system.

Thanks

Anh Ngo

Exception: read past EOF
org.apache.lucene.store.FSIndexInput.readInternal(FSDirectory.java:456)
org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.jav
a:64)
org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.j
ava:33)
org.apache.lucene.store.BufferedIndexInput.readBytes(BufferedIndexInput.
java:41)
org.apache.lucene.index.CompoundFileReader$CSIndexInput.readInternal(Com
poundFileReader.java:219)
org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.jav
a:64)
org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.j
ava:33)
org.apache.lucene.store.IndexInput.readVInt(IndexInput.java:56)
org.apache.lucene.index.SegmentTermDocs.next(SegmentTermDocs.java:101)
org.apache.lucene.index.SegmentTermPositions.next(SegmentTermPositions.j
(Continue reading)

Marvin Humphrey | 1 Jun 01:44 2006

Re: Flexible Indexing (was Re: Lucene Planning)

[wild brainstorming...]

Another reason to consolidate the freqs, positions, and boosts/norms  
into one file: we can isolate and distill the code that encodes/ 
decodes that file into a plugin, weakening the current tight coupling  
between Lucene and its file format.  Changing that index format might  
then be a little less painful, as we'd just write a new plugin but  
leave the old one sitting there.  We may not be able to write plugin  
code for the an entire index, but we can write some for each file.

I'm imagining a PostingsWriter interface that each plugin would  
implement, then a complementary PostingsReader.  PostingsReader would  
look a lot like TermPositions does now, but would add getBoost().  To  
this, a POSPostingsReader subclass might add getPartOfSpeech().

In addition to the postings file, we might want a stored fields file  
plugin.  Maybe call those interfaces DBWriter and DBReader.  This is  
trickier, because stored fields are not inverted, so if we used  
different codecs for each field, their output would have to be  
interleaved.  Bleah.  Seems more like we'd want to use a plugin for  
the entire file, with a limited selection of per-field options.

Each segment would have a file recording which codecs were in use.   
Each field name, once associated with a codec, could not be modified  
to use another.  No more reconciliation of indexed/notIndexed,  
omitNorms/notOmitNorms.

Does it make sense then to have the Term Dictionary as a plugin?  I  
think so.  But maybe rather than ordering all terms first by field  
name then by term text, each indexed field should have its own  
(Continue reading)

Doug Cutting | 1 Jun 02:01 2006
Picon

Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp

Otis Gospodnetic wrote:
> How should 2.0 fixes be handled?  Should we fix things in branches/lucene_2_0 and then manually apply the
same change to trunk immediately, or are people using svn merge a la
http://svnbook.red-bean.com/en/1.0/re16.html ?

Generally we should not change things in the branch, but rather continue 
  to develop primarily in trunk, then sync applicable patches to the 
release branch with 'svn merge' when we're preparing to make a point 
release, including the revision range merged in the commit message. 
This makes it much easier to determine which patches have been sync'd to 
the release branch and which have not.

Doug
Ray Tsang | 1 Jun 02:07 2006
Picon

Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp

sometimes there is a 2.0.x branch that's like the trunk 2.0 fixes,
while 2.1 or future releases are being worked on in the real trunk.
that is if older releases are being maintained while new releases are
being worked on.

ray,

On 6/1/06, Doug Cutting <cutting <at> apache.org> wrote:
> Otis Gospodnetic wrote:
> > How should 2.0 fixes be handled?  Should we fix things in branches/lucene_2_0 and then manually apply the
same change to trunk immediately, or are people using svn merge a la
http://svnbook.red-bean.com/en/1.0/re16.html ?
>
> Generally we should not change things in the branch, but rather continue
>   to develop primarily in trunk, then sync applicable patches to the
> release branch with 'svn merge' when we're preparing to make a point
> release, including the revision range merged in the commit message.
> This makes it much easier to determine which patches have been sync'd to
> the release branch and which have not.
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe <at> lucene.apache.org
> For additional commands, e-mail: java-dev-help <at> lucene.apache.org
>
>
shahzad ahsan (JIRA | 1 Jun 06:49 2006
Picon

[jira] Created: (LUCENE-585) Installation of lucene-2.0.0

Installation of lucene-2.0.0
----------------------------

         Key: LUCENE-585
         URL: http://issues.apache.org/jira/browse/LUCENE-585
     Project: Lucene - Java
        Type: Bug

    Versions: 2.0.0    
 Environment: Windows XP
    Reporter: shahzad ahsan 
    Priority: Blocker

I follow the steps given in Build.txt for the installation of lucene-2.0.0.When i run the "ant" the on the
commond prompt, it gives me following error:

E:\20060517\20060531\lucene Search engine\lucene-2.0.0\lucene-2.0.0>ant
Buildfile: build.xml

BUILD FAILED
E:\20060517\20060531\lucene Search engine\lucene-2.0.0\lucene-2.0.0\build.xml:7:
 Cannot find common-build.xml imported from E:\20060517\20060531\lucene Search e
ngine\lucene-2.0.0\lucene-2.0.0\build.xml

Total time: 0 seconds

--

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
(Continue reading)

shahzad ahsan (JIRA | 1 Jun 06:54 2006
Picon

[jira] Commented: (LUCENE-585) Installation of lucene-2.0.0

    [ http://issues.apache.org/jira/browse/LUCENE-585?page=comments#action_12414199 ] 

shahzad ahsan  commented on LUCENE-585:
---------------------------------------

There is no "common-build.xml" file there in the lucene-2.0.0.zip downloaded from site.

> Installation of lucene-2.0.0
> ----------------------------
>
>          Key: LUCENE-585
>          URL: http://issues.apache.org/jira/browse/LUCENE-585
>      Project: Lucene - Java
>         Type: Bug

>     Versions: 2.0.0
>  Environment: Windows XP
>     Reporter: shahzad ahsan 
>     Priority: Blocker

>
> I follow the steps given in Build.txt for the installation of lucene-2.0.0.When i run the "ant" the on the
commond prompt, it gives me following error:
> E:\20060517\20060531\lucene Search engine\lucene-2.0.0\lucene-2.0.0>ant
> Buildfile: build.xml
> BUILD FAILED
> E:\20060517\20060531\lucene Search engine\lucene-2.0.0\lucene-2.0.0\build.xml:7:
>  Cannot find common-build.xml imported from E:\20060517\20060531\lucene Search e
> ngine\lucene-2.0.0\lucene-2.0.0\build.xml
> Total time: 0 seconds
(Continue reading)

Otis Gospodnetic | 1 Jun 07:08 2006
Picon

Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp

Sorry for newbie questions.  I'm at home with CVS branches, merging, etc., but not so with SVN. 
Developing mainly in trunk makes sense.  However, I don't get trunk -> branch to make a point release.  What if
there are other changes already in the trunk (e.g. new features), which we don't want in a point release? 

It sounds like you are describing "selective patching" of the release in the branch with diffs between 2
specific revisions in the trunk.  Is that it? 

Considering trunk is currently at revision 410747, what should N and M be for something that we want to patch
in the branch (trunk->branch), such as that JSP fix that Daniel made earlier?

$ svn merge -r N:M src/jsp/results.jsp

Thanks,
Otis 

----- Original Message ---- 
From: Doug Cutting  
To: java-dev <at> lucene.apache.org 
Sent: Wednesday, May 31, 2006 8:01:13 PM 
Subject: Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt
src/jsp/results.jsp 

Otis Gospodnetic wrote: 
> How should 2.0 fixes be handled?  Should we fix things in branches/lucene_2_0 and then manually apply the
same change to trunk immediately, or are people using svn merge a la
http://svnbook.red-bean.com/en/1.0/re16.html ? 

Generally we should not change things in the branch, but rather continue  
  to develop primarily in trunk, then sync applicable patches to the  
release branch with 'svn merge' when we're preparing to make a point  
(Continue reading)

Hoss Man (JIRA | 1 Jun 07:10 2006
Picon

[jira] Commented: (LUCENE-585) Installation of lucene-2.0.0

    [ http://issues.apache.org/jira/browse/LUCENE-585?page=comments#action_12414200 ] 

Hoss Man commented on LUCENE-585:
---------------------------------

> There is no "common-build.xml" file there in the
> lucene-2.0.0.zip downloaded from site.

I believe this is expected, see below...

> I follow the steps given in Build.txt for the installation of

BUILD.txt does not contain instructions for installing lucene, it is instructions for building lucene
from the source files -- which ar not inlcuded in lucene-2.0.0.zip, that is a binary release containing
only the jars, documentation, and demo code.

If you'd like to install lucene, just copy the jars somewhere you wish to use them -- if you'd like to build
lucene from source please download a source distribition.

(I'm not entirely sure why the build.xml and BUILD.txt files are in the binary distributions at all)

> Installation of lucene-2.0.0
> ----------------------------
>
>          Key: LUCENE-585
>          URL: http://issues.apache.org/jira/browse/LUCENE-585
>      Project: Lucene - Java
>         Type: Bug

>     Versions: 2.0.0
(Continue reading)

mark harwood | 1 Jun 10:22 2006
Picon

RE: Luke - in need of maintainer

I can pick this up, but I don't think I've got much
more bandwidth than Andrzej to work on it.

I certainly don't have the time now for a port to an
Apache-friendly GUI framework but ultimately I think
Luke should end up under the "contrib" section where
it can be managed and benefit from the attention of
more than one maintainer.

Andrzej, have you tried contacting the Thinlet author
to see if he would consider releasing the old Thinlet
code under an Apache license? 

		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Gmane