Yeah, sounds like we have the same things in mind here. In fact, this
is pretty similar to what we discussed a while ago on LUCENE-2026 I think.
SegmentWriter could be a higher level interface with more than one
implementation. E.g. there could be one SegmentWriter that supports
appending
With DocumentsWriterPerThread we can allow 2GB per thread, so that
should be a good step forward.
For realtime indexing on the RAM buffer I'm planning to remove even that
per-thread limit, because then you really want to make use of all the
RAM you have available on your machine.
Michael
+1
Michael
On 4/26/10 8:59 AM, Michael McCandless wrote:
This is a vote for the proposal discussed on the 'Proposal about
Version API relaxation' thread. This thread replaces the first
VOTE thread!
The vote is to open up a separate parallel line of development, called
unstable (on trunk),
Hi All,
When working on large patches, such as LUCENE-2324, I find it always
troublesome to use patch files only to track progress. Since branching
in svn works fine now (since 1.5) I'd like to create a branch for 2324.
The big advantage is that everyone can track progress much more easily
OK cool. I'll start the new realtime branch soon!
Michael
On 6/10/10 9:30 AM, karl.wri...@nokia.com wrote:
I technically can't vote, but if I could I would say +1 to option 2 as well.
Karl
-Original Message-
From: ext Mark Miller [mailto:markrmil...@gmail.com]
Sent: Thursday, June
+1
smoketest succeeded on macos 10.7.4.
Michael
On 10/6/12 1:10 AM, Robert Muir wrote:
artifacts here: http://s.apache.org/lusolr40rc2
Thanks for the good inspection of rc#1 and finding bugs, which found
test bugs and other bugs!
I am happy this was all discovered and sorted out before
After merging trunk into the RT branch it's finally compiling again and
up-to-date.
Several tests are failing now after the merge (43 out of 1427 are
failing), which is not too surprising, because so many things have
changed (segment-deletes, flush control, termsHash refactoring, removal
of
On 1/16/11 11:08 AM, Shai Erera wrote:
I think the reasonable solution is to have a modules/maven package,
with build.xml that generates whatever needs to be generated. Whoever
cares about maven should run the proper Ant targets, just like whoever
cares about Eclipse/IDEA can now run ant
On 1/17/11 8:06 AM, Steven A Rowe wrote:
On 1/17/2011 at 1:53 AM, Michael Busch wrote:
I don't think any user needs the ability to run an ant target on
Lucene's sources to produce maven artifacts
I want to be able to make modifications to the Lucene source, install Maven
snapshot artifacts
On 1/17/11 12:27 PM, Steven A Rowe wrote:
This makes zero sense to me - no one will ever make their own POMs
I did :) (for a different project though).
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For
On 1/18/11 9:13 AM, Robert Muir wrote:
I can't help but remind myself, this is the same argument Oracle
offered up for the whole reason hudson debacle
(http://hudson-labs.org/content/whos-driving-thing)
Declaring that I have a secret pocket of users that want XYZ isn't
open source consensus.
On 1/18/11 10:44 AM, Mark Miller wrote:
From my point of view, but perhaps I misremember:
At some point, Grant or someone put in some Maven poms.
I did. :) It was a ton of work and especially getting the
maven-ant-tasks to work was a nightmare!
I don't think anyone else really paid
It's sad how aggressive these discussions get. There's really no reason.
On 1/18/11 1:10 PM, Robert Muir wrote:
On Tue, Jan 18, 2011 at 4:06 PM, Grant Ingersollgsing...@apache.org wrote:
In other words, I don't see consensus for dropping it. When you have it, get
back to me.
Thats not how
Oh my god, Uwe, I was hoping you would never write a sophisticated™
backwards® compatibility layer again!
Michael
On 1/24/11 12:39 PM, Uwe Schindler wrote:
+1
I also have an idea from the attributes and TokenStream policeman. So I could
even help mentoring.
Uwe
Simon
I just ran this test locally ~15 times and no failure. Weird... I'll
keep looking
On 2/22/11 11:29 PM, Simon Willnauer wrote:
hmm maybe this was caused by LUCENE-2881 but I am not sure. I try to
dig this afternoon...
simon
On Wed, Feb 23, 2011 at 4:11 AM, Apache Hudson Server
I was also able to reproduce this failure locally.
So the problem only happens for segments that had document(s) with term
vectors, but which all hit non-aborting exceptions. In that case the
corresponding FieldInfo(s) will have term vectors enabled, but no TV
files will have been written
Well, after LUCENE-2881 assigning the same fieldNumber to the same
fieldName across segments is best effort - not guaranteed anymore. It
looks like in most cases it works fine, just very rarely we get
different field numbers. I don't see how we can improve the best
effort, because I don't
On 2/27/11 2:47 AM, Simon Willnauer wrote:
On Sat, Feb 26, 2011 at 11:02 PM, Michael Buschbusch...@gmail.com wrote:
Well, after LUCENE-2881 assigning the same fieldNumber to the same fieldName
across segments is best effort - not guaranteed anymore. It looks like in
most cases it works fine,
Yes, I committed LUCENE-5401. Thanks for waiting!
On 1/16/14 11:05 AM, Simon Willnauer wrote:
seems like we are good to go
simon
On Thu, Jan 16, 2014 at 1:59 PM, Simon Willnauer
simon.willna...@gmail.com wrote:
mark, we may wait for
https://issues.apache.org/jira/browse/LUCENE-5401 to be
Hi All,
At Twitter we're using customized IndexingChains and also extend a lot
of abstract classes like e.g. TermsHashConsumer.
Most of these classes are currently package-private, because they were
always considered expert APIs.
I was wondering if we could switch from package-private to
that its properly pluggable, yet passes our
documentation-lint task without unravelling the whole thing and making
some of the crazier impl stuff public, I think it could be a change
for the better overall.
On Fri, Mar 7, 2014 at 2:15 PM, Michael Busch busch...@gmail.com wrote:
Hi All,
At Twitter
let me know what you think about my suggestions. If people
like this approach, then I can add the information to the Wiki
planning page and start working on it.
Best Regards,
Michael Busch
-
To unsubscribe, e-mail: [EMAIL
, if people submit good solutions, those might be
good candidates for contrib.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
Regards,
Michael Busch
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
Doug Cutting wrote:
Marvin Humphrey wrote:
IMO, this should wait. It's going to be freakishly difficult to get
this stuff to work and maintain the commitments that Doug has laid
out for backwards compatibility.
Perhaps we can implement an all-new index format, in a new package.
An
relatively low.
If I find some time I will run performance experiments to get some numbers.
Michael
On Jul 26, 2006, at 5:18 PM, Michael Busch (JIRA) wrote:
[ http://issues.apache.org/jira/browse/LUCENE-624?page=all ]
Michael Busch updated LUCENE-624
I had the same problem with large documents causing memory problems. I
solved this problem by introducing a new setting in IndexWriter
setMaxBufferSize(long). Now a merge is either triggered when
bufferedDocs==maxBufferedDocs *or* the size of the bufferedDocs =
maxBufferSize. I made these
This sounds good. Michael, I'd love to see your patch,
Chuck
Ok, I'll probably need a few days before I can submit it (have to code
unit tests and check if it compiles with the current head), because I'm
quite busy with other stuff right now. But you will get it soon :-)
Chris Hostetter wrote:
: Nice. I think we can't include EMMA jars int he repository, though, so
: you'll want to add the ability to download the Jar on the fly, just like
: Grant did it for the benchmark stuff.
that's not strictly neccessary is it? ... coverage reports could just be
an
Chris Hostetter wrote:
To throw another twist onto things, it would appear that the ASF has a
License for Clover 1.3.2 donated by Cenqua that Committers have access to
(see committers/donated-licenses/clover in SVN) ... it's not clear to me
if that License would allow for auto generated reports
Ning Li wrote:
I was away so I'm catching up.
If this (occasional large documents consume too much memory) happens
to a few applications, should it be solved in IndexWriter?
A possible design could be:
First, in addDocument(), compute the byte size of a ram segment after
the ram segment is
Chris Hostetter wrote:
: Here it is, Grant. This new patch uses Clover to generate code coverage
: reports. Simply add clover.jar to the ant classpath, do a clean and
: run the target test. During compiling Clover will automatically
: instrument all classes under src/java.
haven't had a chance
Thank you Doug and Andreas!!
A year ago I didn't know anything about Lucene and, in general, hadn't
much experience in open source. I have to say that it was a lot of fun
to use Lucene and especially to work with the community. It is
impressive how responsive the developers and committers are
Nicolas Lalevée wrote:
Le Mercredi 20 Décembre 2006 15:31, Grant Ingersoll a écrit :
Hi Michael,
Have a look at https://issues.apache.org/jira/browse/LUCENE-662
I am planning on starting on this soon (I know, I have been saying
that for a while, but I really am.) At any rate, another set
Doug Cutting wrote:
Michael,
This sounds like very good work. The back-compatibility of this
approach is great. But we should also consider this in the broader
context of index-format flexibility.
Three general approaches have been proposed. They are not exclusive.
1. Make the index
Doug Cutting wrote:
A reason not to commit something like this now would be if it
complicates the effort to make the format extensible. Each index
feature we add now will require back-compatibility in the future, and
we should be hesitant to add features that might be difficult to
support
Marvin Humphrey wrote:
On Jan 18, 2007, at 8:31 AM, Michael Busch wrote:
I think it makes sense to add new functions incrementally, as long as
we try to only extend the API in a way, so that it is compatible with
the long-term goal, as Doug suggested already. After the payload
patch
Grant Ingersoll wrote:
Couldn't agree more. This is good progress.
I like the payloads patch, but I would like to see the lazy prox
stream (Lucene 761) stuff done (or at least details given on it) so
that we can hook this into Similarity so that it can be hooked into
scoring. For 761 and
Doug Cutting wrote:
The Lucene PMC has voted to add Michael Busch as a Lucene committer.
Welcome, Michael!
Doug
Thanks everyone for the nice words!
Of course I want to keep the tradition alive, so here follows my
introduction :-)
I am from Germany (more exactly from the Sauerland :-) ). I
Hi,
I just added myself to the Who we are page, regenerated it and
committed the changes. Now I tried to update the website by doing:
ssh people.apache.org
cd /www/lucene.apache.org/java/docs
svn up
It fails with the following message:
svn: Can't open file 'images/.svn/lock': Permission
Chris Hostetter wrote:
: I just added myself to the Who we are page, regenerated it and
: committed the changes. Now I tried to update the website by doing:
: ssh people.apache.org
: cd /www/lucene.apache.org/java/docs
: svn up
just to clarify: is that what you tried because you saw it
: https://issues.apache.org/jira/browse/LUCENE-755
Project: Lucene - Java
Issue Type: New Feature
Components: Index
Reporter: Michael Busch
Assigned To: Michael Busch
Attachments: payload.patch, payloads.patch
This patch adds the possibility
Hi Grant,
I certainly agree that it would be great if we could make some progress
and commit the payloads patch soon. I think it is quite independent from
FI. FI will introduce different posting formats (see Wiki:
http://wiki.apache.org/lucene-java/FlexibleIndexing). Payloads will be
part of
Grant Ingersoll wrote:
Cool. I will try and take a look at it tomorrow. Since we have the
lazy SegTermPos thing in now, we should be able to integrate this into
scoring via the Similarity and merge TermDocs and TermPositions like
you suggested.
If I can get the Scoring piece in and people
Grant Ingersoll wrote:
In regard of FI and 662 however I really believe we should split it
up and plan ahead (in a way I mentioned already), so that we have
more isolated patches. It is really great that we have 662 already
(Nicolas, thank you so much for your hard work, I hope you'll keep
Grant Ingersoll wrote:
I haven't looked at your latest patch yet, so this is just guesswork,
but was thinking in TermScorer, around line 75 or so, we could add:
score *= similarity.scorePayload(payloadBuffer);
TermScorer currently doesn't iterate over the positions. It uses a
buffer to load
Marvin Humphrey wrote:
On Mar 10, 2007, at 3:27 PM, Michael Busch wrote:
I'm going to respond to this over several mails (: and possibly days
:) because there's an awful lot here, and I've already implemented a
lot of it in KS.
We should also make this public, so that users can store
Marvin Humphrey wrote:
On Mar 12, 2007, at 2:11 PM, Michael Busch wrote:
I think our best option here is to have a closed XML file for the
index format/configuration (something like you sent in your other
mail) plus a binary file for custom index-level metadata like Grant
suggested.
Why
Marvin Humphrey wrote:
It uses global field semantics, which Hoss won't be happy about. ;)
However, I'm grateful to Hoss for past critiques, as they've helped me
to refine and improve how Schema works. For instance, as of KS
0.20_02 you can introduce new field_name = FieldSpec
[EMAIL PROTECTED] wrote:
Author: doronc
Date: Thu Mar 15 02:08:07 2007
New Revision: 518529
URL: http://svn.apache.org/viewvc?view=revrev=518529
Log:
maintain most recent file format in a single line in the code.
(this is less bug prone.)
Cool, Doron. I actually had a bug in my local,
Grant Ingersoll wrote:
OK, I need to take a step back, Michael, b/c I thought I understood
your original comment, but I went to make the change and am no longer
sure.
By first term position are you referring to multiple terms per
position or do you mean the same term in different
Karl Wettin (JIRA) wrote:
[ https://issues.apache.org/jira/browse/LUCENE-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491557 ]
Karl Wettin commented on LUCENE-580:
25 apr 2007 kl. 10.23 skrev Michael Busch (JIRA
Hi,
if you run Lucene as a service you want to be able to shut it down in a
certain period of time (usually 1-2 mins). This can be a problem if the
IndexWriter is in the middle of a merge when the service shutdown
request is received.
Therefore it would be nice if we had a method in
Doug Cutting wrote:
If a contrib package is failing tests or breaking the build, then we
should file an issue in Jira. One potential patch is to remove the
package (since incompatible changes are permitted in contrib). That
can be proposed, and if no one with a binding vote objects, it can
Steven Parkes wrote:
I'm not certain, but would parts of your goal be achieved by the work
i've
seen floating arround Jira to refactor th MergePolicy so that it can
be
handled by multiple thrads?
Well, in what I've been working on for LUCENE-847 (merge policy
Chris Hostetter wrote:
: With this committed it also makes sense to deprecate the setUseScorer14()
: method and the corresponding get...() method. If you want a patch for that,
: I'll gladly provide one.
i haven't really been able to follow this issue as much as i would like,
but docs now
this
to 2.3?
- LUCENE-446: search.function - (1) score based on field value, (2) simple
score customizability, Doron Cohen
This looks ready to commit, Doron?
- LUCENE-894: Custom build.xml for binary distributions, Michael Busch
I'm planning to commit this soon.
- LUCENE-854: Create
Grant Ingersoll wrote:
What say people about my suggestion of implementing a code freeze
for 1-2 weeks prior to a release wherein we work on documentation and
cleaning up JIRA? Perhaps we _strive_ to have every committer (and
others are welcome) to try to javadoc a set of files or to clean
And this isn't just for our users. There are a lot of significant
changes being proposed (or already committed) to the merging/indexing
process, and I know I, for one, would benefit from having a good,
coherent, unbroken writeup of it in the javadocs after the issues
have been worked out.
Whatever files also need to be included along with the jars in order to
make the maven distribution complete that can't be built completley
dynamicly (ie: the md5 files) can certainly be commited into the
repository ... but if making a release requires a lot of manual
upating to
those
Doron Cohen wrote:
This is new API, so I was kinda waiting for some feedback on it.
Another passible issue is that it expands FieldCache and
FieldcacheImpl - while LUCENE-831 Complete overhaul of
FieldCache API/Implementation is also changing it.
So I think this can wait for the next release.
Michael Busch wrote:
There are currently 9 issues in Jira targeted for 2.2:
Good progress! Already down to 3 within a day!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Michael McCandless wrote:
Hi,
I have a small API change that I've added in my patch for LUCENE-843.
It just changes two add methods in FieldInfos to return the FieldInfo
instance for the added field, instead of void.
One of the methods is private, so that should be fine. The other one
is
Hi Jukka,
Big +1 from me! We're doing a big 1.4 release of Jackrabbit in a few
months and many of the improvements you listed would be very much
welcome.
Cool!
PS. When doing 2.2, it would be nice if you could upload the release
artifacts also in the Maven repository. See the instructions in
Hi Team,
in our Lucene 2.1 release we had several problems with our release files:
- build.xml in binary release didn't work - demos couldn't be built even
though the demo sources were included in the binaries
- some contrib modules couldn't be built or testcases failed for some
contribs
-
Michael, I updated LUCENE-446, including these
warnings. Is 2.2 still open for adding this?
Hi Doron,
yes it is. I just sent a note to java-dev with a possible schedule for the
2.2 release in which I suggest to have a feature freeze from Wednesday
on. So features can still be committed
Hello everyone,
I'd like to suggest a schedule here for the Lucene 2.2 release:
-- Feature freeze from Wednesday (06/06)
All features must be checked in by end of Tuesday. On Wednesday I will
branch the trunk and we will have a feature freeze on the branch. Then
only Jira issues with Fix
Doron Cohen wrote:
Michael Busch wrote on 04/06/2007 18:59:49:
So please help testing the release files on
different platforms with different JVM versions.
Checked with jdk 1.4 on Win/XP, found no problems:
lucene-2.2-dev.zip:
+ md5: OK
+ LICENSE.TXT: OK
+ NOTICE.TXT: OK
Michael Busch wrote:
I checked on Ubuntu Linux 7.0.4 32 Bit.
With all Sun JDKs 1.4, 5.0 and 6.0:
lucene-2.2-dev.tar.gz:
+ md5: OK
+ LICENSE.TXT: ? (see below)
+ NOTICE.TXT: ? (see below)
+ ant clean war-demo: OK
lucene-2.2-dev-src.tar.gz:
+ md5: OK
+ ant clean test: OK
* the two
Doron Cohen wrote:
Michael, is there a need to hold commits to trunk while
the new branch is created?
No, normal trunk development may continue as usual.
(This is with LUCENE-912 and LUCENE-913 in mind - I think
they can wait for 2.3, there would always be new issues.)
I haven't
Doron Cohen wrote:
If there are no objections I plan to commit it later today.
+1. Thanks for taking care of these, Doron!
I'm working on LUCENE-908 in parallel. After all three are committed
(908, 912, 913)
I will make the branch.
robert engels wrote:
The method states 'greater than OR EQUAL TO' so your d1 != d2 test is
invalid.
It should be assert (d2=d1)
Well, but the javadoc says BEYOND the current.
But I think it should be the desired behavior for skipTo() to not skip
at all
if curDoc==target already? Which
Chris Hostetter wrote:
: But I think it should be the desired behavior for skipTo() to not skip
: at all
: if curDoc==target already? Which means we should clearify the javadocs.
i'm not certain about that ... in theory (given the way the
javadocs are currently written) shouldn't s.skipTo(0)
Doron Cohen wrote:
Since the patches are in place we might want to commit LUCENE-912 and
LUCENE-913 before?
If there are no objections I plan to commit it later today.
912 and 913 are committed. Great job, Doron! Thank you!
Alright, everything seems to be in place. Good timing! I
Hello Team,
well, first of all, let's take a deep breath! Behind us are a couple of
busy weeks. I would like to take this chance to thank everyone very much
for the great work! We're on track for our 2.2 release on the 19th of June.
As announced I created a Lucene 2.2 branch today from trunk
Michael Busch wrote on 04/06/2007 18:59:49:
So please help testing the release files on
different platforms with different JVM versions.
For testing purposes I uploaded a current build from the 2.2 branch to
http://people.apache.org/~buschmi/staging_area/lucene/
- Michael
Michael Busch wrote:
We should make use of this feature freeze and spend the next 10 days for
extensive testing and javadoc improvements. Also help with the maven
patch
(LUCENE-622) is welcome.
To get started with the javadoc improvements I scanned through the index
package
and opened
Grant Ingersoll wrote:
As for the binary distributions, they are pretty much worthless unless
you have some way of knowing what the dependencies are, right?
We could add README.txt files to the contrib directories and package
them together with the jars in the binary distribution?
The
Jukka Zitting wrote:
Tested on:
- Windows XP, Sun Java 1.4.2_12
- Windows XP, Sun Java 1.6.0-b105
- Ubuntu 7.04, Sun Java 1.6.0-b105
Great, thank you, Jukka!
I also ran RAT (http://code.google.com/p/arat/) on the source archive,
and there seem to be some files without license
Hoss Man (JIRA) wrote:
[
https://issues.apache.org/jira/browse/LUCENE-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved LUCENE-930.
-
Resolution: Fixed
Fix Version/s: 2.2
Committed revision 546226. (trunk)
Michael Busch wrote:
- *Only* Jira issues with Fix version 2.2 and priority Blocker will
delay a release candidate build. If on June 17th none of those issue are
in Jira I will build a release candidate and call a release vote on
java-dev.
Hi Team,
it looks good with our schedule
I just finished building the release candidate from the current 2.2
branch (rev. 548010)
Please vote to officially release the release artifacts located at
http://people.apache.org/~buschmi/staging_area/lucene-2.2.0/ as Lucene 2.2.
A minimum of three binding votes (i. e. from Lucene PMC
[EMAIL PROTECTED] wrote:
[junit] Testsuite: org.apache.lucene.gdata.search.index.TestGdataIndexWriter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.394 sec
[junit] - Standard Error -
[junit] Jun 18, 2007 3:23:16 AM
Doron Cohen wrote:
(2) No meta-inf/license in some external jars.
Well I'm not a lawyer either, but since these are 3rd party jars we
can't change that,
right?
(3) Empty lucene-similarity jar in the bin distribution.
The similarity package is still in the trunk for future
Hello,
looking at JIRA and the email archives I find several people asking us
to upload Lucene to the Maven2 repository. Currently there are only the
artifacts from Lucene core 1.9.1 and 2.0.0 in the repository. 1.9.1 is
even incomplete, as LUCENE-867 indicates. Therefore I ported the maven
Grant Ingersoll wrote:
+1 Thanks for taking the lead on this Michael. I hate to ask you to
do more when you already have done so much, but, If you have the time,
can you do a post-mortem to make sure the release checklist is up to
date on the Wiki with all the things you did, esp. the Maven
Paul Smith wrote:
Any chance of adding source jars as artifacts too? Makes the Maven
Eclipse plugin rather nice. I appreciate the effort in organizing the
artifacts (particularly the older versions).
cheers,
Paul
In German we have a saying, something like Offer them your pinky, and
Paul Smith wrote:
quick check, I haven't tried the maven build system for lucene yet,
but getting a clean trunk, and doing this:
mvn -f lucene-parent-pom.xml -Dversion=2.2 install
It appears to be ignoring the version property:
Installing /workspace/lucene-svn/lucene-parent-pom.xml to
Chris Hostetter wrote:
hmm... i thought i suggested before (but it may have just been in my head
and never made it into an email) that the template nature of those files
might confuse people, and we may want to rename them *-pom.xml.template
so people checking out of subversion don't get
Doron Cohen wrote:
Just to clear any doubt about the 2.2 zip files:
from the 'WinZip support' response:
The particular report you sent is almost never reproducible
after a machine restart. Can you reproduce the problem
after restarting your machine?
And indeed after restart the
Release 2.2.0 of Lucene is now available!
Many new features, optimizations, and bug fixes have been added since 2.1,
including point-in-time searching, payloads, function queries and new
APIs for pre-analyzed fields.
The detailed change log is at:
Michael McCandless wrote:
Maybe we should change this to point in time searching over NFS or
custom index deletion policies instead?
Thanks for the feedback, Mike! I agree, point-in-time searching over
NFS describes the new
addition more accurately. I will change the news entry.
-
Daniel Naber wrote:
On Wednesday 20 June 2007 03:01, Yonik Seeley wrote:
The links to the new features don't work for me, I always end up on the API
overview page. Shouldn't the links be e.g.
http://lucene.apache.org/java/2_2_0/api/org/apache/lucene/document/Field.html
instead of
Hi Team,
now that Lucene 2.2 is out (I also announced it today on freshmeat.net
and the Apache announce mailinglist) I would like to say a few words
about the release process.
It was the first time that I did something like release management, so I
was a bit nervous before. But I must say that
karl wettin wrote:
There seem to be problems with this and the new maven-ant-task release.
Karl,
ant generate-maven-artifacts works fine with maven-ant-tasks version
2.0.6. In 2.0.7, which is the current version, the attribute name
location was changed to path. I'm going to update this with
Grant Ingersoll wrote:
2. Release 2.4 so all of Mike M's goodness is available to 1.4 users
within the next 2-4 weeks using our new release mechanism (i.e code
Hi Grant,
2-4 weeks seems quite soon considering that 2.2 is very new and that
there are a lot of open issues targeted for 2.3. For
Chris Hostetter wrote:
is it just me, or does it seem like the base class versions of
getVersion(), isOptimized(), and isCurrent() in IndexReader should all
throw UnsupportedOperationException?
(it seems like ideally they should abstract, but that ship/API has sailed)
Hoss,
I think
Chris Hostetter wrote:
isn't segmentInfos the kind of thing that should be refactored into the
subclasses? there might be a little duplication, but it shouldn't be
significant (and it helps eliminate the odds of other problems like this
in the future as more features/methods get added).
Grant Ingersoll wrote:
Michael,
If we wanted to publish M2 snapshots, we could configure Hudson to call
generate-maven-artifacts and have them deployed to the M2 snapshots
repository, right?
This would mean we would have to change the deploy call a bit in
common-build.xml so that it could
Grant Ingersoll wrote:
Are GData tests passing for people? I notice a lot of exceptions in the
logs and it failed for me.
I'm seeing exceptions too when I run the GData tests. I'm running on Win
XP, SUN JRE 1.5.0.
Two examples:
[junit] INFO: Release new StorageQuery
[junit]
Grant Ingersoll wrote:
Also, can someone else verify clover runs? I feel like I am going in
circles and need a sanity check.
I just tried it, clover instrumentation fails for me when I enable
clover and execute target test-core:
[clover] Sorry, you are not licensed to instrument files in
1 - 100 of 1544 matches
Mail list logo
