build.xml: result of "dist-src" should support "build-contrib"
--
Key: LUCENE-804
URL: https://issues.apache.org/jira/browse/LUCENE-804
Project: Lucene - Java
Issue Type: Task
: > I'm not exactly sure if this is show stopper, but when I get the
: > binary, the build.xml that is included is not usable b/c it is
: > missing common-build.xml.
: Oops... I think we should fix this for the release if at all
: possible. It is handy for folks to be able to pull down a buildab
: Unless expected out-of-the-box behavior for the source pack
: includes compilable contrib/*.
contrib/*/lib is explicitly excluded from srource distributions in the
build.xml ...
1 file only in 507610:
: > index.html
the top level index.html file should *not* be in any releases
+1
Unless expected out-of-the-box behavior for the source pack
includes compilable contrib/*.
So I'm not sure if this is a stopper... more details below...
---
> Checking md5's and asc's of 3 of the files was OK.
> lucene-2.1.0-src.zip
> lucen
On Feb 14, 2007, at 2:18 PM, Grant Ingersoll wrote:
I'm not exactly sure if this is show stopper, but when I get the
binary, the build.xml that is included is not usable b/c it is
missing common-build.xml.
It may not be a big deal, b/c you don't necessarily need to build
anything since it
Checking md5's and asc's of 3 of the files was OK.
lucene-2.1.0-src.zip
lucene-2.1.0.zip
lucene-core-2.1.0.jar
Comparing the content of lucene-2.1.0-src.zip with revision 507610
shows some differences:
3 folders and files only in 2.1.0:
[1] contrib/db/bdb/lib
[2] contrib/db/bdb
[
https://issues.apache.org/jira/browse/LUCENE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473274
]
Grant Ingersoll commented on LUCENE-803:
This probably goes for IntelliJ too
*.iml
*.iws
*.ipr
> add svn ig
add svn ignores for eclipse artifacts
-
Key: LUCENE-803
URL: https://issues.apache.org/jira/browse/LUCENE-803
Project: Lucene - Java
Issue Type: Improvement
Reporter: Steven Parkes
Ass
[
https://issues.apache.org/jira/browse/LUCENE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Parkes updated LUCENE-802:
-
Lucene Fields: [Patch Available] (was: [Patch Available, New])
> lucene jars should include LiCE
[
https://issues.apache.org/jira/browse/LUCENE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Parkes updated LUCENE-802:
-
Lucene Fields: [New, Patch Available] (was: [New])
> lucene jars should include LiCENSE and NOTI
[
https://issues.apache.org/jira/browse/LUCENE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Parkes reassigned LUCENE-802:
Assignee: Steven Parkes
> lucene jars should include LiCENSE and NOTICE
> -
[
https://issues.apache.org/jira/browse/LUCENE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Parkes updated LUCENE-802:
-
Attachment: LUCENE-802.txt
> lucene jars should include LiCENSE and NOTICE
>
lucene jars should include LiCENSE and NOTICE
-
Key: LUCENE-802
URL: https://issues.apache.org/jira/browse/LUCENE-802
Project: Lucene - Java
Issue Type: Improvement
Reporter: Steven Par
Okay, +1
Had no problem verifying anything else on either Gentoo or Windows XP
Pro, both x64.
I'll create a JIRA to get the files in. Even if we don't distribute the
raw file (which I couldn't find any other projects which do, though I
didn't look too hard), I did notice that other projects always
OK, I've removed the raw jar, and a maven release will have to wait
until someone fixes things up. The normal release can proceed.
I promised to be release-manager-lite... I'll do the release
mechanics, but I don't currently have time to do much else.
-Yonik
On 2/14/07, Steven Parkes <[EMAIL P
I'm not exactly sure if this is show stopper, but when I get the
binary, the build.xml that is included is not usable b/c it is
missing common-build.xml.
It may not be a big deal, b/c you don't necessarily need to build
anything since it is a binary release, yet, the first thing I tried
w
On 2/14/07, mark harwood <[EMAIL PROTECTED]> wrote:
Yonik, thanks for the ConstantScoreQuery.getFilter() addition yesterday.
Following the same principle of "enabling query inspection", any objections to
exposing read-only access to the criteria for a RangeFilter?
I'm happy to make the change
I'm new to the release process, so I'm trying to understand it at the
same time as checking out the candidate.
One thing I noticed is that the raw jar doesn't contain LICENSE or
NOTICE files, a la http://www.apache.org/dev/release.html. To wit:
Can I Distribute A Raw Artifact?
AS
+1
On Feb 14, 2007, at 12:20 PM, Yonik Seeley wrote:
Release artifacts for review are at
http://people.apache.org/~yonik/staging_area/lucene/
Please vote to officially release these packages as Lucene 2.1.
-Yonik
-
To unsubs
+1
I pulled down the zip & src zip, was able to build the core/demo jars
from sources, pass all unit tests (clean), and run the
IndexFiles/SearchFiles demos. I also confirmed the md5's & asc's on
all 4.
Mike
On Wed, 14 Feb 2007 12:20:56 -0500, "Yonik Seeley" <[EMAIL PROTECTED]>
said:
> Release
+1
Michael
Yonik Seeley wrote:
Release artifacts for review are at
http://people.apache.org/~yonik/staging_area/lucene/
Please vote to officially release these packages as Lucene 2.1.
-Yonik
-
To unsubscribe, e-mail: [EMAIL
+1
Otis
P.S.
There is a JIRA issue about the jars not getting pushed to ibiblio for Maven
folks. You may want to make sure this step is done right this time and update
the release howto on zee wiki.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ -
Release artifacts for review are at
http://people.apache.org/~yonik/staging_area/lucene/
Please vote to officially release these packages as Lucene 2.1.
-Yonik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Yonik, thanks for the ConstantScoreQuery.getFilter() addition yesterday.
Following the same principle of "enabling query inspection", any objections to
exposing read-only access to the criteria for a RangeFilter?
I'm happy to make the change but possibly unable to access SVN in time if a 2.1
r
On Wed, 14 Feb 2007 15:23:57 +0100, "Wolf Siberski" <[EMAIL PROTECTED]>
said:
> With respect to the general evolution of Lucene, IMHO we have
> at least two types of users, with different needs:
> a) Lucene experts which use it as low level building block
> within their highly customized info
robert engels schrieb:
Lucene is not a word processor. It is a development library. I think an
understanding of any development library is essential to using it
properly.
With respect to the specific change (see subject) under discussion,
I don't see how it affects Lucene design or performanc
: Lucene is not a word processor. It is a development library. I think
: an understanding of any development library is essential to using it
: properly. Once you have even a basic understanding of the Lucene
: design, it is very clear as to why deletes are performed using the
: IndexReader.
Unde
: My concern is, to get the raw speed of Lucene, you got to get to the basics.
: If we start to apply layers upon layers of code to just mask off the
: internals of Lucene, it will not do any good.
one of the reasons for the approach of this NewIndexModifier/IndexWriter
approach to supporting del
28 matches
Mail list logo
