[ https://issues.apache.org/jira/browse/LUCENENET-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy resolved LUCENENET-318.
----------------------------
Resolution: Fixed
Patches applied.
DIGY
> TestDisjunctionMaxQuery.TestBooleanOptionalWithTiebreaker failure
> -----------------------------------------------------------------
>
> Key: LUCENENET-318
> URL: https://issues.apache.org/jira/browse/LUCENENET-318
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Priority: Trivial
> Attachments: LUCENENET-318.patch, QueryUtils.patch
>
>
> The failure is due to a floating point arithmetic difference. Altering the value of
the constant SCORE_COMP_THRESH to only 7 significant digits (the accuracy of float in .NET)
allows the test to pass.
> Interestingly, the test passes for me as-is when run in debugging mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy resolved LUCENENET-321.
----------------------------
Resolution: Fixed
Assignee: Digy
Patch applied.
DIGY
> Compression support via reflection
> ----------------------------------
>
> Key: LUCENENET-321
> URL: https://issues.apache.org/jira/browse/LUCENENET-321
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Digy
> Assignee: Digy
> Attachments: LUCENENET-321.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hi Everyone, Few hours ago, as I was debugging an issue, I realized that a new component, org.apache.lucene.messages, was added during one of the RC release of Lucene Java 2.9 and somehow, I missed it. Thus, it's not ported over to Lucene.Net. I just made that port and committed it. The port isn't complete because resource handling is different in .NET vs. Java so this part still needs some work. Anyone wants to give it a try? The new code is under Lucene.Net.Messages. Thanks. -- George
[ https://issues.apache.org/jira/browse/LUCENENET-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786780#action_12786780
]
George Aroush commented on LUCENENET-318:
-----------------------------------------
Looks good. Commit away. Thanks for adding the diversion comment.
> TestDisjunctionMaxQuery.TestBooleanOptionalWithTiebreaker failure
> -----------------------------------------------------------------
>
> Key: LUCENENET-318
> URL: https://issues.apache.org/jira/browse/LUCENENET-318
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Priority: Trivial
> Attachments: LUCENENET-318.patch, QueryUtils.patch
>
>
> The failure is due to a floating point arithmetic difference. Altering the value of
the constant SCORE_COMP_THRESH to only 7 significant digits (the accuracy of float in .NET)
allows the test to pass.
> Interestingly, the test passes for me as-is when run in debugging mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786779#action_12786779
]
George Aroush commented on LUCENENET-322:
-----------------------------------------
I'd rather see a fix / hack done in the test code vs. in the core. In the test code, why
not conditionally compile the code in / out based on debug / release setting? This way, when
the code is compiled with debug, the test will actually execute, and pass. If not, it won't
execute and still pass.
> 3 failing tests of TestIndexWriter
> ----------------------------------
>
> Key: LUCENENET-322
> URL: https://issues.apache.org/jira/browse/LUCENENET-322
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Digy
> Attachments: LUCENENET-322.patch
>
>
> TestExceptionDocumentsWriterInit , TestExceptionOnMergeInit & TestRollbackExceptionHang
fail when "DEBUG constant" is unchecked and pass when checked.
> DIGY
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786776#action_12786776
]
George Aroush commented on LUCENENET-321:
-----------------------------------------
Thanks for doing this DIGY. Commit away!
> Compression support via reflection
> ----------------------------------
>
> Key: LUCENENET-321
> URL: https://issues.apache.org/jira/browse/LUCENENET-321
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Digy
> Attachments: LUCENENET-321.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786181#action_12786181
]
Digy commented on LUCENENET-322:
--------------------------------
What I tried to express with "release build" was "not setting the DEBUG constant". Since this
is the default behaviour.
But what to do? These codes are necessary for testing. A conditional compilation,such as
#if UNIT_TEST?
DIGY
> 3 failing tests of TestIndexWriter
> ----------------------------------
>
> Key: LUCENENET-322
> URL: https://issues.apache.org/jira/browse/LUCENENET-322
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Digy
> Attachments: LUCENENET-322.patch
>
>
> TestExceptionDocumentsWriterInit , TestExceptionOnMergeInit & TestRollbackExceptionHang
fail when "DEBUG constant" is unchecked and pass when checked.
> DIGY
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786094#action_12786094
]
Michael Garski commented on LUCENENET-322:
------------------------------------------
I'm not sure if the tests having issues in a release build is an issue. The failures occur
due to the Debug.Assert call not being compiled into the IL when the DEBUG constant is not
set. Invoking the test methods, even if they have negligible overhead, in a release build
doesn't seem necessary.
Anyone else have thoughts on this one?
Michael
> 3 failing tests of TestIndexWriter
> ----------------------------------
>
> Key: LUCENENET-322
> URL: https://issues.apache.org/jira/browse/LUCENENET-322
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Digy
> Attachments: LUCENENET-322.patch
>
>
> TestExceptionDocumentsWriterInit , TestExceptionOnMergeInit & TestRollbackExceptionHang
fail when "DEBUG constant" is unchecked and pass when checked.
> DIGY
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy updated LUCENENET-322:
---------------------------
Attachment: LUCENENET-322.patch
TestPoint function in System.Diagnostics.Debug.Assert(TestPoint(....)) is not executed when
compiled with "release mode".
DIGY
> 3 failing tests of TestIndexWriter
> ----------------------------------
>
> Key: LUCENENET-322
> URL: https://issues.apache.org/jira/browse/LUCENENET-322
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Digy
> Attachments: LUCENENET-322.patch
>
>
> TestExceptionDocumentsWriterInit , TestExceptionOnMergeInit & TestRollbackExceptionHang
fail when "DEBUG constant" is unchecked and pass when checked.
> DIGY
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy updated LUCENENET-318:
---------------------------
Attachment: QueryUtils.patch
Same problem. TestCustomScoreQuery fails (only in release mode).
Patch coming.
> TestDisjunctionMaxQuery.TestBooleanOptionalWithTiebreaker failure
> -----------------------------------------------------------------
>
> Key: LUCENENET-318
> URL: https://issues.apache.org/jira/browse/LUCENENET-318
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Priority: Trivial
> Attachments: LUCENENET-318.patch, QueryUtils.patch
>
>
> The failure is due to a floating point arithmetic difference. Altering the value of
the constant SCORE_COMP_THRESH to only 7 significant digits (the accuracy of float in .NET)
allows the test to pass.
> Interestingly, the test passes for me as-is when run in debugging mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
3 failing tests of TestIndexWriter
----------------------------------
Key: LUCENENET-322
URL: https://issues.apache.org/jira/browse/LUCENENET-322
Project: Lucene.Net
Issue Type: Bug
Reporter: Digy
TestExceptionDocumentsWriterInit , TestExceptionOnMergeInit & TestRollbackExceptionHang
fail when "DEBUG constant" is unchecked and pass when checked.
DIGY
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy updated LUCENENET-321:
---------------------------
Attachment: LUCENENET-321.patch
> Compression support via reflection
> ----------------------------------
>
> Key: LUCENENET-321
> URL: https://issues.apache.org/jira/browse/LUCENENET-321
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Digy
> Attachments: LUCENENET-321.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Compression support via reflection
----------------------------------
Key: LUCENENET-321
URL: https://issues.apache.org/jira/browse/LUCENENET-321
Project: Lucene.Net
Issue Type: Improvement
Reporter: Digy
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
So I've been thinking about this for a few days before throwing my 2
cents in.
Regarding the contrib section, I'm not sure how it is managed on the
Java side, but I see it as a repository where any user can contribute
items that they have developed (or ported from Java). Keeping the
contrib section up to date with the latest release version would fall on
whoever had submitted the contrib code or if that person is no longer
active with Lucene anyone who wants to. I have a few things that I'll
be contributing for it, some of which are ported from Java, some of
which are unique to Lucene.Net.
On the topic of altering Lucene.Net to take advantage of the .Net
Framework and employing best practices I have mixed feelings.
Modifications to internal implementations are fine with me, however I
would draw the line at modifying the between the classes as we just
don't have the critical mass of contributors to take the port to a
functionality based port from a class & method based port. A good
example of this is in the interfaces for TermEnum, TermDocs, and
TermPositions - they are a bit cumbersome to use compared to the best
practice of enumerating over .Net collections, however it radically
alters Lucene.Net and makes porting future Java Lucene functionality
challenging. Providing wrappers around TermDocs, etc is a good
candidate for the contrib section. Nick's point on
ParallelMutliSearcher is a good one - it's a dog. However from my
testing in a high load environment you're better off using MultiSearcher
and searching multiple indexes serially and handling multiple requests
concurrently which minimizes thread contention and resource starvation.
We (at MySpace) have never run a 'stock' version of Lucene.Net but a
customized build that tweaks a few things under the hood. I have not
yet made these changes to the 2.9 version, and will do so once it is
tagged and contribute a patch that anyone can then use and apply. I
would not see such changes being applied to the trunk as they either
modify behavior in ways that would make future porting more challenging.
I don't think there is a timeline on when we target the ability to keep
up with Java Lucene commits. I'm hoping we can give it a whirl with 3.0
which was recently released, but how to approach that is a whole other
topic.
Michael
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Sunday, November 29, 2009 11:00 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: port of contrib packages from java
Rob,
I appreciate the input, but I feel that I might have been
misunderstood.
When I said a custom port, I meant for private consumption, not
for
public consumption.
To answer your question, there are a number of benefits that
will
benefit from a .NET overhaul which have been outlined before. Some
specific
ones are the multi thread searchers (using Threads with calls to Join
for
synchronization is a bit of a dog, the ThreadPool can help there),
replacement of ArrayList with List<T> (especially where the type
parameter
is a structure, there are performance issues due to boxing when using
ArrayList instances).
Those are the two off the top of my head which would fall within
the
purview of the Lucene.NET project, but no one seems to be doing. The
replacement of ArrayList with List<T> isn't even a call site change in
99%
of the instances, just a declaration change. This is probably the
lowest-hanging fruit of all, and no one is doing it (Hashtables come to
mind
as well, but those would require call site changes, but could easily be
handled with an extension method on IDictionary<TKey, TValue>).
Why? To be honest, none of the answers are really satisfactory.
The current commits that are being made are only being made if they help
drive towards passing the test cases. I'm not saying that's not a goal
to
try and direct people towards, but being open source, you have to take
what
you can get when it comes to the work that people contribute (I'm not
saying
you have to ^accept it^ mind you).
With that, not everyone wants to see a line-for-line port of
Lucene
from Java to .NET. People would like to address pain points that come
with
an implementation that isn't very .NET friendly, as well as an API that
is
unfriendly. I know the latter point is not up for discussion, but you
indicate your desire for having the project fulfill your particular
vision.
I respect that vision, but I have one as well. I don't think it's
unfair to
say that there are others that share it as well.
While I agree that catching up to Java is an achievable goal,
there
is no timeline for that goal (nor do you give one, mind you), and my
impression is that it's not one that will be accomplished anytime soon.
George implies (and if I am misrepresenting you George, I apologize,
this is
how I read your response) that is the case given the current level of
contribution.
All this being said, I see the discussion as moot, given my
first
statement about not making it available for public consumption. I
simply
want access to the process for my own individual consumption. Given the
open source nature of the project, I don't see why it should be
unavailable.
I should also note that I am not looking to stop contributing to
the
project, but given the current direction that it is going, I have needs
and
desires for it I would like to address, and feel comfortable doing work
that
I know will not be shared with others, but which will fully attribute
the
original source of the work.
That being said, are those tools and information on the process
available?
- Nicholas Paldino [.NET/C# MVP]
-----Original Message-----
From: Ron Grabowski [mailto:rongrabowski@yahoo.com]
Sent: Monday, November 30, 2009 12:53 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: port of contrib packages from java
I agree with George. Catching up to Java (within in a week or so of
their
SVN commits) seems like an achievable goal. The work being done on 2.9
is
only about a month off the Java release.
I'm concerned that having more of a .NET internal API would cause the
project to slow down adopting new features. Take the PHP Lucene port for
example...its sort of a port of Lucene but I couldn't find anything on
the
site detailing what version they branched from. I doubt they've
incorporated
the new features of 2.4, 2.9, etc. into their port or even have plans to
be
3.0 compliant.
I'd rather have a .NET port that is 10% slower but can more easily adapt
new
features from the parent project than a super-sweet .NET API that people
have to bend over backwards to re-re-implement parent project features.
Do we need to make the internal API more .NET-ish if people aren't going
to
use it much? Do you have specific areas that might benefit from a .NET
overhaul?
----- Original Message ----
From: Nicholas Paldino [.NET/C# MVP] <casperOne@caspershouse.com>
To: lucene-net-dev@incubator.apache.org
Sent: Sun, November 29, 2009 9:53:53 PM
Subject: RE: port of contrib packages from java
George,
If that is the case, then where can I get a hold of the
tools/process
that is
used to port over the java version to .NET?
Being completely honest, I'd much rather just grab 3.0 from Java, do
a
port,
and then have a custom version which is more to my liking implementation
and
API-wise. (still honoring the Apache license of course).
While I very much like what Lucene does (and I am speaking in a
general
sense, not the .NET specific version), the .NET version suffers from
this
lack
of resources, which unfortunately will keep it in this perpetual state.
- Nick
-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Sunday, November 29, 2009 12:40 AM
To: lucene-net-dev@incubator.apache.org
Subject: RE: port of contrib packages from java
I'm not discouraging the use of .NET 3.5, or making Lucene.Net to be
fully
.NET compliant. I'm simply trying to set expectation as this is not the
first time this subject came up.
As you can see, it has been over 1 month since I committed the initial
port
of 2.9 and even with a good community help (never had this much help in
any
previous releases, it was just 2 or 3 of us) we still have about 14
NUnit
tests failing! If the port was not line-per-line port, not only will we
have to deal with NUnit tests, but we might very well have to deal with
index format, compatibility, corruption, and threading issues to name
some;
the community will have to be well versed with Lucene's internals to
address
such issues. Are we ready for this? IMHO, no, we are not. I believe
we
need to first prove that we can maintain a port at a commit-per-commit
level
(or no more than a week behind Lucene Java), before we commit to be
fully
.NET compliant and take full advantage of it.
-- George
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Wednesday, November 25, 2009 10:09 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: port of contrib packages from java
George,
This brings up the question of whether or not work will be done to
Lucene.NET to adhere to best practices in .NET development. I'm not
even
suggesting the public-facing API, but doing internal work.
While I respect the desire to be able to be on a commit-by-commit
basis with the Java project, there has been discussion in the past about
moving to .NET 3.5 when Lucene 3.0 comes out (they are upgrading to a
new
version of the JVM at that point, from what I understand).
Even if the decision to move to .NET 3.5 is made, I can't see the
benefit if all that is desired for the Lucene.NET port is to be a mirror
for
the Java version because there aren't enough people that can maintain
the
project on a commit-per-commit basis.
And while I don't have the metrics of those that have contributed,
it doesn't seem like the project has the critical mass necessary to do
this,
which makes for a catch-22 situation.
Basically, there aren't enough people to keep the project current on
a commit-by-commit basis with the Java project, and that's one of the
big
reasons that I think people aren't contributing, because they are
limited
severely to this tenant to have literally line-by-line parity between
the
two code bases.
It's also a tenant which serves the limitations of the resources
that the project has available to it, as opposed to the betterment of
the
project itself.
I'm not looking to bash the project or the people who have
contributed (and I still want to contribute), but I don't see the point
where the goal of matching the Java version consistently will happen, so
it
makes me ask if there shouldn't be a discussion about shifting the
priorities of the project to address some of the pain points for the
audience that is using the product now (some examples being a sloppy API
from a .NET perspective, inefficient internal implementations and other
such
"goodies").
Perhaps this is something that should be put to a vote as well (not
that I know who's vote would matter or count, but it's something you
suggested for the ports of the contrib projects)?
- Nick-----Original Message-----
From: George Aroush [mailto:george@aroush.net]
Sent: Monday, November 23, 2009 11:21 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: port of contrib packages from java
Porting all of the code in contrib is going to be a challenge; there is
a
lot of code in there. So it makes sense to first port packages that
gives
us the most value (maybe via a vote). Also, what's ported now may no
longer
work with 2.9.1's Lucene.Net port; this is because contrib.Net port has
not
been kept up to date. And yes, virtually every project in contrib has a
JUnit test associated with it, thus it can be used for validation of a
project port.
Regarding the .NET'es of ports, this has come up few times in the past,
and
it's tempting to want to make Lucene.Net more .NET'es. However. this is
very hard to achieve without solid commitment and being at a
commit-per-commit port with Lucene Java (i.e.: anytime a commit in
Lucene
Java happens, it must, within days, be ported over to Lucene.Net and
committed).
Many of the projects in contrib, the task to port them is much simpler
than
it is for the core Lucene code. However, here is where things get
challenging. Any time you think about making a port more .NET'es, you
must
keep the following in mind:
1) It will be more work and harder to keep the code in sync with the
Java
version (per the above reasons), and
2) The code in contrib may no longer work with the code in Lucene core
due
to the .NET'es of the port (mainly public APIs). Thus, your effort at
.NET'es of contrib port may be limited if Lucene core code isn't.
What's the take away? Until when we can maintain commit-per-commit port
with Lucene Java, trying to make Lucene.Net and / or contrib more
.NET'es
isn't realistic.
-- George
-----Original Message-----
From: Eran Sevi [mailto:eransevi@gmail.com]
Sent: Monday, November 23, 2009 3:12 PM
To: lucene-net-dev@incubator.apache.org
Subject: Re: port of contrib packages from java
Although some contrib packages might not be in use by any lucene .net
user
at the moment, I think we should port them all in accordance with the
java
version (it shouldn't be as hard as the core classes although I'm not
sure
there are any tests for them).
When and if we'll diverge from the core java implementation in order to
take
benefit of .net and apply each patch as it comes, we can do the same for
contrib which also sees much less traffic anyway.
Eran
On Mon, Nov 23, 2009 at 8:27 PM, Digy <digydigy@gmail.com> wrote:
> I don't know whether there is such a preference for contribs or not,
but
> diverging from Java makes life harder for further ports.
> Will someone be able to easily port the next release after your state
of
> art work following .NET best practices?
> Or a new port from scratch?
>
> DIGY
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP]
[mailto:casperOne@caspershouse.com]
> Sent: Monday, November 23, 2009 7:11 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: RE: port of contrib packages from java
>
> On a somewhat related note, these ports, do they adhere to the
> tenants applied to the main trunk, or can they better follow .NET best
> practices if one wants to apply them?
>
> - Nick
>
> -----Original Message-----
> From: Eran Sevi [mailto:eransevi@gmail.com]
> Sent: Monday, November 23, 2009 8:45 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: port of contrib packages from java
>
> Thanks,
> I'm more into the "queries" package.
> If no one will beat me to it, I hope I can help and add it myself.
>
> How did you do the port? manually or using some conversion tools?
>
> Eran.
>
> On Mon, Nov 23, 2009 at 3:34 PM, Roger Chapman <roger@stormid.com>
wrote:
>
> > I've done a first pass port of the Spatial Contrib project :
> > https://issues.apache.org/jira/browse/LUCENENET-199
> >
> > Roger.
> >
> > -----Original Message-----
> > From: Eran Sevi [mailto:eransevi@gmail.com]
> > Sent: 23 November 2009 13:17
> > To: lucene-net-dev@incubator.apache.org
> > Subject: port of contrib packages from java
> >
> > Hi,
> > Is there any thought to port all the contrib packages from java
lucene
> > after
> > the porting of core 2.9.1 version is complete?
> > Currently there are 23 packages in java contrib compared to only 7
> packages
> > in .net contrib.
> >
> > Thanks,
> > Eran.
> >
>
>
Hey, I have set up a continuous integration server for Lucene.Net. The url is http://teamcity.codebetter.com/project.html?projectId=project56. The server builds the trunk release configuration of the Lucene.Net project, the demo projects, and the test project. It also runs all the tests. At the time of writing, there are 41 failing tests, many of which is due to the lack of compression support. Is that a bug in the code, or is compression support required for those tests to pass? The way the build server works is that the source code is downloaded from trunk and built automatically as is. To enable compression support, SHARP_ZIP_LIB has to be defined and the SharpLibZip assembly has to be referenced. The define can be added as a parameter to the msbuild process. However, I'm not quite sure how to configure the server to add the assembly reference to the project file without any manual steps. Now that the continuous integration server is set up, every time a commit is made, it automatically downloads the changes, builds the projects, and runs the tests. That way it is easy to see if the changes breaks the build in any way, either by causing the compilation or one or more tests to fail. It's possible to configure the server to automatically send a notification by email, instant messaging, withing Visual Studio, or to a tray application if a build breaks. This functionality is available for registered users in the "My Settings & Tools" section. I hope this will come in handy for some of you. I figured that with the current status of trunk, with quite a few failing tests, it is nice to have a place to get the current status without having to build the project and run all the tests yourself. Also, it's a nice way to check whether the code actually compiles after a commit. For example, if one or more files were left out from the commit, it can compile just fine locally, but once someone else downloads the changes, it fails. This was actually the case a few days ago when the updated project file was not committed along with the deleted files. So, what do you guys think? - Rune
[ https://issues.apache.org/jira/browse/LUCENENET-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy resolved LUCENENET-308.
----------------------------
Resolution: Fixed
patch committed.
DIGY
> TestIndexWriter.TestThreadInterruptDeadlock
> -------------------------------------------
>
> Key: LUCENENET-308
> URL: https://issues.apache.org/jira/browse/LUCENENET-308
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Andrei Iliev
> Attachments: TestIndexWriter.patch
>
>
> 2 problems with the test:
> 1) There is no .Net equivalent for java's java.lang.Thread.interrupted() and interrupted
bit => we can not check if IW restored interrupted bit (there is no such bit).
> 2) Sometimes test fails with exception:
> An unhandled System.NullReferenceException was thrown while executing this test : Object
reference not set to an instance of an object.
> In seems that in java statement "synchronized(this) "
> will never throw an InterruptedException but in .Net statement lock(this) can throw
such exception. Because of this the inner exception sometimes will be null => cause System.NullReferenceException
exception.
> Here's a snippet of code from the ConcurrentMergeScheduler
> =============
> lock (this) // (1)
> {
> MergeThread merger;
> while (MergeThreadCount() >= maxThreadCount)
> {
> if (Verbose())
> Message(" too many merge threads running; stalling...");
> try
> {
> System.Threading.Monitor.Wait(this); // (2)
> }
> catch (System.Threading.ThreadInterruptedException ie)
> {
> // In 3.0 we will change this to throw
> // InterruptedException instead
> SupportClass.ThreadClass.Current().Interrupt();
> throw new System.SystemException(ie.Message, ie);
> }
> }
> =============
> In java ThreadInterruptedException can be thrown only in position (2). But in .Net
it can be at postion (1) as well.
> I choose the easiest fix: check not only inner exception but the exception as well
> if(re is System.Threading.ThreadInterruptedException || e is System.Threading.ThreadInterruptedException)
> As alternative we have to fix many places in ConcurrentMergeScheduler by
> -finding lock(this),
> -add try , and catch blocks in the following way:
> catch (System.Threading.ThreadInterruptedException ie)
> {
> // In 3.0 we will change this to throw
> // InterruptedException instead
> SupportClass.ThreadClass.Current().Interrupt();
> throw new System.SystemException(ie.Message, ie);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785427#action_12785427
]
Nicholas Paldino commented on LUCENENET-320:
--------------------------------------------
I would recommend using JTidy or TidyNet to create parsable XML (to fix the tags) and then
go from there. You should be able to create a custom lexer which will handle the "///" lines.
> Clean up XML documentation comments
> -----------------------------------
>
> Key: LUCENENET-320
> URL: https://issues.apache.org/jira/browse/LUCENENET-320
> Project: Lucene.Net
> Issue Type: Task
> Reporter: George Aroush
> Assignee: George Aroush
> Priority: Minor
>
> Many of the XML documentation are not well formatted during the conversion from Lucene
Java to Lucene.Net using JLCA. This task is to see if we can write a script to clean up what
JLCA couldn't do.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy resolved LUCENENET-317.
----------------------------
Resolution: Fixed
Patch committed.
DIGY
> The release configuration in the Lucene.Net project file is not configured correctly
> ------------------------------------------------------------------------------------
>
> Key: LUCENENET-317
> URL: https://issues.apache.org/jira/browse/LUCENENET-317
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Rune Vistnes
> Attachments: LUCENENET-317.patch
>
>
> The release configuration in the Lucene.Net project file is configured as a debug build.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy resolved LUCENENET-314.
----------------------------
Resolution: Fixed
> Excluded files from project
> ---------------------------
>
> Key: LUCENENET-314
> URL: https://issues.apache.org/jira/browse/LUCENENET-314
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Digy
> Priority: Minor
> Attachments: LUCENENET-314.patch
>
>
> Creating this issue on behalf of Eran Sevi
> DIGY
> {quote}
> Hi,
> There are many files that are maintained in the svn but are not included in the Lucene.Net
csproj.
> Probably these files are leftovers from previous releases since the project compiles
and runs without a problem. If not, they should be included in the project.
> I think we should include a patch that removes all these files.
> Here's the list of the files I found that are not used:
> Index\DirectoryIndexReader.cs
> Index\MultiSegmentReader.cs
> Index\ReadOnlyMultiSegmentReader.cs
> Index\StoredFieldsWriterPerField.cs
> Index\StoredFieldWriterPerThread.cs
> Search\ExtendedFieldCacheImpl.cs
> Search\NonMatchingScorer.cs
> Search\RemoteCachingWrapperFilter.cs
> Search\RemoteSearchable.cs
> Search\Spans\NearSpans.cs
> Search\Spans\PayloadSpans.cs
> Thanks,
> Eran.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy resolved LUCENENET-316.
----------------------------
Resolution: Fixed
Thanks Michael,
done.
DIGY
> Unncesary TestFixture Attribute on LocalizedTestCase
> ----------------------------------------------------
>
> Key: LUCENENET-316
> URL: https://issues.apache.org/jira/browse/LUCENENET-316
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Priority: Trivial
> Attachments: LUCENENET-316.patch
>
>
> There is an unnecessary TestFixture attribute on the LocalizedTestCase class. While
it does not cause any problems, it appears as a failing test in the NUnit GUI. Patch coming
in a moment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy resolved LUCENENET-202.
----------------------------
Resolution: Fixed
I committed LUCENENET-202.patch (no change in project files).
DIGY
> Compile warnings trying to build source code, svn revision 829945
> -----------------------------------------------------------------
>
> Key: LUCENENET-202
> URL: https://issues.apache.org/jira/browse/LUCENENET-202
> Project: Lucene.Net
> Issue Type: Bug
> Environment: VS C# Express 2008. A
> Reporter: Corey Trager
> Attachments: csproj.patch, LUCENENET-202.patch
>
>
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,12): warning CS0472:
The result of the expression is always 'true' since a value of type 'bool' is never equal
to 'null' of type 'bool?'
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,24): warning CS0429:
Unreachable expression code detected
> C:\cit\lucene\C#\src\Lucene.Net\Index\FormatPostingsDocsWriter.cs(42,17): warning CS0649:
Field 'Lucene.Net.Index.FormatPostingsDocsWriter.freqStart' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(230,15): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.yycolumn' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(233,16): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.zzAtBOL' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocFieldProcessorPerThread.cs(42,18): warning CS0649:
Field 'Lucene.Net.Index.DocFieldProcessorPerThread.docBoost' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Index\CharBlockPool.cs(31,16): warning CS0649: Field
'Lucene.Net.Index.CharBlockPool.numBuffer' is never assigned to, and will always have its
default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(87,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.byteBuf' is never assigned to, and will always
have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(90,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.otherByteBuf' is never assigned to, and will
always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\CharReader.cs(32,35): warning CS0649: Field
'Lucene.Net.Analysis.CharReader.input' is never assigned to, and will always have its default
value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocumentsWriter.cs(181,37): warning CS0649: Field
'Lucene.Net.Index.DocumentsWriter.newFiles' is never assigned to, and will always have its
default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermVectorsTermsWriter.cs(35,30): warning CS0649:
Field 'Lucene.Net.Index.TermVectorsTermsWriter.termVectorsWriter' is never assigned to, and
will always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermsHash.cs(43,21): warning CS0169: The field
'Lucene.Net.Index.TermsHash.primaryTermsHash' is never used
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785376#action_12785376
]
Digy commented on LUCENENET-315:
--------------------------------
Btw, nice code. Thanks Michael
DIGY
> SimpleLRUCache Implementation
> -----------------------------
>
> Key: LUCENENET-315
> URL: https://issues.apache.org/jira/browse/LUCENENET-315
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Michael Garski
> Attachments: LUCENENET-315.patch
>
>
> The current SimpleLRUCache implementation is a performance hit in the case of 100% cache
misses, which is a common occurrence if search results are cached externally and only unique
queries are executed.
> Patch and performance metrics coming shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy resolved LUCENENET-315.
----------------------------
Resolution: Fixed
Nothing, I just hadn't time to test it deeply.
Patch committed.
DIGY
> SimpleLRUCache Implementation
> -----------------------------
>
> Key: LUCENENET-315
> URL: https://issues.apache.org/jira/browse/LUCENENET-315
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Michael Garski
> Attachments: LUCENENET-315.patch
>
>
> The current SimpleLRUCache implementation is a performance hit in the case of 100% cache
misses, which is a common occurrence if search results are cached externally and only unique
queries are executed.
> Patch and performance metrics coming shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785319#action_12785319
]
George Aroush commented on LUCENENET-202:
-----------------------------------------
Go ahead and commit this patch, DIGY. I created LUCENENET-320 to keep track of cleaning up
the XML documentation comments
> Compile warnings trying to build source code, svn revision 829945
> -----------------------------------------------------------------
>
> Key: LUCENENET-202
> URL: https://issues.apache.org/jira/browse/LUCENENET-202
> Project: Lucene.Net
> Issue Type: Bug
> Environment: VS C# Express 2008. A
> Reporter: Corey Trager
> Attachments: csproj.patch, LUCENENET-202.patch
>
>
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,12): warning CS0472:
The result of the expression is always 'true' since a value of type 'bool' is never equal
to 'null' of type 'bool?'
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,24): warning CS0429:
Unreachable expression code detected
> C:\cit\lucene\C#\src\Lucene.Net\Index\FormatPostingsDocsWriter.cs(42,17): warning CS0649:
Field 'Lucene.Net.Index.FormatPostingsDocsWriter.freqStart' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(230,15): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.yycolumn' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(233,16): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.zzAtBOL' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocFieldProcessorPerThread.cs(42,18): warning CS0649:
Field 'Lucene.Net.Index.DocFieldProcessorPerThread.docBoost' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Index\CharBlockPool.cs(31,16): warning CS0649: Field
'Lucene.Net.Index.CharBlockPool.numBuffer' is never assigned to, and will always have its
default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(87,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.byteBuf' is never assigned to, and will always
have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(90,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.otherByteBuf' is never assigned to, and will
always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\CharReader.cs(32,35): warning CS0649: Field
'Lucene.Net.Analysis.CharReader.input' is never assigned to, and will always have its default
value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocumentsWriter.cs(181,37): warning CS0649: Field
'Lucene.Net.Index.DocumentsWriter.newFiles' is never assigned to, and will always have its
default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermVectorsTermsWriter.cs(35,30): warning CS0649:
Field 'Lucene.Net.Index.TermVectorsTermsWriter.termVectorsWriter' is never assigned to, and
will always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermsHash.cs(43,21): warning CS0169: The field
'Lucene.Net.Index.TermsHash.primaryTermsHash' is never used
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Clean up XML documentation comments
-----------------------------------
Key: LUCENENET-320
URL: https://issues.apache.org/jira/browse/LUCENENET-320
Project: Lucene.Net
Issue Type: Task
Reporter: George Aroush
Assignee: George Aroush
Priority: Minor
Many of the XML documentation are not well formatted during the conversion from Lucene Java
to Lucene.Net using JLCA. This task is to see if we can write a script to clean up what JLCA
couldn't do.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785316#action_12785316
]
George Aroush commented on LUCENENET-315:
-----------------------------------------
What's holding this back from being committed? DIGY, are you OK with this patch? I'm, I
can commit it.
> SimpleLRUCache Implementation
> -----------------------------
>
> Key: LUCENENET-315
> URL: https://issues.apache.org/jira/browse/LUCENENET-315
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Michael Garski
> Attachments: LUCENENET-315.patch
>
>
> The current SimpleLRUCache implementation is a performance hit in the case of 100% cache
misses, which is a common occurrence if search results are cached externally and only unique
queries are executed.
> Patch and performance metrics coming shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785315#action_12785315
]
George Aroush commented on LUCENENET-202:
-----------------------------------------
If we can automate the XML documentation comments clean up, let's do that, otherwise I would
like to wait on till when we start working on 3.0 to keep the delta low when doing the migration
from 2.9.1 -> 3.0.
I will look into the XML doc clean up in a separate JIRA issue.
> Compile warnings trying to build source code, svn revision 829945
> -----------------------------------------------------------------
>
> Key: LUCENENET-202
> URL: https://issues.apache.org/jira/browse/LUCENENET-202
> Project: Lucene.Net
> Issue Type: Bug
> Environment: VS C# Express 2008. A
> Reporter: Corey Trager
> Attachments: csproj.patch, LUCENENET-202.patch
>
>
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,12): warning CS0472:
The result of the expression is always 'true' since a value of type 'bool' is never equal
to 'null' of type 'bool?'
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,24): warning CS0429:
Unreachable expression code detected
> C:\cit\lucene\C#\src\Lucene.Net\Index\FormatPostingsDocsWriter.cs(42,17): warning CS0649:
Field 'Lucene.Net.Index.FormatPostingsDocsWriter.freqStart' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(230,15): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.yycolumn' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(233,16): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.zzAtBOL' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocFieldProcessorPerThread.cs(42,18): warning CS0649:
Field 'Lucene.Net.Index.DocFieldProcessorPerThread.docBoost' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Index\CharBlockPool.cs(31,16): warning CS0649: Field
'Lucene.Net.Index.CharBlockPool.numBuffer' is never assigned to, and will always have its
default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(87,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.byteBuf' is never assigned to, and will always
have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(90,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.otherByteBuf' is never assigned to, and will
always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\CharReader.cs(32,35): warning CS0649: Field
'Lucene.Net.Analysis.CharReader.input' is never assigned to, and will always have its default
value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocumentsWriter.cs(181,37): warning CS0649: Field
'Lucene.Net.Index.DocumentsWriter.newFiles' is never assigned to, and will always have its
default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermVectorsTermsWriter.cs(35,30): warning CS0649:
Field 'Lucene.Net.Index.TermVectorsTermsWriter.termVectorsWriter' is never assigned to, and
will always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermsHash.cs(43,21): warning CS0169: The field
'Lucene.Net.Index.TermsHash.primaryTermsHash' is never used
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785313#action_12785313
]
George Aroush commented on LUCENENET-313:
-----------------------------------------
True, but what about users who have an index created prior to 2.9 and want to migrate to 2.9?
> SharpZipLib dependency
> ----------------------
>
> Key: LUCENENET-313
> URL: https://issues.apache.org/jira/browse/LUCENENET-313
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Digy
> Attachments: SharpZipLib Dependency.patch
>
>
> With the patch, SharpZipLib is not a "must".
> (but no compression support)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785309#action_12785309
]
George Aroush commented on LUCENENET-319:
-----------------------------------------
See https://issues.apache.org/jira/browse/INFRA-2361 for the mailing list moves
> Graduate Apache Lucene.Net as sub-project under Apache Lucene
> -------------------------------------------------------------
>
> Key: LUCENENET-319
> URL: https://issues.apache.org/jira/browse/LUCENENET-319
> Project: Lucene.Net
> Issue Type: Task
> Reporter: George Aroush
> Assignee: George Aroush
>
> The votes to graduate Apache Lucene.Net from the Incubator to Apache Lucene have passed.
> Here's a list of things we need to do to implement the graduation:
> * Migrate the mailing lists
> * Update the issue tracker (Lucene.Net is in group Lucene, not Incubator)
> * Migrate the web site to lucene.apache.org/lucene.net
> * Remove incubation disclaimers
> * Move the codebase from incubator/tika to lucene/lucene.net
> * Update the svn authorization and commit notification settings
> * Update the incubation records to reflect graduation
> The purpose of this issue is to track progress on these tasks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Graduate Apache Lucene.Net as sub-project under Apache Lucene
-------------------------------------------------------------
Key: LUCENENET-319
URL: https://issues.apache.org/jira/browse/LUCENENET-319
Project: Lucene.Net
Issue Type: Task
Reporter: George Aroush
Assignee: George Aroush
The votes to graduate Apache Lucene.Net from the Incubator to Apache Lucene have passed.
Here's a list of things we need to do to implement the graduation:
* Migrate the mailing lists
* Update the issue tracker (Lucene.Net is in group Lucene, not Incubator)
* Migrate the web site to lucene.apache.org/lucene.net
* Remove incubation disclaimers
* Move the codebase from incubator/tika to lucene/lucene.net
* Update the svn authorization and commit notification settings
* Update the incubation records to reflect graduation
The purpose of this issue is to track progress on these tasks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785203#action_12785203
]
Digy commented on LUCENENET-318:
--------------------------------
It doesn't fail in my test env. but a patch can be safer. It think, this is the difference
between the debug & release modes.
See the issue:
http://issues.apache.org/jira/browse/LUCENENET-95
DIGY
> TestDisjunctionMaxQuery.TestBooleanOptionalWithTiebreaker failure
> -----------------------------------------------------------------
>
> Key: LUCENENET-318
> URL: https://issues.apache.org/jira/browse/LUCENENET-318
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Priority: Trivial
> Attachments: LUCENENET-318.patch
>
>
> The failure is due to a floating point arithmetic difference. Altering the value of
the constant SCORE_COMP_THRESH to only 7 significant digits (the accuracy of float in .NET)
allows the test to pass.
> Interestingly, the test passes for me as-is when run in debugging mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
I've created an issue in Jira and attached a patch. https://issues.apache.org/jira/browse/LUCENENET-317 On Sun, Nov 29, 2009 at 1:31 PM, runenur <runenur@gmail.com> wrote: > Hey, > > I noticed that the only thing you changed in your fix was the output > directory. There are a few other things that has to be fixed as well. I > compared the differences between a debug and release configuration on a > project I just created, compared them with the release configuration in the > Lucene.Net project, and I came up with these differences: > > On line 60: > <DefineConstants>TRACE;DEBUG</DefineConstants> should be > <DefineConstants>TRACE</DefineConstants> > > On line 62: > <DebugSymbols>true</DebugSymbols> should be removed. > > On line 67: > <Optimize>false</Optimize> should be <Optimize>true</Optimize> > > On line 72: > <DebugType>full</DebugType> should be <DebugType>pdbonly</DebugType> > > - Rune > > On Sun, Nov 29, 2009 at 6:59 AM, George Aroush <george@aroush.net> wrote: > >> Strange! I remember fixing this a while back; I just committed a fix. >> However, I don't see "Allow unsafe code" set (per your previous email). >> >> -- George >> >> -----Original Message----- >> From: runenur [mailto:runenur@gmail.com] >> Sent: Thursday, November 26, 2009 6:57 PM >> To: lucene-net-dev@incubator.apache.org >> Subject: Re: The solution file is not configured correctly >> >> I'm sorry, I meant the project file. Also, the output directory is >> incorrect. It is currently set to bin/Debug both in the debug and the >> release configuration. >> >> - Rune >> >> >
[ https://issues.apache.org/jira/browse/LUCENENET-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rune Vistnes updated LUCENENET-317:
-----------------------------------
Attachment: LUCENENET-317.patch
This patch removes the debug parts of the release configuration.
> The release configuration in the Lucene.Net project file is not configured correctly
> ------------------------------------------------------------------------------------
>
> Key: LUCENENET-317
> URL: https://issues.apache.org/jira/browse/LUCENENET-317
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Rune Vistnes
> Attachments: LUCENENET-317.patch
>
>
> The release configuration in the Lucene.Net project file is configured as a debug build.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Garski updated LUCENENET-318:
-------------------------------------
Attachment: LUCENENET-318.patch
Patch to alter the float tolerance.
> TestDisjunctionMaxQuery.TestBooleanOptionalWithTiebreaker failure
> -----------------------------------------------------------------
>
> Key: LUCENENET-318
> URL: https://issues.apache.org/jira/browse/LUCENENET-318
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Priority: Trivial
> Attachments: LUCENENET-318.patch
>
>
> The failure is due to a floating point arithmetic difference. Altering the value of
the constant SCORE_COMP_THRESH to only 7 significant digits (the accuracy of float in .NET)
allows the test to pass.
> Interestingly, the test passes for me as-is when run in debugging mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
TestDisjunctionMaxQuery.TestBooleanOptionalWithTiebreaker failure
-----------------------------------------------------------------
Key: LUCENENET-318
URL: https://issues.apache.org/jira/browse/LUCENENET-318
Project: Lucene.Net
Issue Type: Bug
Reporter: Michael Garski
Priority: Trivial
The failure is due to a floating point arithmetic difference. Altering the value of the constant
SCORE_COMP_THRESH to only 7 significant digits (the accuracy of float in .NET) allows the
test to pass.
Interestingly, the test passes for me as-is when run in debugging mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
The release configuration in the Lucene.Net project file is not configured correctly
------------------------------------------------------------------------------------
Key: LUCENENET-317
URL: https://issues.apache.org/jira/browse/LUCENENET-317
Project: Lucene.Net
Issue Type: Bug
Reporter: Rune Vistnes
The release configuration in the Lucene.Net project file is configured as a debug build.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Garski updated LUCENENET-316:
-------------------------------------
Attachment: LUCENENET-316.patch
Patch to remove unnecessary attribute.
> Unncesary TestFixture Attribute on LocalizedTestCase
> ----------------------------------------------------
>
> Key: LUCENENET-316
> URL: https://issues.apache.org/jira/browse/LUCENENET-316
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Priority: Trivial
> Attachments: LUCENENET-316.patch
>
>
> There is an unnecessary TestFixture attribute on the LocalizedTestCase class. While
it does not cause any problems, it appears as a failing test in the NUnit GUI. Patch coming
in a moment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Unncesary TestFixture Attribute on LocalizedTestCase
----------------------------------------------------
Key: LUCENENET-316
URL: https://issues.apache.org/jira/browse/LUCENENET-316
Project: Lucene.Net
Issue Type: Bug
Reporter: Michael Garski
Priority: Trivial
There is an unnecessary TestFixture attribute on the LocalizedTestCase class. While it does
not cause any problems, it appears as a failing test in the NUnit GUI. Patch coming in a
moment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy updated LUCENENET-202:
---------------------------
Attachment: (was: LUCENENET-202.patch)
> Compile warnings trying to build source code, svn revision 829945
> -----------------------------------------------------------------
>
> Key: LUCENENET-202
> URL: https://issues.apache.org/jira/browse/LUCENENET-202
> Project: Lucene.Net
> Issue Type: Bug
> Environment: VS C# Express 2008. A
> Reporter: Corey Trager
> Attachments: csproj.patch, LUCENENET-202.patch
>
>
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,12): warning CS0472:
The result of the expression is always 'true' since a value of type 'bool' is never equal
to 'null' of type 'bool?'
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,24): warning CS0429:
Unreachable expression code detected
> C:\cit\lucene\C#\src\Lucene.Net\Index\FormatPostingsDocsWriter.cs(42,17): warning CS0649:
Field 'Lucene.Net.Index.FormatPostingsDocsWriter.freqStart' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(230,15): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.yycolumn' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(233,16): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.zzAtBOL' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocFieldProcessorPerThread.cs(42,18): warning CS0649:
Field 'Lucene.Net.Index.DocFieldProcessorPerThread.docBoost' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Index\CharBlockPool.cs(31,16): warning CS0649: Field
'Lucene.Net.Index.CharBlockPool.numBuffer' is never assigned to, and will always have its
default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(87,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.byteBuf' is never assigned to, and will always
have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(90,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.otherByteBuf' is never assigned to, and will
always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\CharReader.cs(32,35): warning CS0649: Field
'Lucene.Net.Analysis.CharReader.input' is never assigned to, and will always have its default
value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocumentsWriter.cs(181,37): warning CS0649: Field
'Lucene.Net.Index.DocumentsWriter.newFiles' is never assigned to, and will always have its
default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermVectorsTermsWriter.cs(35,30): warning CS0649:
Field 'Lucene.Net.Index.TermVectorsTermsWriter.termVectorsWriter' is never assigned to, and
will always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermsHash.cs(43,21): warning CS0169: The field
'Lucene.Net.Index.TermsHash.primaryTermsHash' is never used
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/LUCENENET-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy updated LUCENENET-202:
---------------------------
Attachment: LUCENENET-202.patch
> Compile warnings trying to build source code, svn revision 829945
> -----------------------------------------------------------------
>
> Key: LUCENENET-202
> URL: https://issues.apache.org/jira/browse/LUCENENET-202
> Project: Lucene.Net
> Issue Type: Bug
> Environment: VS C# Express 2008. A
> Reporter: Corey Trager
> Attachments: csproj.patch, LUCENENET-202.patch
>
>
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,12): warning CS0472:
The result of the expression is always 'true' since a value of type 'bool' is never equal
to 'null' of type 'bool?'
> C:\cit\lucene\C#\src\Lucene.Net\Search\ComplexExplanation.cs(69,24): warning CS0429:
Unreachable expression code detected
> C:\cit\lucene\C#\src\Lucene.Net\Index\FormatPostingsDocsWriter.cs(42,17): warning CS0649:
Field 'Lucene.Net.Index.FormatPostingsDocsWriter.freqStart' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(230,15): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.yycolumn' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\Standard\StandardTokenizerImpl.cs(233,16): warning
CS0414: The field 'Lucene.Net.Analysis.Standard.StandardTokenizerImpl.zzAtBOL' is assigned
but its value is never used
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocFieldProcessorPerThread.cs(42,18): warning CS0649:
Field 'Lucene.Net.Index.DocFieldProcessorPerThread.docBoost' is never assigned to, and will
always have its default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Index\CharBlockPool.cs(31,16): warning CS0649: Field
'Lucene.Net.Index.CharBlockPool.numBuffer' is never assigned to, and will always have its
default value 0
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(87,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.byteBuf' is never assigned to, and will always
have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Store\NIOFSDirectory.cs(90,35): warning CS0649: Field
'Lucene.Net.Store.NIOFSDirectory.NIOFSIndexInput.otherByteBuf' is never assigned to, and will
always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Analysis\CharReader.cs(32,35): warning CS0649: Field
'Lucene.Net.Analysis.CharReader.input' is never assigned to, and will always have its default
value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\DocumentsWriter.cs(181,37): warning CS0649: Field
'Lucene.Net.Index.DocumentsWriter.newFiles' is never assigned to, and will always have its
default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermVectorsTermsWriter.cs(35,30): warning CS0649:
Field 'Lucene.Net.Index.TermVectorsTermsWriter.termVectorsWriter' is never assigned to, and
will always have its default value null
> C:\cit\lucene\C#\src\Lucene.Net\Index\TermsHash.cs(43,21): warning CS0169: The field
'Lucene.Net.Index.TermsHash.primaryTermsHash' is never used
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.