Re: Forrestize docs

on 2002/12/18 12:00 AM, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: > Forrest is a much more advanced documentation generation system, and, > for example, does doc validation and dead link reporting. > We also have an automatic system that updates the site from CVS every > hour to a test site.

Re: Forrestize docs

on 2002/12/17 11:55 PM, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: > Look who's talking, the one that told all jakarta developers to "quick, > convert all to Maven". I just followed a mail posted here, I did not > take initiatives myself. That is because I still think that Maven is better th

Re: Forrestize docs

on 2002/12/17 7:23 AM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote: > What I _would_ like, on the other hand, is project information that > tools like Maven provide. File, developer, etc. activity, clover > reports, etc. > > Otis +1 If the website is going to be built, it should be built with

Re: Forrestize docs

on 2002/12/16 3:34 PM, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: > - avalon-tigris: http://jakarta.apache.org/avalon/ I don't like how you (or whomever did the stylesheet) got rid of the rounded top left corner edge on the headings. There is a UI design purpose for that edge being there. -

Re: [ANN] NLucene 1.2b released

on 7/12/02 5:22 AM, "Feodor Fitsner" <[EMAIL PROTECTED]> wrote: > Version 1.2b of NLucene has been released, and is available at > > http://sourceforge.net/projects/nlucene > > NLucene is the .NET implementation of the Lucene high-performance, > full-featured text search engine written in Java.

Re: Interesting idea

on 7/10/02 9:35 AM, "Doug Cutting" <[EMAIL PROTECTED]> wrote: > Nilsimsa appears to use what is called a "signature file" approach in > the literature, while Lucene uses an "inverted file". A search on > Google for "signature file versus inverted index" turns up a paper by > Zobel et. al. which

Re: (VERY COOL IDEA) Re: Interesting idea

on 7/8/02 5:06 PM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote: > > --- "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote: >> Very cool Cool! Might make Lucene into a useful plugin for James >> too. > > _That_ (James plugin) is what I have been thinking about lately and was > wondering why nobod

Interesting idea

Adding support to Lucene for Nilsimsa seems like a cool idea... http://ixazon.dynip.com/~cmeclax/nilsimsa.html The index would be the hash and one could use Lucene to rank searches based on the Nilsimsa rating of the results... -jon -- To unsubscribe, e-mail: For

Re: Lucene versions in Bugzilla

on 6/11/02 8:05 AM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote: > it would be good to add that version to > Bugzilla: Done -jon -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: Lucene versions in Bugzilla

on 6/11/02 8:05 AM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote: > With Lucene 1.2 being out Why isn't it on this page? -jon -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: What level JDK compatibility should contributions be at?

on 5/16/02 2:04 PM, "Brian Goetz" <[EMAIL PROTECTED]> wrote: > The majority of sites have moved to 1.3, but the differences in coding > between 1.2 and 1.3 are minor. I would suggest 1.2. +1.2 ;-) -jon -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: RC5 Release

on 5/14/02 10:48 AM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote: > Just out of curiosity, why aren't you branching in CVS so that you don't > have to freeze development (not that there are a lot of commits, but...). > > I'm no CVS management expert, but on the ant-dev team we branched Ant 1.5 > an

Re: Development issues / processes

on 3/27/02 5:08 AM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote: > Do me a favor... You go into "[EMAIL PROTECTED]" and say "can I > have a second CVS module for Lucene, because I want to keep my cvs > repository clean" -- see what kind of reception you get. It is 100% valid for Lucene to creat

Re: Build file changes

on 3/11/02 2:07 PM, "Brian Goetz" <[EMAIL PROTECTED]> wrote: > Simply dividing b.p into three sections, with appropriate comments, > would be helpful. Yea, I just did this earlier today with Scarab's default.properties and I think it helped the readability of it quite a bit. > I'd further consi

Build file changes

Hey all, after all of the discussion that went on, I just want to confirm that the build file changes that I made with regards to the properties settings are indeed cool with everyone and that no one was overly put out by those changes. Any real/major complaints? thanks, -jon -- To unsubs

Re: cvs commit: jakarta-lucene build.xml

on 2/27/02 10:02 PM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote: > The biggest thing Ant and all the projects that use it is STANDARDIZATION! > One way or another, build.properties.sample / default.properties - doesn't > matter functionally. The standardization has to be at a much deeper level > t

Re: cvs commit: jakarta-lucene build.xml

on 2/27/02 7:05 PM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote: > *whew* what a bunch of trouble I stirred up. Please don't associate a discussion with trouble. :-) There is no trouble here...we all have ideas on how to make something work and we are just expressing them... > I apologize folks.

Re: cvs commit: jakarta-lucene build.xml

on 2/27/02 1:43 PM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote: > I imagined build.properties.sample as a mostly blank file with a short > description about it's purpose at the top and maybe one commented out > example for people to follow. > So we wouldn't have to keep properties in sync with

Re: cvs commit: jakarta-lucene build.xml

on 2/27/02 10:08 AM, "Dmitry Serebrennikov" <[EMAIL PROTECTED]> wrote: > As a new and cluless user of Ant, here's my vote: > +1 on not requiring editing of build.xml > +1 on keeping default properties in build.xml > +1 on providing build.properties.sample with comments as to what can > be o

Re: cvs commit: jakarta-lucene build.xml

on 2/26/02 8:23 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote: > The argument of needing both a build.xml and default.properties doesn't > really fly with me. The user shouldn't even have to look at the build.xml > *ever*. > > -jon I liken reading

Re: cvs commit: jakarta-lucene build.xml

on 2/26/02 7:45 PM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote: > Agreed. I would say that this is a good argument for getting rid of > build.properties.sample altogether. Its not really needed, and anyone > wanting to tweak anything would likely have the know-how to figure out which > property t

Re: cvs commit: jakarta-lucene build.xml

eeps all defauilt build info inside build.xml > rather than there being two files necessary. > > Erik > > - Original Message - > From: "Jon Scott Stevens" <[EMAIL PROTECTED]> > To: "Lucene Developers List" <[EMAIL PROTECTED]> > Sent: Tu

Re: cvs commit: jakarta-lucene build.xml

on 2/26/02 5:10 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > - Moved properties from build.properties in here. build.properties should be > removed and replaced by build.properties.sample. -1. A better way to deal with this is to follow what Scarab and other projects do which is to do