[Lucene.Net] [jira] Assigned: (LUCENENET-380) Evaluate Sharpen as a port tool

[Troy Howard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Troy Howard reassigned LUCENENET-380:
-

Assignee: Alex Thompson  (was: Prescott Nasser)

Assigning to Alex to this task (now that I figured out how to add people into 
the assignee's list). 



> Evaluate Sharpen as a port tool
> ---
>
> Key: LUCENENET-380
> URL: https://issues.apache.org/jira/browse/LUCENENET-380
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Lucene.Net Contrib, Lucene.Net Core, 
> Lucene.Net Demo, Lucene.Net Test
>Reporter: George Aroush
>Assignee: Alex Thompson
> Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, 
> 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip, IndexWriter.java, 
> Lucene.Net.3_0_3_Sharpen20110106.zip, Lucene.Net.Sharpen20101104.zip, 
> Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java, QueryParser.java, 
> TestBufferedIndexInput.java, TestDateFilter.java
>
>
> This task is to evaluate Sharpen as a port tool for Lucene.Net.
> The files to be evaluated are attached.  We need to run those files (which 
> are off Java Lucene 2.9.2) against Sharpen and compare the result against 
> JLCA result.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool

[Prescott Nasser (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998186#comment-12998186
 ] 

Prescott Nasser commented on LUCENENET-380:
---

Sharcene, Larpen, LarceneLupen!

> Evaluate Sharpen as a port tool
> ---
>
> Key: LUCENENET-380
> URL: https://issues.apache.org/jira/browse/LUCENENET-380
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Lucene.Net Contrib, Lucene.Net Core, 
> Lucene.Net Demo, Lucene.Net Test
>Reporter: George Aroush
>Assignee: Prescott Nasser
> Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, 
> 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip, IndexWriter.java, 
> Lucene.Net.3_0_3_Sharpen20110106.zip, Lucene.Net.Sharpen20101104.zip, 
> Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java, QueryParser.java, 
> TestBufferedIndexInput.java, TestDateFilter.java
>
>
> This task is to evaluate Sharpen as a port tool for Lucene.Net.
> The files to be evaluated are attached.  We need to run those files (which 
> are off Java Lucene 2.9.2) against Sharpen and compare the result against 
> JLCA result.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool

[Troy Howard (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998185#comment-12998185
 ] 

Troy Howard commented on LUCENENET-380:
---

I guess the best thing to do is to put it to a 72 hour vote on the list. 

It would cover, generally, using Sharpen for conversion, and by proxy creating 
and maintaining a non-ASF fork of Sharpen that our process depends on.

The ultimate question, of course, is what should we call the fork? ;)

 

> Evaluate Sharpen as a port tool
> ---
>
> Key: LUCENENET-380
> URL: https://issues.apache.org/jira/browse/LUCENENET-380
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Lucene.Net Contrib, Lucene.Net Core, 
> Lucene.Net Demo, Lucene.Net Test
>Reporter: George Aroush
>Assignee: Prescott Nasser
> Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, 
> 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip, IndexWriter.java, 
> Lucene.Net.3_0_3_Sharpen20110106.zip, Lucene.Net.Sharpen20101104.zip, 
> Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java, QueryParser.java, 
> TestBufferedIndexInput.java, TestDateFilter.java
>
>
> This task is to evaluate Sharpen as a port tool for Lucene.Net.
> The files to be evaluated are attached.  We need to run those files (which 
> are off Java Lucene 2.9.2) against Sharpen and compare the result against 
> JLCA result.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool

[Alex Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998181#comment-12998181
 ] 

Alex Thompson commented on LUCENENET-380:
-

I saw db40 did accept a patch from an outside user, but it was a pretty small 
fix. For our more significant changes a fork is probably better so our progress 
is not dictated by db4o.

> Evaluate Sharpen as a port tool
> ---
>
> Key: LUCENENET-380
> URL: https://issues.apache.org/jira/browse/LUCENENET-380
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Lucene.Net Contrib, Lucene.Net Core, 
> Lucene.Net Demo, Lucene.Net Test
>Reporter: George Aroush
>Assignee: Prescott Nasser
> Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, 
> 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip, IndexWriter.java, 
> Lucene.Net.3_0_3_Sharpen20110106.zip, Lucene.Net.Sharpen20101104.zip, 
> Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java, QueryParser.java, 
> TestBufferedIndexInput.java, TestDateFilter.java
>
>
> This task is to evaluate Sharpen as a port tool for Lucene.Net.
> The files to be evaluated are attached.  We need to run those files (which 
> are off Java Lucene 2.9.2) against Sharpen and compare the result against 
> JLCA result.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool

[Troy Howard (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998175#comment-12998175
 ] 

Troy Howard commented on LUCENENET-380:
---

Alex - I was thinking we could fork Sharpen along those lines. AFAIK, Sharpen 
doesn't accept contributions, and including the source code in our repo would 
require them to donate to us... So we'd have to do that outside of the ASF. We 
could bring together both changes to Sharpen to reduce pre/post patches and 
also create a reusable set of Support classes starting with the ones at NGit. 

Perhaps over time we could convince db4o to merge our fork back in, or donate 
Sharpen to ASF. 







> Evaluate Sharpen as a port tool
> ---
>
> Key: LUCENENET-380
> URL: https://issues.apache.org/jira/browse/LUCENENET-380
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Lucene.Net Contrib, Lucene.Net Core, 
> Lucene.Net Demo, Lucene.Net Test
>Reporter: George Aroush
>Assignee: Prescott Nasser
> Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, 
> 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip, IndexWriter.java, 
> Lucene.Net.3_0_3_Sharpen20110106.zip, Lucene.Net.Sharpen20101104.zip, 
> Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java, QueryParser.java, 
> TestBufferedIndexInput.java, TestDateFilter.java
>
>
> This task is to evaluate Sharpen as a port tool for Lucene.Net.
> The files to be evaluated are attached.  We need to run those files (which 
> are off Java Lucene 2.9.2) against Sharpen and compare the result against 
> JLCA result.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool

[Alex Thompson (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998172#comment-12998172
 ] 

Alex Thompson commented on LUCENENET-380:
-

Looks like NGit does the pre/post as patches. I think we can make the pre/post 
more integrated and generalized by extending sharpen. Their support classes do 
look useful.

> Evaluate Sharpen as a port tool
> ---
>
> Key: LUCENENET-380
> URL: https://issues.apache.org/jira/browse/LUCENENET-380
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Lucene.Net Contrib, Lucene.Net Core, 
> Lucene.Net Demo, Lucene.Net Test
>Reporter: George Aroush
>Assignee: Prescott Nasser
> Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, 
> 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip, IndexWriter.java, 
> Lucene.Net.3_0_3_Sharpen20110106.zip, Lucene.Net.Sharpen20101104.zip, 
> Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java, QueryParser.java, 
> TestBufferedIndexInput.java, TestDateFilter.java
>
>
> This task is to evaluate Sharpen as a port tool for Lucene.Net.
> The files to be evaluated are attached.  We need to run those files (which 
> are off Java Lucene 2.9.2) against Sharpen and compare the result against 
> JLCA result.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [Lucene.Net] Re: Signing Binary Releases

[Stefan Bodewig]

On 2011-02-22, Troy Howard wrote:

> I found that we have an extant KEYS.TXT at:

> https://svn.apache.org/repos/asf/incubator/lucene.net/site/download/KEYS.txt

> Would it be acceptable to simply add to that file, or is this file in
> the wrong location?

The location doesn't really matter but you should copy it to wherever
the distribution files will live as well.

Stefan

[Lucene.Net] [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool

[Troy Howard (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998156#comment-12998156
 ] 

Troy Howard commented on LUCENENET-380:
---

So far Sharpen seems to be the most viable option.

Worth noting: NGit (a .NET port of JGit) is also using Sharpen to do their code 
generation. They have pretty good documentation about the process. They have 
developed a bunch of support classes to enable the Sharpen conversion. I was 
thinking of contacting Lluis (developer of NGit), and seeing if he would be 
able to help us get our Sharpen setup rolling, or at least help evaluate our 
use case. 

Anyhow, check out the project at:

https://github.com/slluis/ngit 

> Evaluate Sharpen as a port tool
> ---
>
> Key: LUCENENET-380
> URL: https://issues.apache.org/jira/browse/LUCENENET-380
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Lucene.Net Contrib, Lucene.Net Core, 
> Lucene.Net Demo, Lucene.Net Test
>Reporter: George Aroush
>Assignee: Prescott Nasser
> Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, 
> 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip, IndexWriter.java, 
> Lucene.Net.3_0_3_Sharpen20110106.zip, Lucene.Net.Sharpen20101104.zip, 
> Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java, QueryParser.java, 
> TestBufferedIndexInput.java, TestDateFilter.java
>
>
> This task is to evaluate Sharpen as a port tool for Lucene.Net.
> The files to be evaluated are attached.  We need to run those files (which 
> are off Java Lucene 2.9.2) against Sharpen and compare the result against 
> JLCA result.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Commented: (LUCENENET-380) Evaluate Sharpen as a port tool

[Prescott Nasser (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998150#comment-12998150
 ] 

Prescott Nasser commented on LUCENENET-380:
---

I see this is assigned to me - but I'm hoping some other folks have been 
playing with sharpen? Also, at this point what are our other options? We could 
do something like tangible softwares java to C# - but that costs money and is 
likely not as extensible

> Evaluate Sharpen as a port tool
> ---
>
> Key: LUCENENET-380
> URL: https://issues.apache.org/jira/browse/LUCENENET-380
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Lucene.Net Contrib, Lucene.Net Core, 
> Lucene.Net Demo, Lucene.Net Test
>Reporter: George Aroush
>Assignee: Prescott Nasser
> Attachments: 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip, 
> 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip, IndexWriter.java, 
> Lucene.Net.3_0_3_Sharpen20110106.zip, Lucene.Net.Sharpen20101104.zip, 
> Lucene.Net.Sharpen20101114.zip, NIOFSDirectory.java, QueryParser.java, 
> TestBufferedIndexInput.java, TestDateFilter.java
>
>
> This task is to evaluate Sharpen as a port tool for Lucene.Net.
> The files to be evaluated are attached.  We need to run those files (which 
> are off Java Lucene 2.9.2) against Sharpen and compare the result against 
> JLCA result.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Assigned: (LUCENENET-379) Clean up Lucene.Net website

[Troy Howard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENENET-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Troy Howard reassigned LUCENENET-379:
-

Assignee: Prescott Nasser  (was: Troy Howard)

> Clean up Lucene.Net website
> ---
>
> Key: LUCENENET-379
> URL: https://issues.apache.org/jira/browse/LUCENENET-379
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Project Infrastructure
>Reporter: George Aroush
>Assignee: Prescott Nasser
>  Labels: Website
> Fix For: Lucene.Net 2.9.2
>
> Attachments: Lucene.zip, New Logo Idea.jpg, asfcms.zip, asfcms_1.patch
>
>   Original Estimate: 80h
>  Remaining Estimate: 80h
>
> The existing Lucene.Net home page at http://lucene.apache.org/lucene.net/ is 
> still based on the incubation, out of date design.  This JIRA task is to 
> bring it up to date with other ASF project's web page.
> The existing website is here: 
> https://svn.apache.org/repos/asf/lucene/lucene.net/site/
> See http://www.apache.org/dev/project-site.html to get started.
> It would be best to start by cloning an existing ASF project's website and 
> adopting it for Lucene.Net.  Some examples, 
> https://svn.apache.org/repos/asf/lucene/pylucene/site/ and 
> https://svn.apache.org/repos/asf/lucene/java/site/

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Commented: (LUCENENET-381) Official release of Lucene.Net 2.9.2

[Troy Howard (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998145#comment-12998145
 ] 

Troy Howard commented on LUCENENET-381:
---

Started the PPMC vote at: http://bit.ly/eRqE13



> Official release of Lucene.Net 2.9.2
> 
>
> Key: LUCENENET-381
> URL: https://issues.apache.org/jira/browse/LUCENENET-381
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, 
> Lucene.Net Test
>Affects Versions: Lucene.Net 2.9.2
>Reporter: George Aroush
>Assignee: Troy Howard
>Priority: Critical
> Fix For: Lucene.Net 2.9.2
>
>
> This task is to create an official packaged released of Lucene.Net 2.9.2.
> See http://www.apache.org/dev/#releases for details on how to create a 
> release.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Work started: (LUCENENET-381) Official release of Lucene.Net 2.9.2

[Troy Howard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENENET-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on LUCENENET-381 started by Troy Howard.

> Official release of Lucene.Net 2.9.2
> 
>
> Key: LUCENENET-381
> URL: https://issues.apache.org/jira/browse/LUCENENET-381
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, 
> Lucene.Net Test
>Affects Versions: Lucene.Net 2.9.2
>Reporter: George Aroush
>Assignee: Troy Howard
>Priority: Critical
> Fix For: Lucene.Net 2.9.2
>
>
> This task is to create an official packaged released of Lucene.Net 2.9.2.
> See http://www.apache.org/dev/#releases for details on how to create a 
> release.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] Commented: (LUCENENET-167) Compact Framework & Silverlight Support

[Hanrock Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENENET-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998134#comment-12998134
 ] 

Hanrock Wang commented on LUCENENET-167:


Very glad to see this request finally goes into release in a month.

> Compact Framework & Silverlight Support
> ---
>
> Key: LUCENENET-167
> URL: https://issues.apache.org/jira/browse/LUCENENET-167
> Project: Lucene.Net
>  Issue Type: Wish
>  Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, 
> Lucene.Net Test
>Reporter: Andrew C. Smith
>Priority: Minor
>  Labels: silverlight
> Fix For: Lucene.Net 2.9.4
>
>
> Lucene.Net should support the Compact Framework & Silverlight versions of the 
> .NET Framework.
> I've looked into what it might take to do this and most of it is pretty 
> trivial to be able to support these frameworks. Most of what this would take 
> is just changing the different type of classes to use for collection classes 
> used inside of Lucene.Net. 
> This does require changing some details in a lot of places, However this 
> should *not* bring any compatibility issues with *Java Lucene*'s API or index 
> format. It will just change the classes used to some different ones that the 
> frameworks support and also maybe need 1 to 3 classes that might need to be 
> implemented in Lucene.net itself.
> Having made these changes Lucene.Net can be more available to new devices 
> such as running on a window mobile cell phone, or your pda, or run in a 
> Windows, Linux, or Mac computer that runs a silverlight application. This 
> will allow the .Net compact framework & silverlight developers to use 
> Lucene.Net in their applications to provide their users with the same 
> capabilities of an awesome search framework. Developers can also use 
> Lucene.Net to provide them spell checking capabilities in these environments. 

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [VOTE] Release Apache Lucene.Net 2.9.2-incubating-RC1

[Troy Howard]

All,

I'm happy to announce that Lucene.Net 2.9.2-incubating-RC1 is
available and ready for your testing and voting.

Release candidate artifacts:

http://people.apache.org/~thoward/Lucene.Net/2.9.2-incubating-RC1/dist/

SVN tag revision:

http://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_2

The vote is open for 72 hours and passes if a majority of at least
three +1 Lucene.Net PMC votes are cast.

Please cast your votes!

[ ] +1 Release this package as Apache Lucene.Net 2.9.2-incubating
[ ] -1 Do not release this package because...

Thanks to everyone involved for the hard work and contributions which
made this release possible.

Thanks,
Troy

RE: [Lucene.Net] how to update the index

[Digy]

http://www.google.com.tr/search?q=%22Near+Realtime+Search%22+lucene

DIGY

-Original Message-
From: Wen Gao [mailto:samuel.gao...@gmail.com] 
Sent: Tuesday, February 22, 2011 11:07 PM
To: lucene-net-dev@lucene.apache.org
Subject: [Lucene.Net] how to update the index

Hi,
I am using lucene to search items, my index store all the data to be
searched, since the data in the index could change due to uses' update, I
should update index evertytime user update data.

could anyone give me some example about how to manage the index?



Wen

Re: [Lucene.Net] how to make the search not case sensitive

[Peter Mateja]

Wen,
You need to make sure that you are using the same analyzer when both
indexing and searching in a particular index field.  For instance, in your
case, you need to ensure that the value "DATABASE" (in whatever field that
is in) is indexed with the StandardAnalyzer.  Then, use the StandardAnalyzer
to search that field.  This should find the match when you search for
"database", "DATABASE", "Database", etc, and return the original value
stored as "DATABASE".

Of course, if you need case sensitivity, then you'd use the KeywordAnalyzer.


If you've got a more complex index schema which requires different analyzers
per field, then you'll need to look into using the PerFieldAnalyzerWrapper
in order to correctly handle indexing and searching.

Peter Mateja
peter.mat...@gmail.com



On Tue, Feb 22, 2011 at 3:13 PM, Wen Gao  wrote:

> Hi,
>
> I am using lucene's standard analyser to search, however, the search result
> is case sensitive. e.g, when i search for "database", "DATABASE" could not
> return.
>
> I could store the typed items as lowercase, and store the stored data as
> lowercase as well, but in this case, the returned results would be lower
> case, instead of the original form. e.g, the returned results would be
> "database" instead of "DATABASE".
>
> Any ideas?
>
>
> Wen
>

[Lucene.Net] how to make the search not case sensitive

[Wen Gao]

Hi,

I am using lucene's standard analyser to search, however, the search result
is case sensitive. e.g, when i search for "database", "DATABASE" could not
return.

I could store the typed items as lowercase, and store the stored data as
lowercase as well, but in this case, the returned results would be lower
case, instead of the original form. e.g, the returned results would be
"database" instead of "DATABASE".

Any ideas?


Wen

[Lucene.Net] how to update the index

[Wen Gao]

Hi,
I am using lucene to search items, my index store all the data to be
searched, since the data in the index could change due to uses' update, I
should update index evertytime user update data.

could anyone give me some example about how to manage the index?



Wen

Re: [Lucene.Net] Re: Signing Binary Releases

[Troy Howard]

Stefan,

Thanks so much for the explanation. This is much clearer.

I found that we have an extant KEYS.TXT at:

https://svn.apache.org/repos/asf/incubator/lucene.net/site/download/KEYS.txt

Would it be acceptable to simply add to that file, or is this file in
the wrong location?

Thanks,
Troy


On Mon, Feb 21, 2011 at 9:38 PM, Stefan Bodewig  wrote:
> On 2011-02-21, Troy Howard wrote:
>
>> Stefan - You indicated that the Apache signing process is
>> straightforward and simple, but the documentation is kind of all over
>> the place.
>
> I've never read any of it ;-)
>
>> It discusses so many edge cases and different methods for doing this
>> that it's hard to know what the correct one is.  I might be missing
>> something. Do you mind breaking it down for me in a very simple step
>> by step manner?
>
> I'll try but skip over the details since they ultimately depend on the
> OpenPGP implementation you use.  The only implementations I have ever
> used were a self-compiled PGP 2.6.x more than ten years ago and several
> versions of GnuPG, all of them running on Linux - and I've never used
> any GUI of any kind.
>
> If anything I write below is unclear, please ask and I'll try to figure
> out the correct answer.  Maybe even by reading the ASF documentation.
>
> First of all you need an OpenPGP implementation.  I use GnuPG, you might
> prefer something graphical.
>
> Then you need a key pair.  This should be straight forward to create
> with your OpenPGP implementation.  It may be best to pick the defaults
> offered as algorithms and the longest key length your implementation
> offers.
>
> In retrospect it may have been a good idea if I had created my key in a
> way that it expired after ten years since the key length of my key will
> no longer be sufficient in a few years (if it still is today).  But then
> again I can simply create a new one and stop using the old one at one
> point in time.
>
> The next step is to publish the key.  There are key servers and
> publishing you key there is a command line option in GnuPG.  Most of the
> key servers have a web frontend where you can simply add your ASCII
> armored exported key as well.  For example .
> The key servers automatically propagate keys from one server to the
> others so it is sufficient to publish to a single server.
>
> You should also create a file called KEYS and add it to Lucene.NET's svn
> area so all developers can add their keys to it.  This one will later be
> published in http://www.apache.org/dist/ as the authoritative source.
> For an example that also explains how to create the file see
> 
>
> The most difficult part is getting your key signed by others.  There is
> no general rule.  You must try to find people who are willing to sign
> your key.  Most people will only do so if you meet F2F so try to contact
> ASF people living close to you.  All bigger ASF events have key signing
> parties just for this purpose.
>
> If your key isn't signed by anybody else you can certainly still sign
> the releases with it - users are just less likely to have chain of trust
> leading to your key.  In reality they likely won't have one anyway.
>
> Finally you create the distribution artifact the way you always did.
> Once done you create a detached signature for each of the distribution
> artifacts.  I.e. if you have foo-1.0-src.zip you sign it which creates
> foo-1.0-src.zip.asc.  You publish both of them side by side.  That is
> really all that needs to be done.
>
> On the download page the link to foo-1.0-src.zip will point to the ASF
> mirror system while the one to foo-1.0-src.zip.asc will always point to
> www.apache.org.
>
> Stefan
>

Re: [Lucene.Net] Creating a Strong Named Assembly as part of our release

[digy digy]

On Tue, Feb 22, 2011 at 3:04 AM, Troy Howard  wrote:

> DIGY - Extracting the public key out is generally only used for delay
> signing.


In my senario, public key will not be used in delay signing. Just for
validating the assembly by comparing the public key in assembly with the
public key file in svn.


> I don't think delay signing would help our situation, because
> it means an end user still needs our private key to make a complete
> signed build.
>
>
An end user still has the choice of using assembly signed by Lucene.Net team
or signing it by compiling the source with his key.  Of course,He can not
sign the assembly with Lucene.Net team's private key and this is the
intented behaviour of "signing"


> As a side note, I just realized that the multiple-signers scenario I
> described in my initial post wouldn't happen, since the public key
> token is included in the fully qualified assembly name. A different
> signer, using a different SNK, would create a DLL with a different
> FQAN. Side-by-side installs of the same version of Lucene.Net, built
> by different signers could function on the same machine, no problem.
>
> Anyhow, so essentially the question that remains is: Publicly
> distribute the SNK or not?
>
> It seems like trying to keep track of the private SNK file via mailing
> list may run into problems at some point.
>
> I think Robert probably is right.. That we should just include it in
> SVN publicly, and make sure we state clearly that even though an
> assembly may be signed using our strong named signature, that unless
> it validates via OpenPGP key, it is not an official build and
> shouldn't be trusted as a ASF endorsed binary. Language to that effect
> should be included in a README file for our binary releases.
>

It would be a solution too, but users will have to learn more tools.



Thanks,
> Troy
>


DIGY

>
>
> On Mon, Feb 21, 2011 at 2:25 PM, Digy  wrote:
> > After we have two files,
> >one contaning public+private key(Lucene.Net.snk)
> >{sn -k Lucene.Net.snk}
> >and the other containing just public key(Lucene.Net.Public.snk)
> >{sn -p Lucene.Net.snk Lucene.Net.Public.snk}
> > we can share Lucene.Net.snk via private mailing list  and put the
> Lucene.Net.Public.snk to svn.
> >
> >
> > Assuming that we create two binary releases(signed + unsigned), users
> have many alternatives like source-code, signed release or unsigned release
> and free to choose any one of them.
> >
> > I don't think that some extreme cases(like one uses the signed-release in
> GAC and then wants to compile and sign with his own key and forgets to
> remove the old one from GAC) should be handled by Lucene.Net.
> > At the end, all Lucene.Net users are developers.
> >
> > DIGY
> >
> >
> > -Original Message-
> > From: Troy Howard [mailto:thowar...@gmail.com]
> > Sent: Monday, February 21, 2011 7:08 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: [Lucene.Net] Creating a Strong Named Assembly as part of our
> release
> >
> > All,
> >
> > There was a request, in LUCENENET-389 [1], that our binary release be
> > signed as a Strong Named Assembly (SNA). There are many compelling
> > reasons to do this, however managing this as an open source project
> > raises some questions.
> >
> > The main question is, how to manage the Strong Name Key (SNK) file?
> >
> > Since this file contains the private key in the strong-naming
> > asymmetric encryption scheme, it is supposed to be kept privately by
> > the signer. In this way, a given assembly can be verified as coming
> > from that particular signer, because only they can make a build which
> > is signed using that private key. If we include that in the source
> > trunk, we are essentially allowing anyone to sign any assembly with
> > the Lucene.Net naming key.
> >
> > This has many implications, not the least of which is that an end user
> > could change the code in a malicious manner, and recompile, signing
> > with our key, and create an assembly which seems like a valid build,
> > and specifically seems to be *endorsed* by the Apache Lucene.Net
> > brand.
> >
> >
> > If we keep the key private, how do we then manage it? Is there a place
> > to store these kinds of resources, where only the committers have
> > access? Is this even reasonable considering the seeming philosophical
> > disparity between this idea and the open source ideal?
> >
> >
> > Another option, is to provide instructions for the end user on how to
> > create their own SNA by building from source, using their SNK. This
> > allows the publisher to establish trust based on their own name,
> > rather than ours. Unfortunately this creates a different issue;
> > multiple signers. Suppose there are two publishers; both creating
> > products that use Lucene.Net, both creating their own differently
> > signed SNA of the same version of Lucene.Net. Further suppose both
> > products end up being installed on the same box. This would cause the
> > s