Ryan McKinley wrote:
If someone is
using /trunk, they should be ready for changes like this to happen.
+1
Doug
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lu
[
https://issues.apache.org/jira/browse/LUCENE-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670103#action_12670103
]
Doug Cutting commented on LUCENE-1534:
--
Now, on the cusp of 3.0, might be a
[
https://issues.apache.org/jira/browse/LUCENE-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669754#action_12669754
]
Doug Cutting commented on LUCENE-1534:
--
sumOfSquaredWeights properly normal
[
https://issues.apache.org/jira/browse/LUCENE-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669750#action_12669750
]
Doug Cutting commented on LUCENE-1534:
--
I've always found "idf squared
Uwe Schindler wrote:
Why not refer?
I would not veto the refer, but I also would not vote for it and would
not add it myself. As a developer, when I want to see unreleased
javadocs, I build them. Posting unreleased documentation has risks.
Folks might find them, develop software against th
Doug Cutting wrote:
We should add a robots.txt for Hudson that prohibits crawling, no?
At my request, Nigel just added one.
Doug
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e
Chris Hostetter wrote:
: > I think, the outdated docs should be removed from the server to also
: > disappear from search engines.
We do not want unofficial builds to be indexed by search engines anyway.
Folks who're searching for information about Lucene should not be
referred to unreleased
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667326#action_12667326
]
Doug Cutting commented on LUCENE-1483:
--
> In principle, the MultiSear
[
https://issues.apache.org/jira/browse/LUCENE-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663090#action_12663090
]
Doug Cutting commented on LUCENE-1518:
--
> Why 1.0 and not 0.0?
0.0 does se
[
https://issues.apache.org/jira/browse/LUCENE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663055#action_12663055
]
Doug Cutting commented on LUCENE-1345:
--
Uwe> Maybe I should create an new JIR
robert engels wrote:
Can something be offensive if its a statement of fact ? If you believe
it is (under definition #3), then his remarks to me were just as
offensive - as they caused me much displeasure and resentment. So please
dress him down as well.
His comments were on-topic. The topic
robert engels wrote:
You are a moron. And I don't mean that in a offensive way - I am using
the secondary definition.
*2**:* a very stupid person
That's still offensive and totally unacceptable here. Please refrain
from making ad-hominem remarks and stick to discussing the issues.
Thanks
[
https://issues.apache.org/jira/browse/LUCENE-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662247#action_12662247
]
Doug Cutting commented on LUCENE-1476:
--
bq. To really tighten this loop, you hav
Robert Engels wrote:
Do what you like. You obviously will. This is the problem with the Lucene
managers - the problems are only the ones they see - same with the solutions.
If the solution (or questions) put them outside their comfort zone, they are
ignored or dismissed in a tone that is des
Andrzej Bialecki wrote:
No matter whether you are right or wrong, please keep a civil tone on
this public forum.
+1 Ad-hominem remarks are anti-community.
Doug
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.or
Michael McCandless wrote:
So then I think we should start with approach #2 (build real-time on
top of the Lucene core) and iterate from there. Newly added docs go
into a tiny segments, which IndexReader.reopen pulls in. Replaced or
deleted docs record the delete against the right SegmentReader
Jason Rutherglen wrote:
2) Implement realtime search by incrementally creating and merging
readers in memory. The system would use MemoryIndex or
InstantiatedIndex to quickly (more quickly than RAMDirectory) create
indexes from added documents.
As a baseline, how fast is it to simply use RAM
Michael McCandless wrote:
My feeling is if nobody steps up (has the "itch" & time) to work on
these big changes (which haven't really proceeded beyond
brainstormings on how we might fix them) soonish, we should not block
2.9 for them...
+1
Doug
Jason Rutherglen wrote:
Broadly speaking, what areas are we looking to create new APIs for in
2.9? How dramatic are we looking to go?
That's not really the question. We shouldn't rush to get big API
changes in. Rather we should continue to cautiously evolve the API.
Periodically, when larg
Michael McCandless wrote:
Are you saying we can deprecate these classes in 2.9, and all methods
whose signature involves one of these classes, without offering the
new classes?
No. Folks should be able to recompile w/o deprecation warnings against
2.9, then upgrade to 3.0. Features should no
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657476#action_12657476
]
Doug Cutting commented on LUCENE-1483:
--
> Woah! Don't make me switch al
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657466#action_12657466
]
Doug Cutting commented on LUCENE-1483:
--
bq. I would actually be fine with kee
Jason Rutherglen wrote:
Decoupling IndexReader would for 3.0 would be great. This includes
making public SegmentReader, MultiSegmentReader.
A constructor like new SegmentReader(TermsDictionary termDictionary,
TermPostings termPostings, ColumnStrideFields csd, DocIdBitSet deletedDocs);
Where
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656073#action_12656073
]
Doug Cutting commented on LUCENE-1483:
--
> public abstract void setBase(i
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656071#action_12656071
]
Doug Cutting commented on LUCENE-1473:
--
> Therefore the patch is to be t
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655894#action_12655894
]
Doug Cutting commented on LUCENE-1473:
--
> shift the problem around but do not
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655812#action_12655812
]
Doug Cutting commented on LUCENE-1483:
--
> If users are using a HitCollector a
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655806#action_12655806
]
Doug Cutting commented on LUCENE-1473:
--
Thanks, Wolf, this looks like a promi
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655761#action_12655761
]
Doug Cutting commented on LUCENE-1483:
--
Could we add a new class like
{code}
pu
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654970#action_12654970
]
Doug Cutting commented on LUCENE-1483:
--
> But for IndexSearcher(Multi*Reader)
[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654940#action_12654940
]
Doug Cutting commented on LUCENE-1483:
--
> make a HitCollector that gath
[
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654875#action_12654875
]
Doug Cutting commented on LUCENE-1482:
--
safeDebugMsg is protected in a public c
[
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654545#action_12654545
]
Doug Cutting commented on LUCENE-1482:
--
> Should I attach the slf4j jars sep
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654513#action_12654513
]
Doug Cutting commented on LUCENE-1473:
--
Would it take any more lines of cod
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653972#action_12653972
]
Doug Cutting commented on LUCENE-1473:
--
> I guarantee 2.9 and above classes
Jason Rutherglen wrote:
I think it's best to implement Externalizable as long as someone is
willing to maintain it. I commit to maintaining the Externalizable
code.
We need to agree to maintain things as a community, not as individuals.
We can't rely on any particular individual being aroun
John Wang wrote:
This has been gone back and forth on this thread already. Again,
I agree it is not the perfect solution. I am comparing that to the
current behavior, I don't think it is worse. (Only in my opinion).
So, if it's good enough for you, a user of java serialization, then
pe
John Wang wrote:
If we were to depend on a jar for logging, then why not log4j or
commons-logging?
Lucene is used by many applications. Many of those applications already
perform some kind of logging. We'd like whatever Lucene adds to fit in
with their existing logging framework, not confli
John Wang wrote:
Also, if you find us addressing this issue being a hassle, e.g.
addressing serialization in lucene is an incorrect thing to do, feel
free to let us know and we can close the bug and terminate the thread.
I don't know whether cross-version serialization belongs in Lucene. We
Shai Erera wrote:
Perhaps instead of introducing Java logging then (if you're too against
it), we could introdue a static InfoStream class, with a static
message() and isVerbose() methods.
It's tempting to add our own logging API, as you suggest, but I fear
that would re-invent what so many h
The infoStream stuff goes back to 1997, before there was log4j or any
other Java logging framework.
There's never been a big push to add logging to Lucene. It would add a
dependency, and Lucene's jar has always been standalone, which is nice.
Dependencies can conflict. If Lucene requires one
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653869#action_12653869
]
Doug Cutting commented on LUCENE-1473:
--
> How to write a unit test for m
John Wang wrote:
Thus we are enforcing users
that care about Serialization to use the release jar.
We already encourage folks to use a release jar if possible. So this is
not a big change. Also, if folks choose to build their own jar, then
they are expected to use that same jar everywhere,
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653553#action_12653553
]
Doug Cutting commented on LUCENE-1473:
--
> This discussion has digressed to
Jason Rutherglen wrote:
A relatively simple patch such as 1473 Serialization
represents this well.
LUCENE-1473 is an incomplete patch that proposes to commit the project
to new back-compatibility requirements. Compatibility requirements
should not be added lightly, but only deliberately, as
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653413#action_12653413
]
Doug Cutting commented on LUCENE-1473:
--
> Serialization between VM1 and VM2 o
John Wang wrote:
I agree with the process itself, what would make it better is
some transparency on how patches/issues are evaluated to be committed.
To be clear: there is no forum for communication about patches except
this list, and, by extension, Jira. The process of patch evaluation is
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652965#action_12652965
]
Doug Cutting commented on LUCENE-1473:
--
> I'm not sure why you and Doug
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652939#action_12652939
]
Doug Cutting commented on LUCENE-1473:
--
The documentation should probably be f
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652932#action_12652932
]
Doug Cutting commented on LUCENE-1473:
--
> Doesn't Hadoop handle versioni
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652888#action_12652888
]
Doug Cutting commented on LUCENE-1473:
--
bq. If it is not meant to be serialized,
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652882#action_12652882
]
Doug Cutting commented on LUCENE-1473:
--
> But, what's now being asked f
John Wang wrote:
If you guys need help, maybe you guys should expand your committer list?
Committers are added when they've contributed a series of high-quality
patches that have been committed, and demonstrated their ability to be
easy to work with. Displaying anger is not a good way to bec
[
https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652591#action_12652591
]
Doug Cutting commented on LUCENE-1473:
--
The attached patch optimizes
[
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652194#action_12652194
]
Doug Cutting commented on LUCENE-1472:
--
ThreadLocal?
> DateTools.stringToDat
[
https://issues.apache.org/jira/browse/LUCENE-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650344#action_12650344
]
Doug Cutting commented on LUCENE-1451:
--
A bit of history, if any care.
Origin
Michael McCandless wrote:
I do worry that wholesale formatting changes will obsolete pending
patches
Note that 'patch -l' will ignore whitespace, permitting indentation
changes w/o breaking patches.
Doug
-
To unsubscribe, e
Steven A Rowe wrote:
This would not entirely fix the issue; each version's javadocs should link to the same version of the site docs, rather than to the latest version (which is what I assume you mean here).
Right. The javadocs should use a relative link to point to versioned
docs. But, if
Broken links in released docs might be fixed by adding redirects to the
website, by editing:
http://svn.apache.org/repos/asf/lucene/.htaccess
The trunk javadocs should not be published on the website. We should
only publish released documentation.
Doug
Steven A Rowe wrote:
When the Lucene
[
https://issues.apache.org/jira/browse/LUCENE-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645565#action_12645565
]
Doug Cutting commented on LUCENE-1422:
--
> But: what if you revert all changes
Michael Busch wrote:
Currently Lucene's backwards compatibility policy states: "That's to
say, any code developed against X.0 should continue to run without
alteration against all X.N releases." In LUCENE-1422 the question came
up if this statement should apply to public and protected APIs only
[
https://issues.apache.org/jira/browse/LUCENE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641132#action_12641132
]
Doug Cutting commented on LUCENE-1426:
--
+1 This sounds like a great way to appr
[
https://issues.apache.org/jira/browse/LUCENE-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639495#action_12639495
]
Doug Cutting commented on LUCENE-1422:
--
prototypeToken() and nextToken() seem
Michael Busch wrote:
public abstract boolean nextToken() throws IOException;
What's the point of a separate Token and TokenStream if there's only a
single Token per TokenStream? If that's really the direction we'll go,
then all of the Token methods should be on TokenStream, and Token sho
Yonik Seeley wrote:
AIUI, Apache only officially releases source code, so any binaries are
artifacts or derivatives of a release, not really the release itself.
Unless those artifacts include the source code. It's best to vote on a
signed tgz file than a subversion tag, since the latter can c
Chris Hostetter wrote:
Bingo. Even if we know 100% when/how the Lucene logo can be used, and we
write lots of words about it on the website to make it clear to people
when/how they can use it, people still may avoid it out of legal paranoia.
Long ago, we used to do that.
http://web.archive
To be clear, one can use the official Lucene logo for this purpose,
right? Apache doesn't want its trademarks used to describe other
products, but other folks using the Lucene logo to refer to Apache
Lucene is fine. So a link to http://lucene.apache.org/ whose anchor is
"Powered by " is legal
[
https://issues.apache.org/jira/browse/LUCENE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618001#action_12618001
]
Doug Cutting commented on LUCENE-1340:
--
> I firmly believe there is a wa
This also reminds me of the "pulsing" technique described in:
http://citeseer.ist.psu.edu/cutting90optimizations.html
Doug
eks dev wrote:
It seams someone else had the same idea to "inline" very short postings into
term dictionary (even for in-memory index) ans save one pointer (and seek, in
Chris Hostetter wrote:
I've added you to the committer group in Jira .. you should be able to
assign issues to yourself, and resolve issues now.
You mean 'role', right? We don't use Jira groups much anymore.
Doug
-
To unsub
[
https://issues.apache.org/jira/browse/LUCENE-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601336#action_12601336
]
Doug Cutting commented on LUCENE-1294:
--
I too always felt this a feature, albe
[
https://issues.apache.org/jira/browse/LUCENE-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598105#action_12598105
]
Doug Cutting commented on LUCENE-1290:
--
FWIW, the Hits API was originally desi
The conventional use of ngrams when searching is not to treat them as a
set but a sequence. Thus, for "foola" you could index the sequence
["_f", "fo", "oo", "ol", "la", "a_"], and then search for the phrase
["oo", "ol"] to find all occurences of "ool". This is useful in
languages that use l
[
https://issues.apache.org/jira/browse/LUCENE-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583808#action_12583808
]
Doug Cutting commented on LUCENE-1255:
--
Hoss: you're right, the change I
[
https://issues.apache.org/jira/browse/LUCENE-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583797#action_12583797
]
Doug Cutting commented on LUCENE-1255:
--
Since the increment is relative to the p
[
https://issues.apache.org/jira/browse/LUCENE-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582442#action_12582442
]
Doug Cutting commented on LUCENE-1231:
--
So there are a number of features t
robert engels wrote:
Some would argue that all that Field needs is
FieldData getField(String name); and void setField(String name,FieldData
data);
and FieldData has
toBytes(); fromBytes()
Isn't hindsight wonderful!
Writing custom versions of IndexReader and IndexWriter was very
difficult
Steven A Rowe wrote:
In the comments on the blog post, the author (Kirill Osenkov) agrees with a dissenter
(Alexander Jung, a.k.a. "AJ.NET"), who re-states the rule of thumb as:
"An interface should define at most one contract."
But what if you want to expand the contract? For example, Field
Chris Hostetter wrote:
in my opinion other blog he links to hits the nail on the head a
little better (i remember reading this last year) ...
http://kirillosenkov.blogspot.com/2007/08/choosing-interface-vs-abstract-class.html
The rule of thumb there is good too:
"An interface should define a
[
https://issues.apache.org/jira/browse/LUCENE-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581662#action_12581662
]
Doug Cutting commented on LUCENE-1231:
--
How would this compare to making the sto
robert engels wrote:
The problem with abstract classes, is that any methods you provide
"know" something of the implementation, unless the methods are
implemented solely by calling other abstract methods (which is rarely
the case if the abstract class contains ANY private members).
Yes, abstr
Chris Hostetter wrote:
Committers tend to prefer abstract classes for extension points because it
makes it easier to support backwards compatibility in the cases were we
want to add methods to extendable APIs and the "default" behavior for
these new methods is simple (or obvious delegation to e
[
https://issues.apache.org/jira/browse/LUCENE-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated LUCENE-1217:
-
Description:
Field class can hold three types of values,
See: AbstractField.java protected
[
https://issues.apache.org/jira/browse/LUCENE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571553#action_12571553
]
Doug Cutting commented on LUCENE-954:
-
Disabling score normalization in Hits s
Michael McCandless wrote:
In fact I've found you need to pursue both the 2x type gains and also
the many smaller ones, to reach good performance.
+1 Put another way, you must address both the asymptotic behavior and
the constant factors. A good order-of-algorithms implementation is
worthles
Doug Cutting wrote:
The linux
kernel dynamically increases the readahead window based on the access
pattern: the more you read sequentially, the larger the readahead window.
Sorry, it appears that's in 2.6.23, which isn't yet broadly used.
http://kernelnewbies.org/Linux_2
robert engels wrote:
But that would mean we should be using at least 250k buffers for the
IndexInput ? Not the 16k or so that is the default.
Is the OS smart enough to figure out that the file is being sequentially
read, and adjust its physical read size to 256k, based on the other
concurrent
[
https://issues.apache.org/jira/browse/LUCENE-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567115#action_12567115
]
Doug Cutting commented on LUCENE-1169:
--
> iterator.skipTo(itera
Michael McCandless wrote:
Merging is far more IO intensive. With mergeFactor=10, we read from
40 input streams and write to 4 output streams when merging the
tii/tis/frq/prx files.
If your disk can transfer at 50MB/s, and takes 5ms/seek, then 250kB
reads and writes are the break-even point, w
Ning,
I am also interested in starting a new project in this area. The
approach I have in mind is slightly different, but hopefully we can come
to some agreement and collaborate.
My current thinking is that the Solr search API is the appropriate
model. Solr's facets are an important featur
[
https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565917#action_12565917
]
Doug Cutting commented on LUCENE-1157:
--
Maybe we can make the links to the nig
[
https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565843#action_12565843
]
Doug Cutting commented on LUCENE-1157:
--
Sure, it makes sense to make changes
[
https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565820#action_12565820
]
Doug Cutting commented on LUCENE-1157:
--
I worry that the nightly build documenta
[
https://issues.apache.org/jira/browse/LUCENE-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565815#action_12565815
]
Doug Cutting commented on LUCENE-1044:
--
> deprecate autoCommit=true entir
Michael Busch wrote:
Doug Cutting wrote:
/www/lucene.apache.org/java/docs/api/.htaccess
/www/lucene.apache.org/java/docs/nightly/api/.htaccess
I just changed these to files to redirect to the new location:
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc/.
Are these in
Chris Hostetter wrote:
the only .htaccess
files i can find anywhere under
https://svn.apache.org/repos/asf/lucene/java/site or
https://svn.apache.org/repos/asf/lucene/java/trunk only contain
"AddDefaultCharset off"
There are more:
> find /www/lucene.apache.org/ -name .htaccess
/www/lucene.a
[
https://issues.apache.org/jira/browse/LUCENE-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561778#action_12561778
]
Doug Cutting commented on LUCENE-1121:
--
For Hadoop, we've seen si
[
https://issues.apache.org/jira/browse/LUCENE-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561539#action_12561539
]
Doug Cutting commented on LUCENE-1121:
--
What JVM were these tests run with?
&
Grant Ingersoll wrote:
Does anyone have experience w/ how other open source projects deal with
this?
Use abstract base classes instead of interfaces: they're much easier to
evolve back-compatibly. In Hadoop, for example, we really wish that
Mapper and Reducer were not interfaces and are very
Grant Ingersoll wrote:
1. We add a new section to CHANGES for each release, at the top where we
can declare what deprecations will be removed in the _next_ release
(major or minor) and also any interface API changes
2. When deprecating, the @deprecate tag should declare what version it
will be
1 - 100 of 585 matches
Mail list logo
