RE: [Lucene.Net] [VOTE] Apache-Lucene-2.9.4g-incubating-RC1 Release (take 2)
My apologies for not waiting. Sent from my Windows Phone From: Stefan Bodewig Sent: 1/23/2012 9:02 AM To: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene-2.9.4g-incubating-RC1 Release (take 2) On 2012-01-23, Prescott Nasser wrote: I've created a wiki page with the checklist: https://cwiki.apache.org/confluence/display/LUCENENET/Release+Checklist+and+steps+once+a+release+is+approved. Thanks, I've added the points from my list. I've also called a vote in general for 2.9.4g. Personally I would have preferred it if you had waited until you got three +1s from this list. So far I've only seen Christopher's (and imply yours even though you didn't vote explicitly ;-). Once/if Michael gets around voting I'll throw in my +1 as well (on general and here). Stefan
[Lucene.Net] [jira] [Updated] (LUCENENET-446) Make Lucene.Net CLS Compliant
[ https://issues.apache.org/jira/browse/LUCENENET-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-446: -- Fix Version/s: Lucene.Net 3.0.3 Make Lucene.Net CLS Compliant - Key: LUCENENET-446 URL: https://issues.apache.org/jira/browse/LUCENENET-446 Project: Lucene.Net Issue Type: Task Components: Lucene.Net Core Affects Versions: Lucene.Net 2.9.4 Reporter: Prescott Nasser Fix For: Lucene.Net 3.0.3 Attachments: Lucene2.9.4-CLS-partial-fix Make Lucene.Net CLS Compliant -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-439) Correctly Rethrow exceptions in C#
[
https://issues.apache.org/jira/browse/LUCENENET-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-439:
--
Fix Version/s: Lucene.Net 3.0.3
Correctly Rethrow exceptions in C#
--
Key: LUCENENET-439
URL: https://issues.apache.org/jira/browse/LUCENENET-439
Project: Lucene.Net
Issue Type: Sub-task
Components: Lucene.Net Core, Lucene.Net Test
Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g
Environment: all
Reporter: michael herndon
Labels: refactoring, testing,
Fix For: Lucene.Net 3.0.3
There are a few places in the tests and possibly in the code where exceptions
are being rethrown incorrectly and erasing stacktrace.
Please fix these as you come across them and add the ticket number in the
commit message.
BaseTokenStreamTestCase.cs has a good example of this. Inside the RunBare
method:
// Do the test again with onlyUseNewAPI=true
try
{
onlyUseNewAPI = true;
base.RunBare();
}
catch(Exception ex)
{
System.Console.Out.WriteLine(Test failure of ' + GetType() + '
occurred with onlyUseNewAPI=true);
throw ex;
}
in this case you don't need to specify the exception, and we're trapping to
write out the context of the exception problem.
try
{
onlyUseNewAPI = true;
base.RunBare();
}
catch
{
Type type = this.GetType();
Console.WriteLine(Test failure of ' + type.Name + ' occurred with
onlyUseNewAPI=true);
throw;
}
http://msdn.microsoft.com/en-us/library/ms182363(v=vs.80).aspx
http://winterdom.com/2002/09/rethrowingexceptionsinc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Commented] (LUCENENET-372) NLS pack for Lucene.NET: BR, CJK, CN, CZ, DE, FR, NL, RU analyzers
[ https://issues.apache.org/jira/browse/LUCENENET-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191896#comment-13191896 ] Christopher Currens commented on LUCENENET-372: --- All of this code has been ported from the 3.x Java into the 3.0.3 branch. The code above is outdated, in that is uses constructs from 2.9.4 that are no longer used/are deprecated. Are we planning on doing a separate contrib release for 2.9.4, or should this be closed? NLS pack for Lucene.NET: BR, CJK, CN, CZ, DE, FR, NL, RU analyzers -- Key: LUCENENET-372 URL: https://issues.apache.org/jira/browse/LUCENENET-372 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Reporter: Pasha Bizhan Assignee: Prescott Nasser Priority: Minor Labels: Analyzers Attachments: lucene-net-nls.zip Port of java analyzers. Sorry for 1.4 version, it's from 2005 year Update to 2.9.2/2.9.4 compatibility for 2.9.4 release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Commented] (LUCENENET-463) Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances
[ https://issues.apache.org/jira/browse/LUCENENET-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191897#comment-13191897 ] Christopher Currens commented on LUCENENET-463: --- This is, at least, on my list of things to include in 3.0.3, but only if I can find the time to do it. The entire Highlighter project has a lot of changes between what is in it now and what needs to be for it to be the same as Java's highlighter in 3.0.3. This isn't a *top* priority for 3.0.3. If you'd like to port it yourself or parts of it to help make sure it's in the next release, we'd welcome it and include it, otherwise, we'll try and get it in ourselves, time permitting. Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances -- Key: LUCENENET-463 URL: https://issues.apache.org/jira/browse/LUCENENET-463 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Reporter: Steven Priority: Minor Fix For: Lucene.Net 3.0.3 This is described in the Java version, but it does not seem to be in the dot.net port, is there a reason for this as I would have imagined lots of people doing document work would want it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-463) Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances
[ https://issues.apache.org/jira/browse/LUCENENET-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-463: -- Fix Version/s: Lucene.Net 3.0.3 Would like to be able to use a SimpleSpanFragmenter for extrcting whole sentances -- Key: LUCENENET-463 URL: https://issues.apache.org/jira/browse/LUCENENET-463 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Reporter: Steven Priority: Minor Fix For: Lucene.Net 3.0.3 This is described in the Java version, but it does not seem to be in the dot.net port, is there a reason for this as I would have imagined lots of people doing document work would want it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-436) Refactor Deprecated Code inside of tests
[ https://issues.apache.org/jira/browse/LUCENENET-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-436: -- Fix Version/s: Lucene.Net 3.0.3 This is a nice to have for the 3.x release. A lot of the tests are written with deprecated code simply, because they are that way in Java Lucene, and thus haven't been updated. Unless the majority objects, I agree that we should take this approach of removing the deprecated code ourselves, when the test isn't testing the behavior of the deprecated method itself, instead of sticking to exact Java tests. I say we try and get as much of it as we can updated, but not have this issue block a 3.x release if we run out of time. Refactor Deprecated Code inside of tests - Key: LUCENENET-436 URL: https://issues.apache.org/jira/browse/LUCENENET-436 Project: Lucene.Net Issue Type: Sub-task Components: Lucene.Net Test Affects Versions: Lucene.Net 2.9.4g Reporter: michael herndon Labels: refactoring, testing, Fix For: Lucene.Net 3.0.3 * We should still be testing deprecated methods, but we need to use #pragma warning disable/enable 0618 for testing those. otherwise compiler warnings are too numerous to be anywhere near helpful. * We should only be using deprecated methods in places where they are being explicitly tested, other tests that need that functionality in order to validate those tests should be re factored to use methods that are not deprecated. This is one place we should probably deviate from the parent project and make sure that any deprecated code gets isolated to the tests designed only for the deprecated methods and then use the newer API through out the testsuite. This should help move the project forward and remove deprecated API's when the time comes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-423) QueryParser differences between Java and .NET when parsing range queries involving dates
[
https://issues.apache.org/jira/browse/LUCENENET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-423:
--
Fix Version/s: Lucene.Net 3.0.3
Summary: QueryParser differences between Java and .NET when parsing
range queries involving dates (was: QueryParser differences between Java and
.NET)
This is a difference of behavior between searching in Java and .NET. While
.NET is more accurate about DateTime parsing, that difference in behavior seems
to be against what was discussed [in this email
thread|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201112.mbox/%3CCAFZAm_VxWaNZmCAUZPFt2%2B9HJBXJjSTmJ-uLj%3DQh-naGja9MKA%40mail.gmail.com%3E],
regarding people's wishes for the future of the project. Much of what was
agreed upon was the project having much of the same behavior of Java, in that
indexes are compatible and searches in each returning the same results for the
same search on the same index.
QueryParser differences between Java and .NET when parsing range queries
involving dates
Key: LUCENENET-423
URL: https://issues.apache.org/jira/browse/LUCENENET-423
Project: Lucene.Net
Issue Type: Bug
Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
When trying to do a RangeQuery that uses dates in a certain format, .NET
behaves differently from its Java counterpart. The code is the same between
them, but as far as I can tell, it appears that it is a difference in the way
Java parses dates vs how .NET parses dates. To reproduce:
{code:java}
var queryParser = new QueryParser(Lucene.Net.Util.Version.LUCENE_29,
FullText, new StandardAnalyzer(Lucene.Net.Util.Version.LUCENE_29));
var query = queryParser.Parse(Field:[2001-01-17 TO 2001-01-20]);
{code}
You'll notice that query looks like the old DateField format (eg
0g1d64542). If you do the same query in Java (or Luke), you'll notice the
query gets parsed as if it were a RangeQuery of string. AFAIK, Java cannot
parse a string formatted in that way. If you change the string to use /
instead of - in the java, you'll get one that uses DateResolutions and
DateTools.DateToString().
It seems an appropriate fix for this, if we wanted to keep this behavior
similar to Java, would be to write our own DateTime parser that behaved the
same way to Java's parser.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-179) SnowballFilter speed improvment
[ https://issues.apache.org/jira/browse/LUCENENET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Currens updated LUCENENET-179: -- Fix Version/s: Lucene.Net 3.0.3 I haven't looked at the code, but I'm adding it into 3.0.3 anyway. When someone has the time to look over it and test it, we can decide if we plan on including it or not. At first glance, it looks good, but I wouldn't want to sign off on it until we're sure it fits in with the changes of 3.0.3 and passes all tests. SnowballFilter speed improvment --- Key: LUCENENET-179 URL: https://issues.apache.org/jira/browse/LUCENENET-179 Project: Lucene.Net Issue Type: Improvement Components: Lucene.Net Contrib Affects Versions: Lucene.Net 2.9.2 Reporter: Arian Bär Fix For: Lucene.Net 3.0.3 Attachments: FailOverSnowballFilter.cs I'm using Lucene.Net along with snowball stemming to index text from a database. The class Lucene.Net.Analysis.Snowball.SnowballFilter uses the reflection API and the invoke method to call the stem methods of snowball. I have written a Snowball filter which creates a delegate and uses this delegate to stem the words afterwards. This approach improves the indexing speed of my indexing program by about 10%. I would be happy if you include this code into lucene.net. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Created] (LUCENENET-467) .NETify the public API where appropriate
.NETify the public API where appropriate Key: LUCENENET-467 URL: https://issues.apache.org/jira/browse/LUCENENET-467 Project: Lucene.Net Issue Type: Improvement Components: Lucene.Net Contrib, Lucene.Net Core Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.2, Lucene.Net 3.0.3, Lucene.Net 2.9.4g Environment: all Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 Although we haven't abandoned the line-by-line port of Java lucene, there are many idioms in Java that make little to no sense in a .NET assembly. The API can change to allow for a conventional .NET experience, while still maintaining the ability and ease during the porting process of Java logic. * Change Getxxx() and Setxxx() methods to .NET Properties * Implement the [dispose pattern|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] properly. Try, at all costs, to only use finalizers *when necessary*. They are expensive, and most of the classes used already have finalizers that will be called. * Convert Java Iterator-style classes (see TermEnum, TermDocs and others) to implement IEnumerableT * When catching exceptions, do not use *throw;* instead of *throw ex;* to maintain the stack trace -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Created] (LUCENENET-468) Implement the Dispose pattern properly in classes with Close
Implement the Dispose pattern properly in classes with Close Key: LUCENENET-468 URL: https://issues.apache.org/jira/browse/LUCENENET-468 Project: Lucene.Net Issue Type: Sub-task Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, Lucene.Net Test Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.2, Lucene.Net 3.0.3, Lucene.Net 2.9.4g Environment: all Reporter: Christopher Currens Fix For: Lucene.Net 3.0.3 Implement the dispose pattern as [suggested here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that implements Close(). Be sure to implement the IDisposable.Dispose() only in the base class, and have all sub-class behavior overridden in a protected method. This change will involve making sure that everywhere the classes are used in contrib, core, demo and test, that dispose is called on them. We don't want to neglect calling dispose in our own code. For those with Visual Studio 2010 Premium or higher, turning on Code Analysis in the project settings will flag a warning that Dispose needs to be called on a class, so you don't have to manually go searching for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Created] (LUCENENET-469) Convert Java Iterator classes to implement IEnumerableT
Convert Java Iterator classes to implement IEnumerableT
-
Key: LUCENENET-469
URL: https://issues.apache.org/jira/browse/LUCENENET-469
Project: Lucene.Net
Issue Type: Sub-task
Components: Lucene.Net Contrib, Lucene.Net Core
Affects Versions: Lucene.Net 2.9.4, Lucene.Net 3.0.3, Lucene.Net 2.9.4g
Environment: all
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
The Iterator pattern in Java is equivalent to IEnumerable in .NET. Classes
that were directly ported in Java using the Iterator pattern, cannot be used
with Linq or foreach blocks in .NET.
{{Next()}} would be equivalent to .NET's {{MoveNext()}}, and in the below case,
{{Term()}} would be as .NET's {{Current}} property. In cases as below, it will
require {{TermEnum}} to become an abstract class with {{Term}} and {{DocFreq}}
properties, which would be returned from another class or method that
implemented {{IEnumerableTermEnum}}.
{noformat}
public abstract class TermEnum : IDisposable
{
public abstract bool Next();
public abstract Term Term();
public abstract int DocFreq();
public abstract void Close();
public abstract void Dispose();
}
{noformat}
would instead look something like:
{noformat}
public class TermFreq
{
public abstract Term { get; }
public abstract int { get; }
}
public abstract class TermEnum : IEnumerableTermFreq, IDisposable
{
// ...
}
{noformat}
Keep in mind that it is important that if the class being converted implements
{{IDisposable}}, the class that is enumerating the terms (in this case
{{TermEnum}}) should inherit from both {{IEnumerableT}} *and*
{{IDisposable}}. This won't be any change to the user, as the compiler
automatically calls {{IDisposable}} when used in a {{foreach}} loop.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Updated] (LUCENENET-468) Implement the Dispose pattern properly in classes with Close
[
https://issues.apache.org/jira/browse/LUCENENET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-468:
--
Description:
Implement the dispose pattern as [suggested
here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that
implements Close(). Be sure to implement the IDisposable.Dispose() only in the
base class, and have all sub-class behavior overridden in a protected method.
This change will involve making sure that everywhere the classes are used in
contrib, core, demo and test, that dispose is called on them. We don't want to
neglect calling dispose in our own code. For those with Visual Studio 2010
Premium or higher, turning on Code Analysis in the project settings will flag a
warning that Dispose needs to be called on a class, so you don't have to
manually go searching for it.
These changes do not have to be breaking. Instead, also make {{Close}} a
public method in the base class and have it call {{Dispose}}. Mark it with the
Obsolete attribute, so we can remove it in later releases.
was:
Implement the dispose pattern as [suggested
here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that
implements Close(). Be sure to implement the IDisposable.Dispose() only in the
base class, and have all sub-class behavior overridden in a protected method.
This change will involve making sure that everywhere the classes are used in
contrib, core, demo and test, that dispose is called on them. We don't want to
neglect calling dispose in our own code. For those with Visual Studio 2010
Premium or higher, turning on Code Analysis in the project settings will flag a
warning that Dispose needs to be called on a class, so you don't have to
manually go searching for it.
Implement the Dispose pattern properly in classes with Close
Key: LUCENENET-468
URL: https://issues.apache.org/jira/browse/LUCENENET-468
Project: Lucene.Net
Issue Type: Sub-task
Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo,
Lucene.Net Test
Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.0.3,
Lucene.Net 2.9.4g
Environment: all
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
Implement the dispose pattern as [suggested
here|http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx] on any class that
implements Close(). Be sure to implement the IDisposable.Dispose() only in
the base class, and have all sub-class behavior overridden in a protected
method.
This change will involve making sure that everywhere the classes are used in
contrib, core, demo and test, that dispose is called on them. We don't want
to neglect calling dispose in our own code. For those with Visual Studio
2010 Premium or higher, turning on Code Analysis in the project settings will
flag a warning that Dispose needs to be called on a class, so you don't have
to manually go searching for it.
These changes do not have to be breaking. Instead, also make {{Close}} a
public method in the base class and have it call {{Dispose}}. Mark it with
the Obsolete attribute, so we can remove it in later releases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Created] (LUCENENET-470) Change Getxxx() and Setxxx() methods to .NET Properties
Change Getxxx() and Setxxx() methods to .NET Properties
---
Key: LUCENENET-470
URL: https://issues.apache.org/jira/browse/LUCENENET-470
Project: Lucene.Net
Issue Type: Sub-task
Components: Lucene.Net Contrib, Lucene.Net Core
Affects Versions: Lucene.Net 2.9.4, Lucene.Net 3.0.3, Lucene.Net 2.9.4g
Environment: all
Reporter: Christopher Currens
Fix For: Lucene.Net 3.0.3
We should use .NET properties where ever possible. There are many methods in
the API that use methods similar to {{Class.Getx()}} or
{{Class.Setx()}}. These methods often just return a less-accessible field,
with no real logic behind it.
* If there are both public Get/Set methods with no special logic, they can be
turned into an automatic property: Name { get; set; }
* If there are both Get/Set methods with no special logic and the setter is
private, use an automatic property: Name { get; private set; }
* In other cases, use good judgement based with the amount of logic that is
present in the getter and setter methods.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] removing .html files
Any reason we have all the overview and package.html files? can we remove those from the source code or are they needed for something?
Re: [Lucene.Net] removing .html files
They are artifacts from java-doc. Package is for package specific comments and overview is filled with comments about multiple packages. We can remove them, we don't have any need for them. Thanks, Christopher On Mon, Jan 23, 2012 at 11:07 PM, Prescott Nasser geobmx...@hotmail.comwrote: Any reason we have all the overview and package.html files? can we remove those from the source code or are they needed for something?
[Lucene.Net] [jira] [Created] (LUCENENET-471) Remove Package.html and Overview.html artifacts
Remove Package.html and Overview.html artifacts --- Key: LUCENENET-471 URL: https://issues.apache.org/jira/browse/LUCENENET-471 Project: Lucene.Net Issue Type: Task Affects Versions: Lucene.Net 3.0.3 Reporter: Prescott Nasser Assignee: Prescott Nasser Priority: Trivial Fix For: Lucene.Net 3.0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] Coding Standards
All, I just wanted to confirm everyone's stance on the coding guidelines listed in the wiki. https://cwiki.apache.org/confluence/display/LUCENENET/Coding+Guidelines Are these the official guidelines we are using? If they are, has anyone who has Resharper already created rules so others don't have to? I believe that these are the exact rules used in StyleCop, so people without Resharper can use those rules to test the code before check-in, so we may not need to have a ruleset for those who just want to use the stylecop plugin. There are things I like and dislike about the Microsoft Design Standards, specifically, I prefer private variables to start with an underscore for easy identification. Either way, making sure there's a ruleset will be helpful for other people when using tools to conform to the standards. Thanks, Christopher
RE: [Lucene.Net] Coding Standards
fyi, I believe you can request a free resharper license for being an active committer to an open source project (ie Lucene.Net). Date: Mon, 23 Jan 2012 23:20:25 -0800 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org Subject: [Lucene.Net] Coding Standards All, I just wanted to confirm everyone's stance on the coding guidelines listed in the wiki. https://cwiki.apache.org/confluence/display/LUCENENET/Coding+Guidelines Are these the official guidelines we are using? If they are, has anyone who has Resharper already created rules so others don't have to? I believe that these are the exact rules used in StyleCop, so people without Resharper can use those rules to test the code before check-in, so we may not need to have a ruleset for those who just want to use the stylecop plugin. There are things I like and dislike about the Microsoft Design Standards, specifically, I prefer private variables to start with an underscore for easy identification. Either way, making sure there's a ruleset will be helpful for other people when using tools to conform to the standards.Thanks, Christopher
[Lucene.Net] [jira] [Commented] (LUCENENET-465) Error indexing a document end Filed.Store.COMPRESS
[
https://issues.apache.org/jira/browse/LUCENENET-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191975#comment-13191975
]
Christopher Currens commented on LUCENENET-465:
---
It looks by the issue description that you have SharpZipLib? Where is it in
relation to the Lucene.NET dll? Can you print out the stack trace, exception
type, and actual exception method?
Error indexing a document end Filed.Store.COMPRESS
--
Key: LUCENENET-465
URL: https://issues.apache.org/jira/browse/LUCENENET-465
Project: Lucene.Net
Issue Type: Bug
Components: .NET API
Affects Versions: Lucene.Net 2.9.4
Environment: Windows 7 x64 Professional, Visual Studio 2010 Ultimate
SP1, .NET 4.0, Lucene.net 2.9.4.1, SharpZipLib 0.86.0.518
Reporter: João Rosa
Priority: Blocker
Labels: lucene
Fix For: Lucene.Net 2.9.4
I'm developing a index, and need to store values compressed, because its
needed to show that info to the user.
I've the current error: Can not load ICSharpCode.SharpZipLib.dll, when I do
the writer.AddDocument(doc);
The DLLs are from NuGet.
Snippet:
//retirar o directório
System.IO.DirectoryInfo directoryInfo = new
System.IO.DirectoryInfo(path);
//criar o directório para o lucene
Directory directory = FSDirectory.Open(directoryInfo);
//instanciar o analyser
Analyzer analyzer = new SnowballAnalyzer(Portuguese);
//abrir o indíce
bool isNew = !IndexReader.IndexExists(directory);
IndexWriter writer = new IndexWriter(directory, analyzer,
isNew, Lucene.Net.Index.IndexWriter.MaxFieldLength.UNLIMITED);
//gravar o documento
Document doc = new Document();
NumericField numericField = new NumericField(id,
Field.Store.YES, false);
numericField.SetIntValue(id);
doc.Add(numericField);
Field field = new Field(title, title, Field.Store.COMPRESS,
Field.Index.ANALYZED);
field.SetBoost(7);
doc.Add(field);
field = new Field(description, tescription,
Field.Store.COMPRESS, Field.Index.ANALYZED);
doc.Add(field);
writer.AddDocument(doc);
writer.Optimize();
//Close the writer
writer.Commit();
writer.Close();
}
catch (Exception ex)
{
throw ex;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Closed] (LUCENENET-471) Remove Package.html and Overview.html artifacts
[ https://issues.apache.org/jira/browse/LUCENENET-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prescott Nasser closed LUCENENET-471. - Removed from core Remove Package.html and Overview.html artifacts --- Key: LUCENENET-471 URL: https://issues.apache.org/jira/browse/LUCENENET-471 Project: Lucene.Net Issue Type: Task Affects Versions: Lucene.Net 3.0.3 Reporter: Prescott Nasser Assignee: Prescott Nasser Priority: Trivial Fix For: Lucene.Net 3.0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Resolved] (LUCENENET-471) Remove Package.html and Overview.html artifacts
[ https://issues.apache.org/jira/browse/LUCENENET-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prescott Nasser resolved LUCENENET-471. --- Resolution: Fixed Remove Package.html and Overview.html artifacts --- Key: LUCENENET-471 URL: https://issues.apache.org/jira/browse/LUCENENET-471 Project: Lucene.Net Issue Type: Task Affects Versions: Lucene.Net 3.0.3 Reporter: Prescott Nasser Assignee: Prescott Nasser Priority: Trivial Fix For: Lucene.Net 3.0.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
