RE: Porting Automation - Sharpen

[Prescott Nasser]

If it spins up a VM just for conversion purposes, does performance matter much? 
It'll just be one of us converting it. If it has less pre / post work to 
convert correctly to a buildable solution, the extra overhead to convert is 
probably less painful.


~Prescott Nasser



 
> From: m...@aaron-powell.com
> Date: Wed, 10 Nov 2010 17:25:18 +1100
> Subject: Re: Porting Automation - Sharpen
> To: lucene-net-dev@lucene.apache.org
> 
> What's the performance of IKVM? I'm skeptical about having to spin up a Java
> VM inside .NET and the kind of overhead that that would produce
> Aaron Powell
> Umbraco Ninja
> 
> http://www.aaron-powell.com | http://twitter.com/slace | Skype:
> aaron.l.powell | MSN: aaz...@hotmail.com
> 
> 
> On Wed, Nov 10, 2010 at 5:10 PM, Ryan Hoffman  wrote:
> 
> > Hey Guys,
> >
> > I'm loving all the recent activity on the dev list. I've been watching it
> > for some time, and I was also deeply disturbed seeing no posts. This is my
> > first message on the list :).
> >
> > I see that you are evaluating Sharpen. I was wondering if you've heard of
> > IKVM, it's a Java VM that runs on top of .NET/Mono and it also includes a
> > tool which can be used to convert java libraries/apps to .NET assemblies.
> > Check it out at: http://www.ikvm.net/. If this works, it promises to be
> > a very reliable way to convert the official java distribution to .NET.
> >
> > I will give this a shot soon and report back!
> >
> > Ryan Hoffman
> > Software Architect
> > The New Teacher Project
> > www.tntp.org
> >
> > Evaluation systems are broken - so how do we fix them? Teacher Evaluation
> > 2.0 - http://tntp.org/eval2.0
> >
> > -Original Message-
> > From: Aaron Powell [mailto:m...@aaron-powell.com]
> > Sent: Thursday, November 04, 2010 10:25 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: Porting Automation - Sharpen
> >
> > Nice work Alex with getting the ball rolling.
> >
> > I've decided to chuck the contents of that ZIP onto bitbucket (I hope you
> > don't mind) since it'll be easier to track the testing against it than
> > through an email. It's available here:
> > http://hg.slace.biz/lucene-via-sharpen
> > This is the raw package contents from Alex, I'll do some updates to it so
> > that it's not tied to Alex's setup and works more generically (unless
> > someone beats me to it) over the weekend
> >
> > <http://hg.slace.biz/lucene-via-sharpen>Note: This is NOT an attempt to
> > move away from ASF, it's just a way for us to test out how well Sharpen
> > performs as a tool for Java to .NET conversion, if it turns out to be a
> > viable option this will be rolled back to ASF. This is just a playground :)
> >
> > Aaron Powell
> > Umbraco Ninja
> >
> > http://www.aaron-powell.com | http://twitter.com/slace | Skype:
> > aaron.l.powell | MSN: aaz...@hotmail.com
> >
> >
> > On Fri, Nov 5, 2010 at 12:52 PM, Alex Thompson  > >wrote:
> >
> > > I did an initial run of Lucene 3.0.2 through Sharpen. It stops when there
> > > is
> > > an error or finds something it doesn't have a mapping for. I added some
> > > placeholder mappings so it would at least get through a few files.
> > >
> > > Here is a package of what I have so far:
> > > http://convid.com/alex/lucene/Lucene.Net.Sharpen20101104.zip
> > >
> > > It contains the C# files from the test run, the jars for Sharpen, and my
> > > Ant
> > > script with the custom mappings. I encourage others to look at the code
> > and
> > > try sharpen. You can use my script to get started.
> > >
> > > Alex
> > >
> > >
> >
  

RE: Lucene project announcement

[Prescott Nasser]

If I read you right, you're looking for a standards board of some kind to 
develop the standards (file formats, QueryParser syntax, etc). I think that 
makes total sense, but the way I see it, the Java group is the standards board 
at the moment. We are playing catch up to get in the game, but once we are up 
to parity, I don't see why we wouldn't have the ability to make suggestions and 
help steer the "standards"
 
 
 
> From: paul.hadfi...@palmerharvey.co.uk
> To: lucene-net-dev@lucene.apache.org
> Date: Fri, 12 Nov 2010 08:13:48 +
> Subject: RE: Lucene project announcement
> 
> It feels to be that the problem is being approached a* about face (i.e. the 
> wrong way wrong). Maybe it is the way that ASF works but do the constraints 
> of Java define "Lucene, or should it bigger than that? Should Lucene be a 
> full text engine concept that can safely be developed in multiple languages? 
> I'm sure everyone would agree that it would be silly to have different 
> underlying file/data formats and it would definitely make sense that the 
> rules for processing should be the same. But could the developers behind 
> Lucene.JAVA and Lucene.NET work together to define an independent Lucene 
> project and road-map, etc. This could then be developed in each language 
> independently of each other and heaven forbid, Oracle managed to destroy all 
> that is good about Java then Lucene would continue regardless, etc.
> 
> However, if the above (dream?) could not be met, I can't see any way other 
> than keeping with a direct port in the short term. Once it is proven that 
> Lucene.NET can keep up with the Java development, then it might be possible 
> to think about something other than a direct port. This would simply be 
> because every Lucene.NET release is currently trying to catch up with 'x' 
> Lucene releases and it feels like anything other than a direct port would 
> make that nigh on impossible to determine what needs to be implemented in the 
> .NET version.
> 
> - Paul.
> 
> -Original Message-
> From: Hans Merkl [mailto:h...@hmerkl.com] 
> Sent: 11 November 2010 21:53
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Lucere project announcement
> 
> Keep in mind that Java Lucene is being developed actively. Once you
> start to optimize for .NET, it will become harder and harder to keep
> up with future Java Lucene development.
> 
> Whats does MPS do that may be useful for Lucene.NET?
> 
> On Thu, Nov 11, 2010 at 14:54, Karell Ste-Marie  
> wrote:
> > I have done no other past contribution other than use the product,
> >
> > Can I be reminded, once again, why we don't use the .NET Optimized
> > approaches instead of doing a straight code-code port?
> >
> > I understand that the whole purpose of the project is to be a Lucene
> > port to .NET, but should we not at some point in time optimize more for
> > .NET than just continue to try and port more Java to .NET code? From
> > Scratch? Each and every version?
> >
> > It seems to be that if that is the approach then perhaps it would be
> > time better spent to look into a tool such as MPS
> > (http://www.jetbrains.com/mps/) and then use the source java language
> > through this which would product .NET code on the other side.
> >
> > Or perhaps I've just managed to place a size-12 foot in my mouth because
> > the current process is actually almost exactly this today?
> >
> > Comments welcome...
> >
> >
> >
> > Karell Ste-Marie
> > C.I.O. - BrainBank Inc
> > (514) 636-6655
> >
> 
> 
> **
> --=Disclaimer=--
> This communication is to be treated as confidential and the information 
> contained in it may not be used or disclosed except for the purpose for which 
> it has been sent. If you have received this communication in error, please 
> destroy it immediately and notify postmas...@palmerharvey.co.uk. Any 
> defamatory statements or infringements of copyright or licenses by employees 
> of Palmer & Harvey McLane Limited are contrary to company policy. The company 
> will not accept any liability in respect of such a communication. Computer 
> viruses can be transmitted by email. The recipient should check this email 
> and any attachments for the presence of viruses. Palmer & Harvey McLane 
> Limited accepts no liability for any damage caused by any virus transmitted 
> by this email.
> 
> Palmer & Harvey McLane Limited.
> Company registered in England & Wales. Regd. No. 1874153.
> Regd Office P&H House, Davigdor Road, Hove, East Sussex, BN3 1RE.
> **
  

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

[Prescott Nasser]

indeed. Learning as I go.
 



 
> From: neal.granr...@thermofisher.com
> To: lucene-net-dev@lucene.apache.org
> Date: Tue, 30 Nov 2010 08:32:53 -0700
> Subject: RE: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website
> 
> As I understand it, only the official Lucene.NET "committers" (DIGY, George 
> Aroush, and Doug Sale) can commit alterations to the web site or the source.
> 
> - Neal
> 
> -Original Message-
> From: Prescott Nasser (JIRA) [mailto:j...@apache.org] 
> Sent: Thursday, November 25, 2010 12:04 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website
> 
> 
> [ 
> https://issues.apache.org/jira/browse/LUCENENET-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935819#action_12935819
>  ] 
> 
> Prescott Nasser commented on LUCENENET-379:
> ---
> 
> Can anyone commit those files in the zip to the 
> https://svn.apache.org/repos/asf/lucene/lucene.net/site/asfcms? Or how can I 
> get commit access to the location?
> 
> Joe is ready to set up us asf cms space, but we need those files added. Also 
> - if I can't commit, is there a contact I can use to get updates posted? or 
> do I need to always upload files here and then wait for someone to add them?
> 
> > Clean up Lucene.Net website
> > ---
> >
> > Key: LUCENENET-379
> > URL: https://issues.apache.org/jira/browse/LUCENENET-379
> > Project: Lucene.Net
> > Issue Type: Task
> > Reporter: George Aroush
> > Attachments: Lucene.zip
> >
> >
> > 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.
> -
> You can reply to this email to add a comment to the issue online.
> 
  

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

[Prescott Nasser]

Makes sense to me. It just seems like this call went out to save Lucene.Net, 
and there was some initial activity, but since then it seems to have really 
dropped off.
 
There is no way we'll make any end of year deadline with the current activity 
level. I'm hoping it's just thanksgiving that is slowing folks down.
 



 
> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website
> Date: Wed, 1 Dec 2010 01:41:23 +0200
> 
> I got bored with being the only committer who tries to answers the user's
> questions and making commits to keep the project alive.
> So, I continue (for now) to answer some question on mailing lists but
> stopped committing months ago.
> 
> DIGY.
> 
> 
> -Original Message-
> From: Prescott Nasser [mailto:geobmx...@hotmail.com] 
> Sent: Tuesday, November 30, 2010 5:51 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website
> 
> 
> indeed. Learning as I go.
> 
> 
> 
> 
> 
> > From: neal.granr...@thermofisher.com
> > To: lucene-net-dev@lucene.apache.org
> > Date: Tue, 30 Nov 2010 08:32:53 -0700
> > Subject: RE: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website
> > 
> > As I understand it, only the official Lucene.NET "committers" (DIGY,
> George Aroush, and Doug Sale) can commit alterations to the web site or the
> source.
> > 
> > - Neal
> > 
> > -Original Message-
> > From: Prescott Nasser (JIRA) [mailto:j...@apache.org] 
> > Sent: Thursday, November 25, 2010 12:04 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: [jira] Commented: (LUCENENET-379) Clean up Lucene.Net website
> > 
> > 
> > [
> https://issues.apache.org/jira/browse/LUCENENET-379?page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935819#acti
> on_12935819 ] 
> > 
> > Prescott Nasser commented on LUCENENET-379:
> > ---
> > 
> > Can anyone commit those files in the zip to the
> https://svn.apache.org/repos/asf/lucene/lucene.net/site/asfcms? Or how can I
> get commit access to the location?
> > 
> > Joe is ready to set up us asf cms space, but we need those files added.
> Also - if I can't commit, is there a contact I can use to get updates
> posted? or do I need to always upload files here and then wait for someone
> to add them?
> > 
> > > Clean up Lucene.Net website
> > > ---
> > >
> > > Key: LUCENENET-379
> > > URL: https://issues.apache.org/jira/browse/LUCENENET-379
> > > Project: Lucene.Net
> > > Issue Type: Task
> > > Reporter: George Aroush
> > > Attachments: Lucene.zip
> > >
> > >
> > > 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.
> > -
> > You can reply to this email to add a comment to the issue online.
> > 
> 
> 
  

RE: Vote thread started on gene...@lucene.apache.org

[Prescott Nasser]

I was attempting to get things off the ground, but recieved little support from 
those familiar with the apache foundation - how it works, procedures etc, so I 
basically stopped around thanksgiving.
 
I'm still around and interested in helping where I can though. (Just voicing my 
support so people know I exist ;) )


~Prescott Nasser



 
> From: pierogi...@hotmail.com
> To: lucene-net-u...@lucene.apache.org; lucene-net-dev@lucene.apache.org
> Subject: RE: Vote thread started on gene...@lucene.apache.org
> Date: Thu, 30 Dec 2010 11:18:13 -0800
> 
> I'm willing to be a committer as well.
> 
> I agree the entire porting process needs to be publicly documented and much
> of the dev effort (at least initially) will be in this area.
> 
> Alex
> 
> -Original Message-
> From: Lombard, Scott [mailto:slomb...@kingindustries.com] 
> Sent: Thursday, December 30, 2010 10:58 AM
> To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
> Subject: RE: Vote thread started on gene...@lucene.apache.org
> 
> Troy,
> 
> My feeling is that a combination Java and .Net experience is needed. Some
> people will focus on Bug fixes in the .Net code while other focus on the
> translation of the code as their experience allows.
> 
> One of the things I would like to see different with Lucene.Net is that the
> method conversion is kept in the SVN or Wiki. I feel the pre and post
> processing as well as possibly extensions to what ever tool that is used for
> the conversion are more important to this project then the actual executed
> code. Keeping a focus on making strong conversion tools as a community
> should help reduce the lag between a Java releases to a .Net releases. We
> then won't be waiting for one person to make the conversion.
> 
> Scott
> 
> -Original Message-
> From: Troy Howard [mailto:thowar...@gmail.com]
> Sent: Thursday, December 30, 2010 1:38 PM
> To: lucene-net-u...@lucene.apache.org
> Cc: lucene-net-dev@lucene.apache.org
> Subject: Re: Vote thread started on gene...@lucene.apache.org
> 
> Scott,
> 
> I will gladly help put this proposal together and would like to volunteer as
> a committer. I am communicating with others to find some additional
> candidates to be committers.
> 
> Regarding Heath, a quote from his last message in this thread:
> 
> "While I have developed extensively against Lucene.net, I do not possess the
> java skills needed to do a port of the code... So, while I wouldn't mind
> being a committer, I do not think I am qualified."
> 
> Thanks,
> Troy
> 
> 
> On Thu, Dec 30, 2010 at 10:01 AM, Lombard, Scott
>  wrote:
> > Grant,
> >
> > Thanks for your time explaining all the details. I will be willing work
> on a proposal to put Lucene.Net back in to incubation. I will need other
> people to step up and be committers as well. Heath has volunteered and as
> Grant has stated 4 committers are needed to for incubation. Who else is
> willing to be a committer?
> >
> > Grant I will definitely be taking you up on your offer to help on bring
> Lucene.Net into incubation.
> >
> > Scott
> >
> >
> > -Original Message-
> > From: Grant Ingersoll [mailto:gsing...@apache.org]
> > Sent: Thursday, December 30, 2010 12:32 PM
> > To: lucene-net-u...@lucene.apache.org
> > Subject: Re: Vote thread started on gene...@lucene.apache.org
> >
> >
> > On Dec 30, 2010, at 9:51 AM, Heath Aldrich wrote:
> >
> >> Hi Grant,
> >>
> >> Thanks for taking the time to respond.
> >>
> >> While I have developed extensively against Lucene.net, I do not 
> >> possess the java skills needed to do a port of the code... So, while 
> >> I wouldn't mind being a committer, I do not think I am qualified. (I 
> >> guess if I was, I could just use Lucene proper and that would be 
> >> that)
> >>
> >> As to other duties of a committer, I think the ASF is perceived as a
> black box of questions for most of us.
> >>
> >> For one, I don't think anyone outside the 4 committers even understand
> *why* it is a good thing to be on the ASF vs. CodePlex, Sourceforge, etc.
> Maybe if there was an understanding of the why, the requirements of the ASF
> would make more sense. I think a lot of us right now just perceive the ASF
> as the group that is wanting to kill Lucene.net.
> >
> > I don't think we have a desire to kill it, I just think we are faced with
> the unfortunate reality that the project is already dead and now us on the
> PMC have the unfortunate job of cleaning up the mess as best we can. Again,
> it is not even th

RE: Vote thread started on gene...@lucene.apache.org

[Prescott Nasser]

Maybe I'm misunderstanding you, but I think the technology is there - no 
generic porting tool will be 100%, it will always require pre/post processing. 
Sharpen is a pretty good generic conversion tool. 
 
I agree in that I think we need to focus on a process utilizing a tool such as 
sharpen and developing the pre/post processing clean up scripts that are 
specific to Lucene.
 
~Prescott


 
> Subject: RE: RE: Vote thread started on gene...@lucene.apache.org
> Date: Thu, 30 Dec 2010 14:29:21 -0500
> From: stema...@brain-bank.com
> To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
> 
> Folks,
> 
> I will freely admit that I'm seizing the opportunity to raise an old
> point - but that problem would be non-existent if this was a project
> that implemented a methodology as opposed to being a continuous port
> effort. I will even go as far as suggesting that this would broaden (and
> ease) the recruitment of committers. It almost feels like the goal is
> not simply to port Lucene.java to Lucene.net but to also develop a
> technology that ports things automatically. I would almost suggest that
> this in itself could be an ASF TLP. It still feels to me that everyone
> is trying to cut the head off a two-headed dragon with a single sword
> and a single motion.
> 
> Once search algorithms was discovered and implemented - it should be up
> to the language-specific programmers to implement these and optimize
> these as they see fit. Both languages have their strengths and their own
> frameworks - at the moment the java side has great benefits which in
> turn greatly hinder the success of the .net side.
> 
> In a nutshell, while some cultures seem to be better at courtship - the
> fact that I don't speak some of these languages shouldn't make me less
> good at it.
> 
> I think that a project for a Java->NET and NET->Java would be a great
> idea. Again, it would allow a lot of people that are doing the same for
> hundreds of other projects to simply pool their efforts.
> 
> Just my Canadian 2 cents (which is almost at par with the American cents
> these days)
> 
> 
> Karell Ste-Marie
> C.I.O. - BrainBank Inc
> 
> -Original Message-
> From: Lombard, Scott [mailto:slomb...@kingindustries.com] 
> Sent: Thursday, December 30, 2010 2:17 PM
> To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
> Subject: RE: RE: Vote thread started on gene...@lucene.apache.org
> 
> Marco,
> 
> My feeling would be to create strong automated conversion tools to allow
> java Lucene to be ported in to .NET in as few steps and as possible.
> The .net style goal is a noble one, but will require a significant more
> commitment to the project in the future. As each new version of java
> Lucene will have to be integrated by hand into the .net version.
> 
> As the conversion tools get more advanced and robust .net style code may
> be implemented as part of the automated conversion process.
> 
> 
> Scott
  

RE: Vote thread started on gene...@lucene.apache.org

[Prescott Nasser]

In incubator we can probably rewrite the description of the project - but in 
the past we were pushed from doing anything but a straight port becuase the 
description of the project was "line by line port" - where a tool makes sense, 
and .NET specific contructs are basically avoided becuase that wouldn't be a 
line by line port. We talked about using things like Enums but we were shot 
down from this idea by someone...
 
I agree with you whole heartly about utilizing sharpen and jvm just to port the 
code. The Lucere project was the idea of rewriting the java code to .Net, using 
standard constructs. I think the goal for the ASF project was to minimize work 
needed to be done to upgrade to new java things that come out. If we purse this 
direction, then every change needs to be manually ported. I've already said I 
think that is do-able once we are on part with the latest java.
 

~Prescott Nasser
prescott.nas...@hotmail.com
650.208.4205



 
> Subject: RE: Vote thread started on gene...@lucene.apache.org
> Date: Thu, 30 Dec 2010 15:24:32 -0500
> From: stema...@brain-bank.com
> To: lucene-net-dev@lucene.apache.org
> CC: lucene-net-u...@lucene.apache.org
> 
> I think it took be 5 "deletes" of this e-mail and complete rewrites to try to 
> say this in the best way possible:
> 
> First off, Sharpen is a java tool (from the db4o SVN I found) - using sharpen 
> to port lucene to .net means that people now have to install a jvm on their 
> computers in order to contribute. While this may seem like it makes perfect 
> sense in fact it is this type of requirements that scares pure .net 
> developers away. You cannot ask someone to install a bunch of tools "outside" 
> of their comfort zone in order to create a tool that works in their world. 
> Furthermore, it's also saying that now - not only do contributors need to 
> know java and have a jvm, but then they also need to know sharpen in order to 
> make a c# product.
> 
> Gentlemen, I would gladly contribute - I can assure you that I wouldn't be 
> the best but I would be happy to lend a hand - but speaking strictly for 
> myself I don't see myself learning 2-3 new pieces of technologies when I feel 
> that I should just be a good c# programmer to help out.
> 
> Would it not make more sense, given the fact that we want to reduce work and 
> make a quality product that we become more selective about *what* goes 
> through Sharpen and what can be hand-crafted? IE: Do we really need to port 
> the Java methods of writing to files and handling Threading? What about WCF?
> 
> 
> 
> Karell Ste-Marie
> C.I.O. - BrainBank Inc
> 
> 
> -Original Message-
> From: Troy Howard [mailto:thowar...@gmail.com] 
> Sent: Thursday, December 30, 2010 2:46 PM
> To: lucene-net-dev@lucene.apache.org
> Cc: lucene-net-u...@lucene.apache.org
> Subject: Re: Vote thread started on gene...@lucene.apache.org
> 
> That is exactly what I would suggest. Sharpen looks like a great tool, since 
> you can customize it's behaviour. In fact, the only downside is that you have 
> to customize it's behaviour which requires a lot of upfront work.
> 
> Thanks,
> Troy
> 
> 
> On Thu, Dec 30, 2010 at 11:42 AM, Prescott Nasser  
> wrote:
> >
> > Maybe I'm misunderstanding you, but I think the technology is there - no 
> > generic porting tool will be 100%, it will always require pre/post 
> > processing. Sharpen is a pretty good generic conversion tool.
> >
> > I agree in that I think we need to focus on a process utilizing a tool such 
> > as sharpen and developing the pre/post processing clean up scripts that are 
> > specific to Lucene.
> >
> > ~Prescott
  

RE: Initial committers list for Incubator Proposal

[Prescott Nasser]

There are a number of out of the box projects that I think should be developed 
as we have time that will help facilitate new people getting started, be used 
as examples and templates, and give us some good stuff to blog about :). This 
all goes to the marketing/PR/Community stuff that was sent out earlier by 
Michael Herndon

~Prescott Nasser


> From: sk...@sloan.mit.edu
> Date: Fri, 31 Dec 2010 20:18:04 -0500
> Subject: Re: Initial committers list for Incubator Proposal
> To: lucene-net-u...@lucene.apache.org
> CC: lucene-net-dev@lucene.apache.org
> 
> Troy et al,
> 
> Thanks for taking the initiative in reviving Lucene.net. I would like
> to volunteer my time as a contributor. Specifically I would be
> interested in developing a Real-time branch.
> 
> In fact, I have been working on a Lucene.Net based project I had
> called Pulsr. (https://code.google.com/p/pulsr/).  The project is
> inspired even the name is a take on Solr. Pulsr is based on a P2P
> (XMPP/Jabber) model of distributed indexing and querying.  I have not
> made any commits yet - hope to do so pretty soon.
> 
> I believe Lucene.net needs what Solr did to Lucene - a real shot in
> the arm by offering an application server with functionality
> out-of-the-box. Perhaps Pulsr could be that.
> 
> Thanks again & Happy new Year all!
> 
> Shashi
> sk...@alum.mit.edu
> 
> 
> On Thu, Dec 30, 2010 at 7:01 PM, Troy Howard  wrote:
> > All,
> >
> > I'm working on the Incubator Proposal now, and need to establish a
> > list of initial committers.
> >
> > So far, the following people have come forward and offered to be
> > committers (in alphabetical order):
> >
> > Alex Thompson
> > Ben Martz
> > Chris Currens
> > Heath Aldrich
> > Michael Herndon
> > Prescott Nasser
> > Scott Lombard
> > Simone Chiaretta
> > Troy Howard
> >
> > I would like to place an open request for any interested parties to
> > respond to this message with their request to be a Committer. For
> > people who are either on that list or for people who would like to be
> > added, please send a message explaining (briefly) why you think you
> > will be qualified to be involved in the project and specifically what
> > ways you hope to be able to contribute.
> >
> > One thing I would like to point out is that in the Apache world there
> > is a distinction between Committers and Contributors (aka developers).
> > See this link for details:
> >
> > http://incubator.apache.org/guides/participation.html#committer
> >
> >
> > Please consider whether or not you wish to be a Committer or a Contributor.
> >
> > Some quick rules of thumb:
> >
> > Committers:
> >
> > - Committers must be willing to submit a Contributor License Agreement
> > (CLA). See: http://www.apache.org/licenses/#clas
> >
> > - Committers must have enough *consistent* free time to fulfill the
> > expectations of the ASF in terms of reporting,  process, documentation
> > and remain responsive to the community in terms of communication and
> > listening to, considering, and discussing community opinion. These
> > kinds of tasks can consume a lot of time and are some of the first
> > things people stop down when they start running out of time.
> >
> > - A Committer may not even write code, but may simply accept, review
> > and commit code written by others. This is the primary responsibility
> > of a Committer -- to commit code, whether they wrote it themselves or
> > not
> >
> > - Committers may have to perform the unpleasant task of reject
> > contribution from Contributors and explain why in a fair and objective
> > manner. This can be frustrating and time consuming. You may need to
> > play the part of a mentor or engage in debates. You may even be proved
> > wrong and have to swallow your pride.
> >
> > - Committers have direct access to the source control and other
> > resources and so must be personally accountable for the quality of the
> > same and will need to operate under the process and restrictions ASF
> > expects
> >
> >
> > Contributors:
> >
> > - Contributors might have a lot of free time this month, but get
> > really busy next month and have no time at all. They can develop code
> > in short bursts but then drop off the face of the planet indefinitely
> > after that.
> >
> > - Contributors could focus on code only or work from a task list
> > without any need to interact with and be accountable to the community
> > (as this is the responsibility of the Committers)
> >
> > - Contributors can do one-time or infrequently needed tasks like
> > updating the website, documentation, wikis, etc..
> >
> > - Contributors will need to have anything they create reviewed by a
> > Committer and ultimately included by a Committer. Some people find
> > this frustrating, if the Committers are slow to respond or critical of
> > their work.
> >
> >
> > So in your responses, please be clear about whether you would like to
> > offer your help as a Committer or as a Contributor.
> >
> > Thanks,
> > Troy
> >
  

RE: Proposal Stage: Backwards Compatibility / Support

[Prescott Nasser]

I think the 100% Sharpen is more to mean, it should be 100% automatic 
conversion including pre/post processing scripts so that future translations 
can be quick, easy, and as error free as possible. If you replace 100% Sharpen 
with 100% Java 2 CSharp Translator I think Troy's intent stands.
As for Sharpen specifically - I think it comes from when we were trying back in 
mid November to get it up and going, it was the only free option we could find. 
The eclipse plugin I haven't seen before, but should definitely be evaluated. 
As for Tangibles - I actually like their software (I've used their VB.Net -> C# 
for a few projects), but I couldn't get a copy for testing purposes - and 
unless we can get a free licenses for the project, I don't like the idea of 
requiring a piece of not free software as part of our conversion process.
~P




> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Proposal Stage: Backwards Compatibility / Support
> Date: Sun, 2 Jan 2011 19:03:25 +0200
> 
> > The 3.0.X ports should be 100% Sharpen
> Why?
> What about other alternatives?
> 
> Lucene.java 3.0.3 ==> .Net Conversion Samples ( 
> http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> 
> DIGY
> 
> 
> 
> -Original Message-
> From: Troy Howard [mailto:thowar...@gmail.com] 
> Sent: Saturday, January 01, 2011 1:58 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Proposal Stage: Backwards Compatibility / Support
> 
> We are inheriting the outstanding issues facing the Lucene.Net project.
> 
> This includes remaining committed to providing a line-by-line port
> that stays in sync with the Java Lucene releases.
> 
> The project is currently extremely behind schedule on this. The 2.9.2
> code base, which is widely used and thus a fairly well received build,
> has never been formally packaged as a release (i.e. binary builds,
> etc). This is the first order of business to take care of (in terms of
> code).
> 
> After that we need to evaluate weather or not to create releases to
> match all subsequent releases made by the Java Lucene project.
> 
> Those releases are:
> - 3.0.0
> - 3.0.1
> - 2.9.3
> - 3.0.2
> - 2.9.4
> - 3.0.3
> 
> In the interest of time, we could skip some of the intermediate
> releases and just get in sync at 2.9.4 and 3.0.3 releases.
> 
> The 3.0.X ports should be 100% Sharpen conversions and post-processing
> scripts. Once written, anyone should be able to repeat the process of
> pulling down the appropriate Java Lucene SVN revision, executing the
> porting scripts, and building the resulting .NET code, yield a valid
> 3.0.X release with a 1:1 matching API.
> 
> This is something we will need to continue being able to do for every
> subsequent Java Lucene release.
> 
> This aspect of our development should be completely separate from our
> refactoring/re-imagining of a more .NET-like API. They need to be
> separate development branches, and possibly even completely different
> implementations. We will attempt to reuse as much of the automated
> port code as we can, with the understanding that the goal of the
> secondary branch is to make a high-quality .NET implementation of
> Lucene, rather than a API compatible implementation.
> 
> Thanks,
> Troy
> 
> 
> 
> On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson  wrote:
> > Maybe we could just bug-fix support the current 2.9.2 codebase unless people
> > really need something in 2.9.x
> >
> > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> > version.
> >
> > I'd like to throw another idea into the mix which is perhaps the idiomatic
> > version could be created by an automated refactoring of the line-by-line. It
> > might be additional upfront work but might make it easier for future changes
> > from java lucene to be propagated down.
> >
> > Alex
> >
> > -Original Message-
> > From: mhern...@amptools.net [mailto:mhern...@amptools.net] On Behalf Of
> > Michael Herndon
> > Sent: Friday, December 31, 2010 1:28 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Proposal Stage: Backwards Compatibility / Support
> >
> > *Backwards Compatibility / Support: *
> > This is definitely something we need to cover.
> >
> > I'm guessing the obvious choice would be to continue the 2.9.X versions
> > under sharpen, maintain the current api thats has java idioms so that people
> > can continue to use it, release patches, ensure stability with the current
> > community. This would be important for people who have built products on top
> > of lucene.net.
> >
> > The 3.0 version should probably match java in terms of breaking the api due
> > to the language changes or maybe even a separate project inside:
> > lucene.netredux (for lack of a better term at the moment).
> >
> >
> > *
> > *
> > --
> > Michael Herndon
> >
> >
> 
  

RE: Proposal Stage: Backwards Compatibility / Support

[Prescott Nasser]

Also, was there any pre/post processing involved in these files? Was it manual 
/ scripts etc? Just trying to get a feel for the work involved.


> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Proposal Stage: Backwards Compatibility / Support
> Date: Sun, 2 Jan 2011 19:03:25 +0200
> 
> > The 3.0.X ports should be 100% Sharpen
> Why?
> What about other alternatives?
> 
> Lucene.java 3.0.3 ==> .Net Conversion Samples ( 
> http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> 
> DIGY
> 
> 
> 
> -Original Message-
> From: Troy Howard [mailto:thowar...@gmail.com] 
> Sent: Saturday, January 01, 2011 1:58 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Proposal Stage: Backwards Compatibility / Support
> 
> We are inheriting the outstanding issues facing the Lucene.Net project.
> 
> This includes remaining committed to providing a line-by-line port
> that stays in sync with the Java Lucene releases.
> 
> The project is currently extremely behind schedule on this. The 2.9.2
> code base, which is widely used and thus a fairly well received build,
> has never been formally packaged as a release (i.e. binary builds,
> etc). This is the first order of business to take care of (in terms of
> code).
> 
> After that we need to evaluate weather or not to create releases to
> match all subsequent releases made by the Java Lucene project.
> 
> Those releases are:
> - 3.0.0
> - 3.0.1
> - 2.9.3
> - 3.0.2
> - 2.9.4
> - 3.0.3
> 
> In the interest of time, we could skip some of the intermediate
> releases and just get in sync at 2.9.4 and 3.0.3 releases.
> 
> The 3.0.X ports should be 100% Sharpen conversions and post-processing
> scripts. Once written, anyone should be able to repeat the process of
> pulling down the appropriate Java Lucene SVN revision, executing the
> porting scripts, and building the resulting .NET code, yield a valid
> 3.0.X release with a 1:1 matching API.
> 
> This is something we will need to continue being able to do for every
> subsequent Java Lucene release.
> 
> This aspect of our development should be completely separate from our
> refactoring/re-imagining of a more .NET-like API. They need to be
> separate development branches, and possibly even completely different
> implementations. We will attempt to reuse as much of the automated
> port code as we can, with the understanding that the goal of the
> secondary branch is to make a high-quality .NET implementation of
> Lucene, rather than a API compatible implementation.
> 
> Thanks,
> Troy
> 
> 
> 
> On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson  wrote:
> > Maybe we could just bug-fix support the current 2.9.2 codebase unless people
> > really need something in 2.9.x
> >
> > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> > version.
> >
> > I'd like to throw another idea into the mix which is perhaps the idiomatic
> > version could be created by an automated refactoring of the line-by-line. It
> > might be additional upfront work but might make it easier for future changes
> > from java lucene to be propagated down.
> >
> > Alex
> >
> > -Original Message-
> > From: mhern...@amptools.net [mailto:mhern...@amptools.net] On Behalf Of
> > Michael Herndon
> > Sent: Friday, December 31, 2010 1:28 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Proposal Stage: Backwards Compatibility / Support
> >
> > *Backwards Compatibility / Support: *
> > This is definitely something we need to cover.
> >
> > I'm guessing the obvious choice would be to continue the 2.9.X versions
> > under sharpen, maintain the current api thats has java idioms so that people
> > can continue to use it, release patches, ensure stability with the current
> > community. This would be important for people who have built products on top
> > of lucene.net.
> >
> > The 3.0 version should probably match java in terms of breaking the api due
> > to the language changes or maybe even a separate project inside:
> > lucene.netredux (for lack of a better term at the moment).
> >
> >
> > *
> > *
> > --
> > Michael Herndon
> >
> >
> 
  

RE: Proposal Stage: Backwards Compatibility / Support

[Prescott Nasser]

I'm pretty sure Tangible does provide free licenses to open source projects - 
but they must be well and established, which I believe Lucene qualifies as.
Regarding the methodology - I think based on free open source tools isn't 
required, as long as it's free to us, it should suit our purposes - why must it 
be open source if it fits our needs? (Tangible isn't open source). 
Customizing the conversions is definitely beneficial, but if pre/post 
processing scripts achieve similar results to the actual customizing of the 
conversion process, I don't see any difference. 
Regarding the non build-able solutions - Sharpen as is won't give us a 
build-able solution either - it will require us to tweak it, as would any 
option we choose. The question really is do we create scripts that run 
independently of the conversion process or do we customize the actual 
conversion process. I don't think there is really much distinction in which we 
chose.
Rolling our own conversion tool would be cool, but it's definitely outside my 
comfort zone, and my limited knowledge leads me to believe it would be more 
work than other options and would take away from the main goal of the project. 
This is more my own feelings, not necessarily grounded in reality.


> From: thowar...@gmail.com
> Date: Sun, 2 Jan 2011 15:15:39 -0800
> Subject: Re: Proposal Stage: Backwards Compatibility / Support
> To: lucene-net-dev@lucene.apache.org
> 
> I think Prescott explained it very well. I should not have specified a
> tool. Any tool that enables a 100% automated conversion will meet our
> needs.
> 
> What we need is a methodology for conversion which meets these criteria:
> - Automated, Repeatable, and Well Documented (e.g. a script or build
> task with minimal human involvement)
> - Based on free, open source tools
> - Performs a reasonable and high quality conversion that presents a
> 1:1 API between Java/C# and the same functionality and performance
> 
> 
> I liked the idea of using Sharpen because it's FOSS and because it
> allows you to customize your conversions. It's the only system I've
> found that allows you to modify it's behaviour. Most of the other
> conversion tools just crank through the code "doing their best" and
> leave you will a partial conversion which must then be manually
> cleaned up. I'd like to have a tool which allows us to define custom
> conversion so that at the end of the automated (but custom configured)
> process, you have no need to do any additional manual work. I think
> Sharpen might enable that.
> 
> That said, I think we should explore other options. One possibility is
> for us to ask Tangible to donate licenses for their tool. Many
> companies will donate licenses to open source projects. That leaves
> the question: Does the Tangible tool meet the above criteria even if
> it was freely available to us?
> 
> Another possibility is to develop a customized conversion tool. This
> isn't quite as hard as it may seem. There are existing tools (such as
> ANTLR) that can take Java source and parse it into an AST (Abstract
> Syntax Tree). Then, we can convert the Java AST to a C# AST, and
> compile using the .NET BCL. Writing a *generalized* converter for that
> purpose would be difficult. Writing one that just supports the needs
> of our project would be less difficult. We could also incorporate a
> facility to inject custom conversion logic into the AST->AST
> conversion logic. Much of it could be generalized, and where it didn't
> have appropriate conversion logic, or where we wanted to override
> false-positive logic, we could specify a injectable piece of
> conversion logic that we manually coded.
> 
> That may seem like a lofty plan, but  it could work, and might be the
> best solution in the end. We could start a separate project just for
> that, and perhaps start working towards a system that could be used
> for all the Java projects at Apache, to generate customized
> conversions to C#.
> 
> I recall finding a open source project that was similar to the AST
> level conversion process I was just describing, but at the moment I
> can't remember the name of the project or find it in Google. :(
> 
> Here's a similar project that uses this methodology to go from Java to Scala:
> 
> http://code.google.com/p/jatran/
> 
> It was designed to be extended to work with numerous output languages,
> so that could be a good starting point. It only supports Java 5 (1.5)
> but that should be sufficient to port Lucene.
> 
> Anyhow, those are my thoughts at the moment.
> 
> Thanks,
> Troy
> 
> On Sun, Jan 2, 2011 at 1:35 PM, Prescott Nasser  wrote:
> >
> > I think the 100% Sharpen is more to mean, it s

RE: Proposal Stage: Backwards Compatibility / Support

[Prescott Nasser]

Here is a Sharpen conversion Alex Thompson did in November: 
https://issues.apache.org/jira/secure/attachment/12459581/Lucene.Net.Sharpen20101114.zip
>From my understanding there was no pre/post processing done. I also believe 
>it's 2.9.2, not 3.0.3 as Digy's are.
Here is the JIRA issue for the associated conversations: 
https://issues.apache.org/jira/browse/LUCENENET-380





> From: geobmx...@hotmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Proposal Stage: Backwards Compatibility / Support
> Date: Sun, 2 Jan 2011 13:36:49 -0800
> 
> 
> Also, was there any pre/post processing involved in these files? Was it 
> manual / scripts etc? Just trying to get a feel for the work involved.
> 
> 
> > From: digyd...@gmail.com
> > To: lucene-net-dev@lucene.apache.org
> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> > Date: Sun, 2 Jan 2011 19:03:25 +0200
> > 
> > > The 3.0.X ports should be 100% Sharpen
> > Why?
> > What about other alternatives?
> > 
> > Lucene.java 3.0.3 ==> .Net Conversion Samples ( 
> > http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> > 
> > DIGY
> > 
> > 
> > 
> > -Original Message-
> > From: Troy Howard [mailto:thowar...@gmail.com] 
> > Sent: Saturday, January 01, 2011 1:58 AM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: Proposal Stage: Backwards Compatibility / Support
> > 
> > We are inheriting the outstanding issues facing the Lucene.Net project.
> > 
> > This includes remaining committed to providing a line-by-line port
> > that stays in sync with the Java Lucene releases.
> > 
> > The project is currently extremely behind schedule on this. The 2.9.2
> > code base, which is widely used and thus a fairly well received build,
> > has never been formally packaged as a release (i.e. binary builds,
> > etc). This is the first order of business to take care of (in terms of
> > code).
> > 
> > After that we need to evaluate weather or not to create releases to
> > match all subsequent releases made by the Java Lucene project.
> > 
> > Those releases are:
> > - 3.0.0
> > - 3.0.1
> > - 2.9.3
> > - 3.0.2
> > - 2.9.4
> > - 3.0.3
> > 
> > In the interest of time, we could skip some of the intermediate
> > releases and just get in sync at 2.9.4 and 3.0.3 releases.
> > 
> > The 3.0.X ports should be 100% Sharpen conversions and post-processing
> > scripts. Once written, anyone should be able to repeat the process of
> > pulling down the appropriate Java Lucene SVN revision, executing the
> > porting scripts, and building the resulting .NET code, yield a valid
> > 3.0.X release with a 1:1 matching API.
> > 
> > This is something we will need to continue being able to do for every
> > subsequent Java Lucene release.
> > 
> > This aspect of our development should be completely separate from our
> > refactoring/re-imagining of a more .NET-like API. They need to be
> > separate development branches, and possibly even completely different
> > implementations. We will attempt to reuse as much of the automated
> > port code as we can, with the understanding that the goal of the
> > secondary branch is to make a high-quality .NET implementation of
> > Lucene, rather than a API compatible implementation.
> > 
> > Thanks,
> > Troy
> > 
> > 
> > 
> > On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson  
> > wrote:
> > > Maybe we could just bug-fix support the current 2.9.2 codebase unless 
> > > people
> > > really need something in 2.9.x
> > >
> > > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> > > version.
> > >
> > > I'd like to throw another idea into the mix which is perhaps the idiomatic
> > > version could be created by an automated refactoring of the line-by-line. 
> > > It
> > > might be additional upfront work but might make it easier for future 
> > > changes
> > > from java lucene to be propagated down.
> > >
> > > Alex
> > >
> > > -Original Message-
> > > From: mhern...@amptools.net [mailto:mhern...@amptools.net] On Behalf Of
> > > Michael Herndon
> > > Sent: Friday, December 31, 2010 1:28 PM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: Proposal Stage: Backwards Compatibility / Support
> > >
> > > *Backwards Compatibility / Support: *
> > > This is definitely something we need to cover.
> > >
> > > I'm guessing the obvious choice would be to continue the 2.9.X versions
> > > under sharpen, maintain the current api thats has java idioms so that 
> > > people
> > > can continue to use it, release patches, ensure stability with the current
> > > community. This would be important for people who have built products on 
> > > top
> > > of lucene.net.
> > >
> > > The 3.0 version should probably match java in terms of breaking the api 
> > > due
> > > to the language changes or maybe even a separate project inside:
> > > lucene.netredux (for lack of a better term at the moment).
> > >
> > >
> > > *
> > > *
> > > --
> > > Michael Herndon
> > >
> > >
> > 
> 

RE: Website

[Prescott Nasser]

The house CMS is brand spanking new, http://www.apache.org/dev/cms.html, and 
from my understanding it is what ASF would like to move everything towards. It 
looks flexible and easy to use, I really couldn't think of objections to using 
it.I actually built the skeleton files required and was hoping to get them set 
up by some committer / someone who know the process with ASF. The files are 
attached to this JIRA: https://issues.apache.org/jira/browse/LUCENENET-379. 
From my understanding layouts are open to whatever we want to go with as long 
as they conform to branding guidelines: 
http://www.apache.org/foundation/marks/pmcs. The skeleton files are set up to 
use the Forrest Layout to match the Lucene Java website, but again we aren't 
tied to anything from my understandingGrant asked the infrastructure team to 
set up some space (https://issues.apache.org/jira/browse/INFRA-3181, 
https://svn.apache.org/repos/asf/lucene/cms), but rereading the thread it looks 
like it might have been for Lucene/Solr. ~Prescott
As an aside, anytime I try to reply from Troy's emails, I get delivery 
failure..any thoughts why?

  

RE: Proposal Stage: Net Idiomatic Api Version

[Prescott Nasser]

I think good documentation, examples that have best practices is key to 
fostering a good Lucene.Net community. No question in my mind that we would do 
this.
~Prescott



> Subject: RE: Proposal Stage: Net Idiomatic Api Version
> Date: Tue, 4 Jan 2011 12:32:45 -0500
> From: stema...@brain-bank.com
> To: lucene-net-dev@lucene.apache.org
> 
> Peter,
> 
> I completely agree - upon reading my last post it lacked a critical
> component to actually bring some value to the conversation which you
> mentioned. The USING keyword is key, perhaps as Robert mentioned it may
> not be in the best of lights given the context of the example but that
> is indeed how it should be used in the .NET framework.
> 
> Perhaps the documentation for Lucene.NET can include examples that
> demonstrate the use of some of the expensive classes implemented as
> Singletons - perhaps even code that up for the client as part of the
> library itself (or in code examples). Clumsy coders would then not be
> able to "mess up" the performance of Lucene.NET as much as they could
> given their broad control over some of these objects and their lifetime.
> 
> 
> 
> Karell Ste-Marie
> C.I.O. - BrainBank Inc
> 
> 
> -Original Message-
> From: Peter Mateja [mailto:peter.mat...@gmail.com] 
> Sent: Tuesday, January 04, 2011 12:15 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Proposal Stage: Net Idiomatic Api Version
> 
> Robert... good points all.  I especially agree that basing initial
> idiomatic work on 3.0+ makes sense (indeed, I believe this is what
> Lucere.Net had agreed to do.)
> 
> Use of IDisposable can certainly lead to worst practices concerning
> IndexReader / IndexWriter objects.  However, the IDisposable pattern (if
> implemented correctly... see
> http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx,
> http://www.codeproject.com/KB/dotnet/idisposable.aspx and Framework
> Design Patterns book mentioned earlier), really is the best way (in
> .Net) to ensure proper handling of both unmanaged resources, and
> stateful managed resources.
> 
> I think a good combination of documentation and examples could do much
> to discourage worst practices.  In some cases, the sample 'using' code
> you refer to might be appropriate... though in most the lifetime of an
> IndexWriter object might be controlled at a higher context (AppDomain,
> etc.)  Let's ensure that Lucene.Net users know the how and why for each
> approach.
> 
> Peter Mateja
> peter.mat...@gmail.com
  

RE: Proposal Stage: Backwards Compatibility / Support

[Prescott Nasser]

For number 2, you're spot on - free to the Lucene.Net project is probably the 
relevant piece. Someone mentioned having an open source tool that we could 
customize directly for our conversion purposes would be useful - but I think 
that really goes to 1 and 3 - if we can create pre/post processing scripts that 
uses a non open tool what does it matter. 
I hope people are working with the code digy linked to a few days ago to really 
evaluate the extend of the extra work required to get those to build (I know I 
have spent some time digging in and I would like to spend a bit more time). I 
also hope someone is taking a lead on the Sharpen convert - I don't have any of 
the stuff on my system, and don't really have any knowledge of it, so I am 
hesitant to jump in and try to make a 3.0.3 port - is anyone working on that?
I don't think we need them to be buildable , but we need enough people familiar 
with the different options so that we can have an informed decision.

I would ask that everyone download digy's conversions and begin to play with 
those. I would also ask that someone who has sharpen or is familiar with it to 
please step up and do a quick conversion of lucene 3.0.3 and give the group a 
link to that. This would give us 3 conversion tools to evalute.
If anyone can step up and do a 3.0.3 Sharpen conversion in the next couple of 
days please let us know, otherwise I will get started downloading /installing 
the required stuff and digging into Sharpen documentation, I think we need to 
get this ball rolling.
Also, I'm not sure how quickly we need to make a decision, since Troy hasn't 
submitted a proposal to the ASF. I have no idea how long that process might 
take.
~Prescott
> From: slomb...@kingindustries.com
> To: lucene-net-dev@lucene.apache.org
> Date: Tue, 4 Jan 2011 16:37:12 -0500
> Subject: RE: Proposal Stage: Backwards Compatibility / Support
> 
> A couple of different packages have been mentioned for the conversion.  What 
> criteria should be used to determine the best software to use?
> 
> Given the items mention by troy.  How do we metric these items for a 
> comparison?
> 
> 1. Automated, Repeatable, and Well Documented (e.g. a script or build task 
> with minimal human involvement)
> 2. Based on free, open source tools
> 3. Performs a reasonable and high quality conversion that presents a
> 1:1 API between Java/C# and the same functionality and performance
> 
> Note:  Number 2 might be changed to just the software being free to the 
> Lucene.Net project.
> 
> How much up front work do we do to decide on the correct conversion tool?  
> Does the team think we need to get a working source from each tool and then 
> decide?  Should we convert a single file?  Should we convert an analyzer?
> 
> 
> 
> Scott
> 
> 
> -Original Message-
> From: digy digy [mailto:digyd...@gmail.com]
> Sent: Monday, January 03, 2011 2:26 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Proposal Stage: Backwards Compatibility / Support
> 
> No pre/post processing involved. They are just to see how the output of
> these tools looks like.
> 
> DIGY
> 
> On Sun, Jan 2, 2011 at 11:36 PM, Prescott Nasser wrote:
> 
> >
> > Also, was there any pre/post processing involved in these files? Was it
> > manual / scripts etc? Just trying to get a feel for the work involved.
> >
> >
> > > From: digyd...@gmail.com
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> > > Date: Sun, 2 Jan 2011 19:03:25 +0200
> > >
> > > > The 3.0.X ports should be 100% Sharpen
> > > Why?
> > > What about other alternatives?
> > >
> > > Lucene.java 3.0.3 ==> .Net Conversion Samples (
> > http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> > >
> > > DIGY
> > >
> > >
> > >
> > > -Original Message-
> > > From: Troy Howard [mailto:thowar...@gmail.com]
> > > Sent: Saturday, January 01, 2011 1:58 AM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: Re: Proposal Stage: Backwards Compatibility / Support
> > >
> > > We are inheriting the outstanding issues facing the Lucene.Net project.
> > >
> > > This includes remaining committed to providing a line-by-line port
> > > that stays in sync with the Java Lucene releases.
> > >
> > > The project is currently extremely behind schedule on this. The 2.9.2
> > > code base, which is widely used and thus a fairly well received build,
> > > has never been formally packaged as a release (i.e. binary builds,
> > > etc). This is the first order of busin

RE: Build & CI Considerations

[Prescott Nasser]

would the accessibility just be a configuration script? I'm not sure how CI is 
set up, but I assume that we could set up something that points to our 
repository for that, thus any committer could update the configuration script.
 
Also, I dug a bit into Hudson (I'm not familiar with it), there is MSBuild 
support (http://wiki.hudson-ci.org/display/HUDSON/MSBuild+Plugin), and looking 
at the FAQ for Hudson that the apache infrastructure team has it looks like 
plugin's can be added 
(http://wiki.apache.org/general/Hudson#How_do_I_install_a_new_Hudson_plugin.3F).
 This is likely something they had to do for us, but I don't see why it would 
be an issue for them to do it for us
 
~Prescott





> Date: Sat, 29 Jan 2011 15:49:51 -0500
> Subject: Re: Build & CI Considerations
> From: mhern...@o19s.com
> To: lucene-net-dev@lucene.apache.org
>
> Something to think about for future use is accessibility of the build server
> for those maintaining.
>
> How we do go about sharing that information, obviously you don't want to
> hand out access to the ci server to a public mailing list.
>
>
>
>
>
> On Fri, Jan 28, 2011 at 1:41 PM, Wyatt Barnett wrote:
>
> > Why do I forget to check against the obvious? Anyhow, I guess we can
> > run with what we have, though that build is not doing much. Any idea
> > how we get administrative access over there? Might as well try and get
> > it to do stuff like run the tests as well.
> >
> > I think long-term, we'll need something a bit more custom, at least
> > for the build slave/build agent angle --- that would be where the
> > magic largely happens. Such as automated sharpen builds . . .
> >
> >
> > On Thu, Jan 27, 2011 at 5:29 AM, digy digy wrote:
> > > No. It's Rune's work.
> > >
> > >
> > http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/200912.mbox/%3c4b1820f4.10...@gmail.com%3E
> > >
> > > <
> > http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/200912.mbox/%3c4b1820f4.10...@gmail.com%3E
> > >
> > > DIGY
> > >
> > > On Thu, Jan 27, 2011 at 12:16 PM, Glyn Darkin > > >wrote:
> > >
> > >> The guys at code better run a Team City CI which has been building
> > >> Lucene.Net for a while
> > >>
> > >> I believe that DIGY set this up.
> > >>
> > >> http://teamcity.codebetter.com/login.html
> > >>
> > >> Glyn
> > >>
> > >>
> > >> On 27 Jan 2011, at 09:28, Stefan Bodewig wrote:
> > >>
> > >> > On 2011-01-26, Wyatt Barnett wrote:
> > >> >
> > >> >> 2) CI : oh hells yeah. My vision would be to setup something where
> > the
> > >> >> automated conversion would be triggered by commits to the "stable"
> > >> >> branch of the java project. I think if we can construct this bit
> > right
> > >> >> we can even really get down the road of automatically running all the
> > >> >> conversion options until we get it "right".
> > >> >
> > >> > Sounds good. "Back to the mundane" as you said later the ASF runs a
> > few
> > >> > options for CI , one of them is Hudson
> > >> > which has at least one Windows
> > slave
> > >> > installation (Server 2008) and is supposed to support MSBuild.
> > Buildbot
> > >> > might work as well.
> > >> >
> > >> > I'm not up to speed with the state of xbuild but adding support for it
> > >> > to Gump (which fills quite a different role from a traditional CI)
> > >> > wouldn't be too hard and give us builds on Mono - albeit 2.4 right
> > now,
> > >> > this could be changed by adding the Mono PPAs to the Ubuntu servers.
> > >> >
> > >> > Stefan
> > >>
> > >> Glyn Darkin
> > >>
> > >> Darkin Systems Ltd
> > >> Mob: 07961815649
> > >> Fax: 08717145065
> > >> Web: www.darkinsystems.com
> > >>
> > >> Company No: 6173001
> > >> VAT No: 906350835
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> >
>
>
>
> --
> Michael Herndon
> Senior Developer (mhern...@o19s.com)
> 804.767.0083
>
> [connect online]
> http://www.opensourceconnections.com
> http://www.amptools.net
> http://www.linkedin.com/pub/michael-herndon/4/893/23
> http://www.facebook.com/amptools.net
> http://www.twitter.com/amptools-net 

wiki

[Prescott Nasser]

Does anyone know if the wiki will move once / if we get taken into the 
incubator? I'd like to start doing a bunch of updating, but if we have to port 
it all over to a new wiki space for the incubator, it's kind of pointless
 
~Prescott 

Re: Incubator Infrastructure: Wiki

[Prescott Nasser]

Confluence has some fun plugins: 

Http://www.atlassian.com/software/confluence/tour/confluence-wiki-plugins.jsp 

It also supports alternative templates for the output, I don't believe Moin has 
the same capabilities. There is an upgraded code macro plugin which leads me to 
believe there is basic code highlighting support, and if needed we could always 
install the plugin.

That said since I've used Moin I'm happy to go with what I know 

-Prescott
-Original Message-
From: Michael Herndon 
Date: Tue, 1 Feb 2011 12:35:40 
To: 
Subject: Re: Incubator Infrastructure: Wiki

either wiki
* set up to support code syntax highlighting/coloring ?
* attachments ?

(I generally use trac, so I'm not totally familiar what the other two are
offered, much less what our limitations are)


On Tue, Feb 1, 2011 at 6:00 AM, Stefan Bodewig  wrote:

> Hi,
>
> the proposal says a new Wiki should be set up.  There are two choices of
> Wiki on ASF infrastructure right now: Moin and Confluence.  Anybody who
> has added to the propsal or the current wiki[1] has already interacted
> with Moin, an example of Confluence would be the wiki of the Buildr[2]
> project.
>
> Any strong preferences?
>
> Cheers
>
>    Stefan
>
> [1] http://wiki.apache.org/jakarta-lucene/lucene.Net
>
> [2] https://cwiki.apache.org/BUILDR/
>

RE: Arabic Analyzer

[Prescott Nasser]

Unfortunately, I don't think we have that. We're working on creating a new port 
of the java lucene code, but I don't know the timeline yet - I'm sure there 
will be a lot of chatter on this mailing list soon.
 
~Prescott






> Date: Sat, 5 Feb 2011 22:57:11 +
> Subject: Arabic Analyzer
> From: b...@planetcloud.co.uk
> To: lucene-net-dev@lucene.apache.org
>
> Is there an Arabic Analyzer available for Lucene.NET. I see there has been
> one contributed to the Java project but wasn't sure if this has been ported.
>
> Thanks,
>
> Ben 

RE: Arabic Analyzer

[Prescott Nasser]

Hey Digy,
 
Do you use sharpen (or some other conversion tool) or for such minimal amounts 
of code, do you just port it by hand?
 
~Prescott






> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Arabic Analyzer
> Date: Sun, 6 Feb 2011 23:58:01 +0200
>
> Here is a port of lucene.java's arabic analyzer (
> https://issues.apache.org/jira/browse/LUCENENET-392 )
>
> You can safely remove nunit dependency and test cases from the project.
>
> DIGY
>
> -Original Message-
> From: Ben Foster [mailto:b...@planetcloud.co.uk]
> Sent: Sunday, February 06, 2011 5:47 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Arabic Analyzer
>
> Is it still possible to use fixed term queries in Arabic (i.e. NOT using an
> Analyzer)?
>
> Thanks
> Ben
>
> On 6 February 2011 00:51, Prescott Nasser wrote:
>
> >
> > Unfortunately, I don't think we have that. We're working on creating a new
> > port of the java lucene code, but I don't know the timeline yet - I'm sure
> > there will be a lot of chatter on this mailing list soon.
> >
> > ~Prescott
> >
> >
> >
> >
> >
> > 
> > > Date: Sat, 5 Feb 2011 22:57:11 +
> > > Subject: Arabic Analyzer
> > > From: b...@planetcloud.co.uk
> > > To: lucene-net-dev@lucene.apache.org
> > >
> > > Is there an Arabic Analyzer available for Lucene.NET. I see there has
> > been
> > > one contributed to the Java project but wasn't sure if this has been
> > ported.
> > >
> > > Thanks,
> > >
> > > Ben
> >
>
>
>
> --
>
> Ben Foster
>
> planetcloud
> The Elms, Hawton
> Newark-on-Trent
> Nottinghamshire
> NG24 3RL
>
> www.planetcloud.co.uk
> 

FW: Umlauts as Char

[Prescott Nasser]

Alex...thanks Alex. Sorry, not sure why Aaron was in my head.
 
~P






> From: geobmx...@hotmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Umlauts as Char
> Date: Mon, 7 Feb 2011 21:06:55 -0800
>
>
> Stefan somewhat nailed it on the head. My concerns where the java characters 
> - I can't even search google or bing for them. So I can take the source codes 
> word that 'ü' is the u with dots over it (becuase it says replace umlauts in 
> the source notes). But, I guess, is that really true? Is that perhaps u with 
> a carrot over it instead?
>
> I'm tempted to take the source at it's word and just replace them with the 
> umlauts versions (via character map -thanks Aaron), and then make some 
> comment expressing what originally it was in the java source.
>
> What are your guy's thoughts?
>
> ~P
>
>
>
>
>
>
>
> 
> > From: bode...@apache.org
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: Umlauts as Char
> > Date: Tue, 8 Feb 2011 06:01:27 +0100
> >
> > On 2011-02-08, Nicholas Paldino [.NET/C# MVP] wrote:
> >
> > > You can simply use the Unicode escape sequence in code and in
> > > string/character literals, as specified by section 2.4.2 of the C# spec
> > > (http://msdn.microsoft.com/en-us/library/aa664670(v=vs.71).aspx):
> >
> > I think in Prescott's case part of the problem is that he doesn't know
> > which character the sequence seems to be. In this case it likely is an
> > ü.
> >
> > > else if ( buffer.charAt( c ) == 'ü' ) {
> > > buffer.setCharAt( c, 'u' );
> > > }
> >
> > > Would become:
> >
> > > else if ( buffer.charAt( c ) == '\u00C3¼' ) {
> > > buffer.setCharAt( c, 'u' );
> > > }
> >
> > No. The two bytes are part of a two byte UTF-8 sequence making up a
> > single character.
> >
> > Stefan

RE: Umlauts as Char

[Prescott Nasser]

Stefan somewhat nailed it on the head. My concerns where the java characters - 
I can't even search google or bing for them. So I can take the source codes 
word that 'ü' is the u with dots over it (becuase it says replace umlauts in 
the source notes). But, I guess, is that really true? Is that perhaps u with a 
carrot over it instead?
 
I'm tempted to take the source at it's word and just replace them with the 
umlauts versions (via character map -thanks Aaron), and then make some comment 
expressing what originally it was in the java source.
 
What are your guy's thoughts?
 
~P
 







> From: bode...@apache.org
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Umlauts as Char
> Date: Tue, 8 Feb 2011 06:01:27 +0100
>
> On 2011-02-08, Nicholas Paldino [.NET/C# MVP] wrote:
>
> > You can simply use the Unicode escape sequence in code and in
> > string/character literals, as specified by section 2.4.2 of the C# spec
> > (http://msdn.microsoft.com/en-us/library/aa664670(v=vs.71).aspx):
>
> I think in Prescott's case part of the problem is that he doesn't know
> which character the sequence seems to be. In this case it likely is an
> ü.
>
> > else if ( buffer.charAt( c ) == 'ü' ) {
> > buffer.setCharAt( c, 'u' );
> > }
>
> > Would become:
>
> > else if ( buffer.charAt( c ) == '\u00C3¼' ) {
> > buffer.setCharAt( c, 'u' );
> > }
>
> No. The two bytes are part of a two byte UTF-8 sequence making up a
> single character.
>
> Stefan  

RE: Umlauts as Char

[Prescott Nasser]

I'm not sure why I didn't think about it - but there are tons of online 
converters...copy and paste ftw.
 
I think the dealing with other character sets is new to me and complicated this 
more than it needed to be.
 
Thanks guys,
~P






> From: bode...@apache.org
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Umlauts as Char
> Date: Tue, 8 Feb 2011 06:09:58 +0100
>
> On 2011-02-08, Prescott Nasser wrote:
>
> > in the void subsitute function you'll see them:
>
> > else if ( buffer.charAt( c ) == 'ü' ) {
> > buffer.setCharAt( c, 'u' );
> > }
>
> > This does not constitue a character in .net (that I can figure out)
> > and thus it doesn't compile. The .java file says encoded in UTF-8. I
> > was thinking maybe I could do the same thing in VS2010, but I'm not
> > finding a way, and searching on this has been difficult.
>
> IIRC VS will recognize UTF-8 encoded files if they start with a byte
> order mark (BOM) but Java usually doesn't write one. I think I once
> found the setting for reading/writing UTF-8 in VS, will need to search
> for it when at work.
>
> If you have a JDK installed you can use its native2ascii tool that can
> be used to replace non-ASCII characters with Unicoce escape sequences
> that you can then use in C# as well (see Nicolas' post).
>
> If you have Ant installed (sorry, can't resist ;-) you can convert the
> whole tree in one (untested) go with something like
>
> > encoding="utf8">
> 
> 
> 
>
> Stefan  

RE: Umlauts as Char

[Prescott Nasser]

Well - with regards to number 2. It was fine to dig into the code a bit - but I 
guess we have them a number of them already converted, although I guess never 
added source control.
 
Thanks for the heads up on 1 and 3.
 
~P






> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Umlauts as Char
> Date: Tue, 8 Feb 2011 11:12:33 +0200
>
> Hi Prescott,
>
> 1- When I open the java file, I see the code as it should be. You can try to
> open it with notepad and then paste to VS for ex.
> 2- There is an open issue reported by Pasha Bizhan that covers some
> languages (https://issues.apache.org/jira/browse/LUCENENET-372)
> But I don't know it us up to date or not.
> 3- ASCIIFoldingFilter.cs is another example for dealing with non-ascii
> chars.
>
> DIGY
>
> -Original Message-
> From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> Sent: Tuesday, February 08, 2011 3:55 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: Umlauts as Char
>
>
>
> Hey all,
>
> So while digging into the code a bit (and pushed by digy's Arabic conversion
> yesterday). I started looking at the various other languages we were missing
> from java.
>
> I started porting the GermanAnalyzer, but ran into an issue of the
> Umlauts...
>
> http://svn.apache.org/viewvc/lucene/java/tags/lucene_2_9_4/contrib/analyzers
> /common/src/java/org/apache/lucene/analysis/de/GermanStemmer.java?revision=1
> 040993&view=co
>
> in the void subsitute function you'll see them:
>
> else if ( buffer.charAt( c ) == 'ü' ) {
> buffer.setCharAt( c, 'u' );
> }
>
> This does not constitue a character in .net (that I can figure out) and thus
> it doesn't compile. The .java file says encoded in UTF-8. I was thinking
> maybe I could do the same thing in VS2010, but I'm not finding a way, and
> searching on this has been difficult.
>
> Any ideas?
>
> ~Prescott =
> 

RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer

[Prescott Nasser]

 
Would it make sense to also commit the analyzers that Prasha converted and 
submitted here:
 
https://issues.apache.org/jira/browse/LUCENENET-372

 
~P


> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [jira] Commented: (LUCENENET-392) Arabic Analyzer
> Date: Thu, 10 Feb 2011 12:33:37 +0200
> 
> Hi Stefan,
> 
> I don't see it as a "request for permission". It is rather to inform people
> about the change who may have different ideas and give a chance to comment
> on it if this change breaks something in their own local copy.
> 
> DIGY
> 
> 
> 
> 
> 
> -Original Message-
> From: Stefan Bodewig [mailto:bode...@apache.org] 
> Sent: Thursday, February 10, 2011 12:10 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [jira] Commented: (LUCENENET-392) Arabic Analyzer
> 
> On 2011-02-08, Digy (JIRA) wrote:
> 
> > Digy commented on LUCENENET-392:
> > 
> 
> > If no objections, I am going to commit it in a few days.
> 
> Generally in a healthy project it is way easier to ask for forgiveness
> than for permission[1]. It is all under version control so things can
> be changed and even removed again easily when anything goes wrong.
> 
> I hope anybody who'd be interested is subscribed to the commits list and
> will see the changes and can comment on them later.
> 
> Cheers
> 
> Stefan
> 
> [1] A lesson I had to learn myself
> 
> 

RE: Old website redirects?

[Prescott Nasser]

Just curious...
 
The file is here : 
https://svn.apache.org/repos/asf/lucene/site/publish/.htaccess
 
I don't have the ability to update it. Once I get commit status would that 
allow me to update it? or does someone else need to fix it? I feel like my 
committer status wouldn't affect this repo
 
I think we want to append (similar to Lucy):
 
# Lucene.Net has moved to the incubator, 
# site strcuture has changed, do don't use $1 in redirect...
RedirectMatch Permanent ^/lucene.net/(.*)$ 
http://incubator.apache.org/lucene.net

It's not likely our site structure will have changed that much, but I figure 
better safe than sorry.
 
~P



> From: bode...@apache.org
> To: lucene-net-dev@lucene.apache.org
> Subject: Old website redirects?
> Date: Sat, 12 Feb 2011 08:13:04 +0100
>
> Hi,
>
> when I visit I still get to see
> the "old" Lucene.NET page. Wouldn't it be better if it redirected to
> the Incubator site?
>
> A simple .htacess file at lucene.apache.org with something like
>
> RedirectPermanent /lucene.net http://incubator.apache.org/lucene.net
>
> would probably do.
>
> Stefan  

Sharpen setup

[Prescott Nasser]

Hey all,
 
I'm looking for some help setting up sharpen. I haven't done java development 
in probably close to 8 years and my tooling knowledge is incredibly out of date.
 
I grabbed Eclipse IDE for Java Developers (Version: Helios Service Release 1
Build id: 20100917-0705) and was looking at documentation for sharpen 
(http://developer.db4o.com/Documentation/Reference/db4o-7.12/java/reference/html/Content/sharpen/how_to_setup_sharpen.html)
 and 
(http://developer.db4o.com/Blogs/Product/tabid/167/entryid/95/Default.aspx). 
 
Following the first link, I pulled down the latest sharpen from their 
repository, and then imported the project. It then says to export as a Plug-in 
- but I don't have that option. Also, eclipse is giving me errors about 
org.eclipse not being found.
 
Following the second link, it says to add a new project -> from CVS. However, 
ecplise won't even retrieve the packages from their repo. I've tried all the 
options (ext, extssh, pserver, pserverssh) and I get login errors from the 
later 3, an a general ext error when selecting that option.
 
Does anyone have experience setting this up?
 
~Prescott 

RE: Confluence Wiki is there

[Prescott Nasser]

Hey Stefan, 
 
Can you please give me access to the cwiki
 
Username: PrescottNasser
 
Thanks,
~Prescott






> From: bode...@apache.org
> To: lucene-net-dev@lucene.apache.org
> Subject: Confluence Wiki is there
> Date: Sun, 13 Feb 2011 08:01:14 +0100
>
> Hi,
>
> the Wiki instance can be reached at
> . Michael,
> Benson and myself are admins and can grant people access to the pages as
> needed.
>
> AFAIU there will be a static export of the pages to
> once there is actual content (I may
> be wrong and we need to tweak some settings to make it happen).
>
> Anyway, the two pages of the old wiki could now be moved over.
>
> Stefan  

RE: Confluence Wiki is there

[Prescott Nasser]

Good to go, thanks
 
~P






> Date: Sun, 13 Feb 2011 18:11:25 -0500
> Subject: Re: Confluence Wiki is there
> From: mhern...@o19s.com
> To: lucene-net-dev@lucene.apache.org
>
> try logging into the lucene.net space and see if you can now do editing and
> such.   

RE: Sharpen setup

[Prescott Nasser]

Thanks Alex - that was extremely helpful to get me started.
 
~P





> From: pierogi...@hotmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: Sharpen setup
> Date: Sun, 13 Feb 2011 16:35:25 -0800
>
> I'm using Eclipse 3.4.2 (ganymede-SR2) for Java EE. You need a Java EE
> edition to build plugins. I haven't tried the Helios versions.
>
> The repository is SVN not CVS so you need an SVN plugin (regular windows
> TortoiseSVN had some problems). I use Subclipse http://subclipse.tigris.org/
> and that gives you the option new project -> from SVN
>
> Then you can export as a Plug-in and put the resulting jars in the /plugins
> folder under eclipse.
>
> Next you checkout a version of java lucene (again with subclipse) and you
> will need to setup the .project and .classpath files correctly. Here is a
> copy of mine for reference:
> .project
> 
> 
> lucene_3_0_3
> 
> 
> 
> 
> 
> org.eclipse.jdt.core.javabuilder
> 
> 
> 
> 
> sharpen.builder.sharpenBuilder
> 
> 
> 
> 
> 
> org.eclipse.jdt.core.javanature
> sharpen.builder.sharpenNature
> 
> 
>
> .classpath
> 
> 
> 
> 
> 
> > path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
> 
> 
> 
> 
>
> I use Ant to run sharpen and you can find my Ant scripts as well as the
> patches I made for sharpen and preprocessing in my last uploaded package
> here:
> https://issues.apache.org/jira/browse/LUCENENET-380
>
> Alex
>
> -Original Message-
> From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> Sent: Sunday, February 13, 2011 2:12 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: Sharpen setup
>
>
> Hey all,
>
> I'm looking for some help setting up sharpen. I haven't done java
> development in probably close to 8 years and my tooling knowledge is
> incredibly out of date.
>
> I grabbed Eclipse IDE for Java Developers (Version: Helios Service Release 1
> Build id: 20100917-0705) and was looking at documentation for sharpen
> (http://developer.db4o.com/Documentation/Reference/db4o-7.12/java/reference/
> html/Content/sharpen/how_to_setup_sharpen.html) and
> (http://developer.db4o.com/Blogs/Product/tabid/167/entryid/95/Default.aspx).
>
>
> Following the first link, I pulled down the latest sharpen from their
> repository, and then imported the project. It then says to export as a
> Plug-in - but I don't have that option. Also, eclipse is giving me errors
> about org.eclipse not being found.
>
> Following the second link, it says to add a new project -> from CVS.
> However, ecplise won't even retrieve the packages from their repo. I've
> tried all the options (ext, extssh, pserver, pserverssh) and I get login
> errors from the later 3, an a general ext error when selecting that option.
>
> Does anyone have experience setting this up?
>
> ~Prescott
> 

RE: Lucene.Net JIRA

[Prescott Nasser]

I took a look at them - they seem to fall into 3 categories:

1. things we need to go to get up to par (website update, releases, vs2010 
upgrade, signing)
2. bug fixes - ideally these we fix
3. .Net specific things - these are part of our larger goal
 
I think these all fall into the roadmap - perhaps a bit loosely at times, but I 
think they all fall in.
 
We should probably start talking about who might be working on what pieces so 
we know where me might need to allocate resoures

~P




> From: slomb...@kingindustries.com
> To: lucene-net-dev@lucene.apache.org
> Date: Fri, 18 Feb 2011 00:44:02 -0500
> Subject: Lucene.Net JIRA
>
> What is the best way to organize the JIRA? It seems to me that there are a 
> lot of great ideas in the 20 open action items. How do we fit them into the 
> roadmap that was defined incubation proposal?
>
>
> Scott
>
>
> 
>
> This message (and any associated files) is intended only for the
> use of the individual or entity to which it is addressed and may
> contain information that is confidential, subject to copyright or
> constitutes a trade secret. If you are not the intended recipient
> you are hereby notified that any dissemination, copying or
> distribution of this message, or files associated with this message,
> is strictly prohibited. If you have received this message in error,
> please notify us immediately by replying to the message and deleting
> it from your computer. Thank you, King Industries, Inc.   
>   

RE: Proposed Roadmap

[Prescott Nasser]

Do you imagine us doing all the "catching up on backlog" by hand? And then 
later getting the automated conversion out?




> From: thowar...@gmail.com
> Date: Fri, 18 Feb 2011 01:36:00 -0800
> Subject: Proposed Roadmap
> To: lucene-net-dev@lucene.apache.org
>
> All,
>
> Following up on Scott's post asking about JIRA issues and our
> development road map, I've put together a more detailed idea of how
> we could divide work, schedule releases, and clean up the backlog.
>
> There will be at least four main areas of work to address in the
> upcoming months:
> - Project Maintenance
> - Catching up with the backlog
> - Working on a new porting system
> - The Future: New API and Lucene 3.X
>
> Each one of those paths will need a separate road map and plan. In
> JIRA these should probably be listed as separate components, along
> with more structural components like Lucene.Net Core, Lucene.Net
> Contrib, Luke.Net, etc...
>
> Assuming we are working on these in parallel, I've included some
> rough estimate dates for completion of each listed milestone in
> the road maps.
>
>
> Project Maintenance
> ==
>
> This includes the various aspects of transition from Lucene
> subproject to Incubator Podling, as well as updating the website
> and documenation.
>
>
> Roadmap
>
> * Website and branding Update (02/28/2011)
> - LUCENENET-379 - Clean up Lucene.Net website
> * NOTE: Should probably be split into a few separate issues:
> * Update website to be Apache CMS based
> * Update website to reflect current status and information
> * New site layout
> * New logo design
>
> * Documentation Update (03/28/2011)
> - LUCENENET-382 - Create a wiki page for Lucene.Net
> * NOTE: This should probably have more detailed tasks defined
> and separately assigned / managed. This should focus on 2.9.2
> level code, examples, etc, plus FAQ, Design, and other
> similar documentation.
>
>
> Catching up with the Backlog
> ==
>
> This includes finalizing the 2.9.2 release, updating that to
> Lucene 2.9.4 compatibility and applying outstanding patches and
> bug fixes. This will put is slightly out of sync with Java Lucene
> because we'll have additional patches applied that the Java Lucene
> project does not have for our 2.9.4 release.
>
>
> Roadmap
>
> * Lucene.Net 2.9.2 Binary release (02/28/2011)
> - LUCENENET-381 - Official release of Lucene.Net 2.9.2
> * Build from existing tag, no new changes
>
> * Lucene.Net 2.9.4 Source/Binary release (03/28/2011)
>
> *EASY STUFF*
> - LUCENENET-389 - Signing the released assembly
> - LUCENENET-377 - Upgrade solution to VS2010
> - LUCENENET-361 - Workaround for a Mono C# compiler issue
> - LUCENENET-266 - Putting support classes in separate files and
> in a separate directory
> - LUCENENET-337 - TokenAttribute for Selectively Including Tokens
> in Length Norm
> - LUCENENET-330 - Search.Regex minimal port
> - LUCENENET-371 - Unit test for Search.Regex port
> - LUCENENET-374 - IndexReader.IsCurrent returning false
> positive in some cases
> - LUCENENET-179 - SnowballFilter speed improvment
>
> *HARDER STUFF*
> - LUCENENET-??? Rollup changes from Lucene 2.9.3/2.9.4 releases
> - LUCENENET-372 - NLS pack for Lucene.NET: BR, CJK, CN, CZ, DE,
> FR, NL, RU analyzers
> * NOTE: For v1.4 This code could be a starting point for a
> 2.9.2 compatible version
> - LUCENENET-391 - Luke.Net for Lucene.Net
> * NOTE: For v1.4 This code could be a starting point for a
> 2.9.2 compatible version
> - LUCENENET-172 - This patch fixes the unexceptional exceptions
> ecountered in FastCharStream and SupportClass
> * NOTE: Evaluate concerns expressed by George A. for this patch
> - LUCENENET-167 - Compact Framework & Silverlight Support
> * NOTE: Evaluate required steps and impact this will have on
> source code. Perhaps create a branch for CF/SilverLight.
> - LUCENENET-378 - Objects with a Close method should support
> IDisposable
> * NOTE: Significant diversion from Java, involves a lot of
> code-touch. Maybe take some ideas from and/or incorporate
> changes from various CodeProject forks?
>
>
> Working on a New Porting System
> ==
>
> We've discussed that we'd like to fully automate this process and
> so far, the most obvious tool to use is Sharpen. This may involve
> forking Sharpen (or contributing back to that project if
> appropriate). We also discussed we'd like a to set up a CI server
> for this work (and other things).
>
> * Evaluate tooling (02/28/2011)
> - LUCENENET-380 - Evaluate Sharpen as a port tool
> * NOTE: We should conclusively complete the evaluation and if
> we're ok with Sharpen, close this issue and move on to building
> a production version of the Sharpen code.
>
> - LUCENENET-??? - Evalute CI systems and build a proposal for
> CI server setup
>
> * Create Production System, 2.9.2 compatible (03/28/2011)
> - LUCENENET-??? - Create production version of automated port
> scri

RE: Bug Fixes for Lucene.Net versions before 2.9.2

[Prescott Nasser]

Unless they affect current release, I think we need to let them be. Once we get 
to 2.9.5 we should probably continue to support that with bug fixes for quite a 
while, but at some point that too should fall off our list.

~Prescott




> From: slomb...@kingindustries.com
> To: lucene-net-dev@lucene.apache.org
> Date: Sat, 19 Feb 2011 00:41:33 -0500
> Subject: Bug Fixes for Lucene.Net versions before 2.9.2
>
> What is the group's feeling on bug fixes on problems found in versions before 
> 2.9.2?
>
>
>
> Scott
>
>
> 
>
> This message (and any associated files) is intended only for the
> use of the individual or entity to which it is addressed and may
> contain information that is confidential, subject to copyright or
> constitutes a trade secret. If you are not the intended recipient
> you are hereby notified that any dissemination, copying or
> distribution of this message, or files associated with this message,
> is strictly prohibited. If you have received this message in error,
> please notify us immediately by replying to the message and deleting
> it from your computer. Thank you, King Industries, Inc.   
>   

RE: Index AutoCAD files

[Prescott Nasser]

If you can extract text from them, then it shouldn't be a problem.
 
Lucene doesn't do the job of extracting the text. For that you'd have to find 
something else.






> Date: Sat, 19 Feb 2011 13:03:00 +0530
> Subject: Index AutoCAD files
> From: luc...@greatminds.co.in
> To: lucene-net-dev@lucene.apache.org
>
> Hi team,
>
> Is there a way lucene.Net can index AutoCAD files – “*.dwg” files?
>
> If so, please let me know.
>
> Can you please provide some insight on the same?
>
>
>
> Thanks in advance..
>
>
>
> Regards
>
> Vignesh 

RE: [Lucene.Net] Lucene.Net Tasks due by 2/28

[Prescott Nasser]

I'm out of town this weekend, but I'm hoping to get one or two designs (likely 
just screenshots) attached to the JIRA so people can give me some feedback. 
I'll make it quick turn around and won't leave it open for feedback long 
though. If anyone has ideas / thoughts, samples they like, comment on the JIRA 
for the website stuff.
 
I spoke with Troy this evening and it's likely after we get the logo contest 
completed we'd redesign to fit the logo better - so I'm not too worried about 
what this first iteration looks like.
 
Also, I am not a designer ;)
 
~P








> From: thowar...@gmail.com
> Date: Wed, 23 Feb 2011 00:32:03 -0800
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] Lucene.Net Tasks due by 2/28
>
> All,
>
> I've recently been updating JIRA a lot and that's causing a lot of
> noise on the dev list. Also, because of that noise, I fear that some
> of the more important details of those changes might be passing by
> unnoticed.
>
> Mostly, I'm trying to get the project cleaned up by the end of the
> month. The goal is that March will represent a month of building out
> our new infrastructure and creating our first new release as a team
> (2.9.4). To that end, I'd like to resolve some of the outstanding
> questions about tooling so we can get started building out solutions
> with those tools. Also, I'd like to see our new status and efforts
> announced publicly, but I'm hesitant to draw much attention to the
> project until the website is updated.
>
> Additionally, I'd like to take a moment to apologize a bit for moving
> at such a rapid pace. I realize this is not sustainable and could
> cause some people to feel alienated if they don't have the time or
> energy right this second to match that pace. I also feel a bit
> self-conscious and am concerned that I'm being a little to much 'me',
> and perhaps not enough 'we'.
>
> I have been taking a lot of liberty regarding the project direction,
> bypassing some opportunities for community discussion and voting, in
> the interests of pushing the project forward and catching up a bit of
> lost time. Once we get past this initial push, I hope that we can slow
> down a bit, and maintain a healthy forward-moving pace with plenty of
> time allotted for discussion, group decision making and voting. The
> Apache Way is the way this project will succeed and thrive, and that
> requires all of us.
>
>
> So, that said, the outstanding tasks, which we can hopefully complete
> by next Monday are:
>
> Troy Howard:
> LUCENENET-381 - Official release of Lucene.Net 2.9.2
>
> Sergey Mirvoda:
> LUCENENET-398 - LUCENENET-391 Prepare the code for ingestion
>
> Michael Herndon:
> LUCENENET-400 - Evaluate tooling for continuous integration server
>
> Prescott Nasser:
> LUCENENET-379 - Clean up Lucene.Net website
> LUCENENET-379 / LUCENENET-403 - Improve site layout and design
> LUCENENET-379 / LUCENENET-402 - Update website to reflect current
> status and information
> LUCENENET-379 / LUCENENET-401 - Update website to be Apache CMS based
>
> Alex Thompson:
> LUCENENET-380 - Evaluate Sharpen as a port tool
>
> Does anyone feel less than confident about being able to complete
> those tasks on that schedule? Need any help? Want to change
> assignments?
>
> Anyone in the community want to get involved as a contributor on any
> of these tasks (or any of the open tasks in JIRA that are not listed
> here)? Sergey could probably use some help on Luke.Net. Prescott has a
> lot of work cut out for him on the website. Perhaps we should get the
> ball rolling on 2.9.4 task assignments for everyone else?
>
> Thanks,
> Troy

[Lucene.Net] [VOTE] New website / layout looks

[Prescott Nasser]

Hey all,
 
I've uploaded two potential new layouts / site designs: 
https://issues.apache.org/jira/browse/LUCENENET-403. 
 
Troy has also hosted them live in his people.apache.org account:
 
http://people.apache.org/~thoward/Lucene.Net/site/layout1/
http://people.apache.org/~thoward/Lucene.Net/site/layout2/
 
 
Please reply and specify: Layout1 or Layout2. 
 
To you want to throw your hat in the ring, upload a zip to the JIRA above and 
cast your vote for that. 
 
I'm out of town for the weekend, so Vote closes Tuesday @ 12PM PST (roughly 5 
days from now)
 
 
Thanks,
~Prescott 

RE: [Lucene.Net] [VOTE] New website / layout looks

[Prescott Nasser]

Oh, also, +1 for Layout1

~Prescott






> From: geobmx...@hotmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Fri, 25 Feb 2011 18:03:35 -0800
> Subject: [Lucene.Net] [VOTE] New website / layout looks
>
>
> Hey all,
>
> I've uploaded two potential new layouts / site designs: 
> https://issues.apache.org/jira/browse/LUCENENET-403.
>
> Troy has also hosted them live in his people.apache.org account:
>
> http://people.apache.org/~thoward/Lucene.Net/site/layout1/
> http://people.apache.org/~thoward/Lucene.Net/site/layout2/
>
>
> Please reply and specify: Layout1 or Layout2.
>
> To you want to throw your hat in the ring, upload a zip to the JIRA above and 
> cast your vote for that.
>
> I'm out of town for the weekend, so Vote closes Tuesday @ 12PM PST (roughly 5 
> days from now)
>
>
> Thanks,
> ~Prescott   

RE: [Lucene.Net] [VOTE] Release Apache Lucene.Net 2.9.2-incubating-RC2

[Prescott Nasser]

+1
>
> +1
>
> On Mon, Feb 28, 2011 at 2:44 PM, digy digy wrote:
>
> > +1
> > DIGY
> >
> > On Mon, Feb 28, 2011 at 11:04 AM, Glyn Darkin > > >wrote:
> >
> > > +1
> > > On 28 Feb 2011, at 08:39, Troy Howard wrote:
> > >
> > > > All,
> > > >
> > > > A quick voting reminder... This [VOTE] thread will only be active for
> > > > another 4 hours (72 hours total).
> > > >
> > > > So far, we have two +1 votes in.
> > > >
> > > > After this vote, the release will be proposed to the Incubator PMC,
> > > > and will have another 72 hour vote for acceptance there. Assuming that
> > > > passes, it will become an official ASF Incubator release.
> > > >
> > > > Thanks,
> > > > Troy
> > > >
> > > >
> > > > On Fri, Feb 25, 2011 at 12:29 PM, Stefan Bodewig 
> > > wrote:
> > > >> On 2011-02-25, Troy Howard wrote:
> > > >>
> > > >>> I updated the .src zip and associated checksums/signatures at:
> > > >>
> > > >> I have verified the bin zip is still the same that I checked. All
> > > >> signatures and hashes are fine, RAT is reasonably happy with the src
> > zip
> > > >> (I've updated
> > > >> ).
> > > >>
> > > >> +1 from me for the release. Of course I haven't perfromed any
> > technical
> > > >> tests, just verified the artifacts meet the Incubator requirements (at
> > > >> least all I know of).
> > > >>
> > > >>> Hopefully this one will pass the licensing validation! I think I got
> > > >>> them all this time..
> > > >>
> > > >> Thanks a lot.
> > > >>
> > > >> Stefan
> > > >>
> > >
> > > Glyn Darkin
> > >
> > > Darkin Systems Ltd
> > > Mob: 07961815649
> > > Fax: 08717145065
> > > Web: www.darkinsystems.com
> > >
> > > Company No: 6173001
> > > VAT No: 906350835
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> --Regards, Sergey Mirvoda   

RE: [Lucene.Net] [VOTE] New website / layout looks

[Prescott Nasser]

Alright, finally back in town. Looks like Layout 1 is the winner - I'll work on 
cutting that up and putting it into the new CMS over the next week.

There were two comments, one regarding the yellow box being active from the 
page load - I'll make that change. The second regarding the images. I'm at my 
limit with image work - if there is anyone who could clean those up and work on 
the color balance? I know the arrows are difficult to see, and the box isn't 
that rounded. Ideally if the dimensions could be the same that would be 
extremely helpful.
 
Thanks guys,
 
~Prescott






> From: m...@aaron-powell.com
> To: lucene-net-dev@lucene.apache.org
> Date: Sat, 26 Feb 2011 20:16:51 +
> Subject: RE: [Lucene.Net] [VOTE] New website / layout looks
>
> +1 for Layout 01
>
> Aaron Powell
> Umbraco Core Team Member | FunnelWeb Team Member
>
> http://www.aaron-powell.com | http://twitter.com/slace | Skype: 
> aaron.l.powell | MSN: aaz...@hotmail.com
>
> -Original Message-
> From: Digy [mailto:digyd...@gmail.com]
> Sent: Saturday, 26 February 2011 10:42 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [Lucene.Net] [VOTE] New website / layout looks
>
> +1 for Layout1
> DIGY
>
> -Original Message-
> From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> Sent: Saturday, February 26, 2011 4:04 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] [VOTE] New website / layout looks
>
>
> Hey all,
>
> I've uploaded two potential new layouts / site designs:
> https://issues.apache.org/jira/browse/LUCENENET-403.
>
> Troy has also hosted them live in his people.apache.org account:
>
> http://people.apache.org/~thoward/Lucene.Net/site/layout1/
> http://people.apache.org/~thoward/Lucene.Net/site/layout2/
>
>
> Please reply and specify: Layout1 or Layout2.
>
> To you want to throw your hat in the ring, upload a zip to the JIRA above
> and cast your vote for that.
>
> I'm out of town for the weekend, so Vote closes Tuesday @ 12PM PST (roughly
> 5 days from now)
>
>
> Thanks,
> ~Prescott =
> 

RE: [Lucene.Net] [VOTE] New website / layout looks

[Prescott Nasser]

Yeah, that should be no problem. I likely won't have it cut up and into the ASF 
CMS template until then anyway. And, even if images come later, we can always 
go with what we have until that time.
 
Thanks for the help,
 
~P






> Date: Wed, 2 Mar 2011 12:48:47 -0500
> From: mhern...@o19s.com
> To: lucene-net-dev@lucene.apache.org
> CC: geobmx...@hotmail.com
> Subject: Re: [Lucene.Net] [VOTE] New website / layout looks
>
> If it can wait till this weekend for the cleaned up images, I can clean up
> the images then.
>
> On Tue, Mar 1, 2011 at 11:23 PM, Prescott Nasser wrote:
>
> >
> > Alright, finally back in town. Looks like Layout 1 is the winner - I'll
> > work on cutting that up and putting it into the new CMS over the next week.
> >
> > There were two comments, one regarding the yellow box being active from the
> > page load - I'll make that change. The second regarding the images. I'm at
> > my limit with image work - if there is anyone who could clean those up and
> > work on the color balance? I know the arrows are difficult to see, and the
> > box isn't that rounded. Ideally if the dimensions could be the same that
> > would be extremely helpful.
> >
> > Thanks guys,
> >
> > ~Prescott
> >
> >
> >
> >
> >
> > 
> > > From: m...@aaron-powell.com
> > > To: lucene-net-dev@lucene.apache.org
> > > Date: Sat, 26 Feb 2011 20:16:51 +
> > > Subject: RE: [Lucene.Net] [VOTE] New website / layout looks
> > >
> > > +1 for Layout 01
> > >
> > > Aaron Powell
> > > Umbraco Core Team Member | FunnelWeb Team Member
> > >
> > > http://www.aaron-powell.com | http://twitter.com/slace | Skype:
> > aaron.l.powell | MSN: aaz...@hotmail.com
> > >
> > > -Original Message-
> > > From: Digy [mailto:digyd...@gmail.com]
> > > Sent: Saturday, 26 February 2011 10:42 PM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: RE: [Lucene.Net] [VOTE] New website / layout looks
> > >
> > > +1 for Layout1
> > > DIGY
> > >
> > > -Original Message-
> > > From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> > > Sent: Saturday, February 26, 2011 4:04 AM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: [Lucene.Net] [VOTE] New website / layout looks
> > >
> > >
> > > Hey all,
> > >
> > > I've uploaded two potential new layouts / site designs:
> > > https://issues.apache.org/jira/browse/LUCENENET-403.
> > >
> > > Troy has also hosted them live in his people.apache.org account:
> > >
> > > http://people.apache.org/~thoward/Lucene.Net/site/layout1/
> > > http://people.apache.org/~thoward/Lucene.Net/site/layout2/
> > >
> > >
> > > Please reply and specify: Layout1 or Layout2.
> > >
> > > To you want to throw your hat in the ring, upload a zip to the JIRA above
> > > and cast your vote for that.
> > >
> > > I'm out of town for the weekend, so Vote closes Tuesday @ 12PM PST
> > (roughly
> > > 5 days from now)
> > >
> > >
> > > Thanks,
> > > ~Prescott =
> > >
> >
>
>
>
> --
> Michael Herndon
> Senior Developer (mhern...@o19s.com)
> 804.767.0083
>
> [connect online]
> http://www.opensourceconnections.com
> http://www.amptools.net
> http://www.linkedin.com/pub/michael-herndon/4/893/23
> http://www.facebook.com/amptools.net
> http://www.twitter.com/amptools-net 

RE: [Lucene.Net] Knockree Apache Retreat

[Prescott Nasser]

That would be sweeet! Pretty unlikely though :(






> From: thowar...@gmail.com
> Date: Wed, 2 Mar 2011 23:12:25 -0800
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] Knockree Apache Retreat
>
> I went ahead and applied for travel assistance.
>
>
>
> On Wed, Mar 2, 2011 at 10:12 PM, Troy Howard wrote:
> > This sounds like a great opportunity.
> >
> > However airfare, roundtrip from Portland, OR is ~$900; A little
> > expensive. So, I'm a solid 'maybe'.
> >
> > Thanks,
> > Troy
> >
> >
> > On Wed, Mar 2, 2011 at 9:19 PM, Stefan Bodewig wrote:
> >> Hi all,
> >>
> >> I think most people around here are US based, but is anybody going to
> >> Knockree in May?
> >>
> >> 
> >>
> >> Stefan
> >>
> >   

RE: [Lucene.Net] [VOTE] Fork Sharpen

[Prescott Nasser]

+1 great name. I agree, we will probably need to make changes that are not 
generic enough for them.
 
 
 
 
> Date: Fri, 4 Mar 2011 00:54:17 -0800
> Subject: [Lucene.Net] [VOTE] Fork Sharpen
>
> Hey All,
>
> The discussion on Sharpen or other porting tools has been quiet so I think
> its time for a vote. Background info here:
> https://issues.apache.org/jira/browse/LUCENENET-380
>
> I propose forking Sharpen outside of ASF for use in our conversion and any
> other java project.
>
> The company that created Sharpen (db4o) could accept patches however I fear
> that the scope of our changes will be large enough that our goals will not
> align with db4o's and using their trunk would be a burden. Also hopefully
> the fork project could attract more attention and contributions than the
> current obscure repository.
>
> Vote will be open for 72 hours.
> Suggestions on where to host the fork and name for the fork encouraged.
>
> My name pick: Grindstone
> (as in what you use to sharpen)
>
> Thanks,
> Alex
> 

[Lucene.Net] help with a couple of resources

[Prescott Nasser]

Hey guys, 
 
I'm trying to update the website. But I'm having some trouble with a few items.
 
1. Do we have a binary release? (if so where?)
2. I thought I saw a roadmap document of some kind, but I'm having trouble 
finding it.
 
Thanks,
~P

RE: [Lucene.Net] help with a couple of resources

[Prescott Nasser]

Thanks!
 
~P






> From: thowar...@gmail.com
> Date: Sun, 6 Mar 2011 18:14:48 -0800
> To: lucene-net-dev@lucene.apache.org
> CC: geobmx...@hotmail.com
> Subject: Re: [Lucene.Net] help with a couple of resources
>
> Prescott,
>
> I started a thread called 'Proposed Roadmap' a while back. It's here:
>
> http://s.apache.org/9Ov
>
> We just finished a new official release, and I will be announcing it
> either today or tomorrow (I was waiting for the mirror sites to get
> updated before announcing it). It's located here:
>
> http://www.apache.org/dist/incubator/lucene.net/
>
> Thanks,
> Troy
>
> On Sun, Mar 6, 2011 at 4:09 PM, Prescott Nasser wrote:
> >
> >
> > Hey guys,
> >
> > I'm trying to update the website. But I'm having some trouble with a few 
> > items.
> >
> > 1. Do we have a binary release? (if so where?)
> > 2. I thought I saw a roadmap document of some kind, but I'm having trouble 
> > finding it.
> >
> > Thanks,
> > ~P

RE: [Lucene.Net] [jira] Resolved: (LUCENENET-403) Improve site layout and design

[Prescott Nasser]

Chris - I agree. I ripped off bitbutcket like mad. The idea was to get 
something up there quickly with the logo Troy put together. My understanding 
was that once we had a logo from the contest that Troy is working with SO on, 
that we would redesign the site to work well with that logo. 
 
This was put together rather quickly and really I'm using it to learn how the 
ASF CMS works. I'll be refactoring it a bit to get common elements out of it, 
etc.
 
Feel free to make changes - I'm not married to anything, and I don't think 
everyone else is. We just needed something up and running.
 
~P






> Date: Mon, 7 Mar 2011 09:49:11 -0800
> From: currens.ch...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] [jira] Resolved: (LUCENENET-403) Improve site 
> layout and design
>
> The site does look great, I only have one concern and that is that is seems
> we used bitbucket.org as our sole design inspiration. I'm concerned that it
> looks *too* much like the bitbucket site and that may cause problems in the
> future. I don't like having words and not backing it up without any
> actions, so I would like to add to the design if that's alright with
> everyone, I don't have anything now, but I can get something in the next few
> days...I just need some time to think about the design.
>
> Christopher
>
> On Mon, Mar 7, 2011 at 5:59 AM, Michael Herndon > > wrote:
>
> > +1, Great Job Prescott.
> >
> > On Mon, Mar 7, 2011 at 3:44 AM, Glyn Darkin 
> > wrote:
> > > The site looks great.
> > >
> > > Well done!!!
> > >
> > > Glyn
> > >
> > > On 6 Mar 2011, at 23:04, Prescott Nasser (JIRA) wrote:
> > >
> > >>
> > >> [
> > https://issues.apache.org/jira/browse/LUCENENET-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
> > >>
> > >> Prescott Nasser resolved LUCENENET-403.
> > >> ---
> > >>
> > >> Resolution: Fixed
> > >>
> > >> Latest Layout was voted upon and selected. Images were updated by Mike
> > and I've moved it to staging:
> > http://lucene.net.staging.apache.org/lucene.net/index.html.
> > >>
> > >>> Improve site layout and design
> > >>> --
> > >>>
> > >>> Key: LUCENENET-403
> > >>> URL:
> > https://issues.apache.org/jira/browse/LUCENENET-403
> > >>> Project: Lucene.Net
> > >>> Issue Type: Sub-task
> > >>> Components: Project Infrastructure
> > >>> Reporter: Troy Howard
> > >>> Assignee: Prescott Nasser
> > >>> Fix For: Lucene.Net 2.9.2
> > >>>
> > >>> Attachments: layout1.zip, layout2.zip
> > >>>
> > >>>
> > >>> Improve the website layout and design. Current staging design is based
> > off an extremely simplistic implementation of Apache CMS basic template
> > using the default Apache CMS CSS styling. Let's try to make it look better
> > and have a more intuitive navigational structure.
> > >>> See staging site at:
> > >>> http://lucene.net.staging.apache.org/lucene.net/
> > >>> To edit content, please use:
> > >>> https://cms.apache.org/lucene.net/
> > >>
> > >> --
> > >> This message is automatically generated by JIRA.
> > >> For more information on JIRA, see:
> > http://www.atlassian.com/software/jira
> > >
> > > Glyn Darkin
> > >
> > > Darkin Systems Ltd
> > > Mob: 07961815649
> > > Fax: 08717145065
> > > Web: www.darkinsystems.com
> > >
> > > Company No: 6173001
> > > VAT No: 906350835
> > >
> > >
> > >
> > >
> > >
> > >
> >   

RE: [Lucene.Net] Google Ranking with Lucene

[Prescott Nasser]

Hello Björn.
 
In short, no.
 
What google does to their algorithmic search is extremely secretive. It is also 
a very limited subset of the type of data Lucene.Net might store. It uses lots 
of signals from around the web, such as how many people link to a particular 
page, to guage the important of a particular search result. This becomes 
irrelveant if you are indexing something such as research documents. People 
don't link to other documents in the traditional sense.
 
Further, the recent changes they made really focused on downranking "content 
farms" where data is cheaply put together and lots of advertising is added to 
generate advertising revenues. Their changes don't really apply to Lucene. That 
would more apply to how you decide to index your content, how deal with 
strengtheners, etc.
 
Hope that helps,
~Prescott Nasser






> Date: Mon, 7 Mar 2011 11:12:17 +0100
> From: b...@patorg.de
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] Google Ranking with Lucene
>
> Hello,
>
> i have just read that google has optimised its ranking. Now google shows
> more relevant results on the first pagen as before. Is there a chance to
> get advantage of this ranking algorithm with Lucene?
>
> Thank You
> Björn   

RE: [Lucene.Net] Nudge: Your Board Report Needs Content (was Re: Incubator PMC/Board report for March 2011)

[Prescott Nasser]

thanks for the nudge - I've updated this section







> From: bode...@apache.org
> To: lucene-net-dev@lucene.apache.org
> Date: Mon, 7 Mar 2011 10:18:04 +0100
> Subject: [Lucene.Net] Nudge: Your Board Report Needs Content (was Re: 
> Incubator PMC/Board report for March 2011)
>
> On 2011-03-01, Stefan Bodewig wrote:
>
> > this is one of the pain^H^H^H^Hjoys you've taken on yourself by entering
> > the incubator 8-)
>
> > Lucene.NET will be on a monthly schedule the first three month and then
> > change to a quarterly schedule for as long as you need to graduate.
>
> > On 2011-03-01, wrote:
>
> >> The board meeting is scheduled for Wed, 16 March 2011, 10 am
> >> Pacific. The report for your podling will form a part of the Incubator
> >> PMC report. The Incubator PMC requires your report to be submitted one
> >> week before the board meeting, to allow sufficient time for review.
>
> > This means the report has to be ready in
> > by the 9th. Please let us
> > mentors know when you deem it ready so we can review it.
>
> Still looks empty.
>
> Stefan  

RE: [Lucene.Net] buildbot success in ASF Buildbot on lucene.net-site-staging

[Prescott Nasser]

LOL - blame list - awesome.







> Date: Sat, 19 Mar 2011 21:35:53 +
> From: build...@apache.org
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] buildbot success in ASF Buildbot on 
> lucene.net-site-staging
>
> The Buildbot has detected a restored build of lucene.net-site-staging on ASF 
> Buildbot.
> Full details are available at:
> http://ci.apache.org/builders/lucene.net-site-staging/builds/45
>
> Buildbot URL: http://ci.apache.org/
>
> Buildslave for this Build: bb-cms-slave
>
> Build Reason:
> Build Source Stamp: [branch incubator/lucene.net/site] 1083298
> Blamelist: pnasser
>
> Build succeeded!
>
> sincerely,
> -The Buildbot
> 

[Lucene.Net] need some perl help

[Prescott Nasser]

Alright, any perl experts - I've been doing some binging and can't quite figure 
this out..
 
 
We have this function:
 
 
sub basic {
my %args = @_;
my $filepath = "content$args{path}";
read_text_file($filepath, \%args);
$args{path} =~ s/\.mdtext$/\.html/;
$args{breadcrumbs} = _breadcrumbs($args{path});
$args{tagline} = _tagline($args{path});
my $template_path = "templates/$args{template}";
my $rendered = Dotiac::DTL->new($template_path)->render(\%args);
return ($rendered, 'html', \%args);
}
 
and then following is part of _tagline:
 
 
sub _tagline {
my $file = basename($_); 
 
Occasionally, $_ is empty, which means basename($_) throws an error - 
specifically when editing .mdtext files via the asf cms process. This obviously 
poses an issue when compiling. I'm not sure how to account for this. Why would 
%args{path} be empty? I could just do a check in _tagline to say if $_ is empty 
then $file = "", which would work, but I'm concerned about why this is empty in 
the first place
 
Thanks for any help
~P

  

RE: [Lucene.Net] need some perl help

[Prescott Nasser]

I added the fix to check if path is null - now of course when updating via the 
cms javascript on hte site, the path is null, so the tagline gets set to the 
default of Lucene.Net.
 
Not quite sure how to trouble shoot this
 






> From: geobmx...@hotmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Sat, 19 Mar 2011 15:38:45 -0700
> Subject: [Lucene.Net] need some perl help
>
>
> Alright, any perl experts - I've been doing some binging and can't quite 
> figure this out..
>
>
> We have this function:
>
>
> sub basic {
> my %args = @_;
> my $filepath = "content$args{path}";
> read_text_file($filepath, \%args);
> $args{path} =~ s/\.mdtext$/\.html/;
> $args{breadcrumbs} = _breadcrumbs($args{path});
> $args{tagline} = _tagline($args{path});
> my $template_path = "templates/$args{template}";
> my $rendered = Dotiac::DTL->new($template_path)->render(\%args);
> return ($rendered, 'html', \%args);
> }
>
> and then following is part of _tagline:
>
>
> sub _tagline {
> my $file = basename($_);
>
> Occasionally, $_ is empty, which means basename($_) throws an error - 
> specifically when editing .mdtext files via the asf cms process. This 
> obviously poses an issue when compiling. I'm not sure how to account for 
> this. Why would %args{path} be empty? I could just do a check in _tagline to 
> say if $_ is empty then $file = "", which would work, but I'm concerned about 
> why this is empty in the first place
>
> Thanks for any help
> ~P
>
> 

RE: [Lucene.Net] need some perl help

[Prescott Nasser]

gracias



~Prescott Nasser

prescott.nas...@hotmail.com

650.208.4205







> Date: Sat, 19 Mar 2011 16:50:45 -0700
> From: thowar...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] need some perl help
>
> I have had success asking questions in #asfinfra . Maybe they can explain.
>
> On Saturday, March 19, 2011, Prescott Nasser wrote:
> >
> > I added the fix to check if path is null - now of course when updating via 
> > the cms javascript on hte site, the path is null, so the tagline gets set 
> > to the default of Lucene.Net.
> >
> > Not quite sure how to trouble shoot this
> >>
> >>
> >> Alright, any perl experts - I've been doing some binging and can't quite 
> >> figure this out..
> >>
> >>
> >> We have this function:
> >>
> >>
> >> sub basic {
> >> my %args = @_;
> >> my $filepath = "content$args{path}";
> >> read_text_file($filepath, \%args);
> >> $args{path} =~ s/\.mdtext$/\.html/;
> >> $args{breadcrumbs} = _breadcrumbs($args{path});
> >> $args{tagline} = _tagline($args{path});
> >> my $template_path = "templates/$args{template}";
> >> my $rendered = Dotiac::DTL->new($template_path)->render(\%args);
> >> return ($rendered, 'html', \%args);
> >> }
> >>
> >> and then following is part of _tagline:
> >>
> >>
> >> sub _tagline {
> >> my $file = basename($_);
> >>
> >> Occasionally, $_ is empty, which means basename($_) throws an error - 
> >> specifically when editing .mdtext files via the asf cms process. This 
> >> obviously poses an issue when compiling. I'm not sure how to account for 
> >> this. Why would %args{path} be empty? I could just do a check in _tagline 
> >> to say if $_ is empty then $file = "", which would work, but I'm concerned 
> >> about why this is empty in the first place
> >>
> >> Thanks for any help
> >> ~P
> >>
> >>  

RE: [Lucene.Net] [VOTE] New Directory Layout for Project

[Prescott Nasser]

Any more thoughts on the directory structure?
 
Quick Recap:

We have Troy's original proposal here: 
http://people.apache.org/~thoward/Lucene.Net/directory-structure-example/
 
bin/
build/   (various solution and project files)
 vs2008/
 vs2010/ 
doc/
lib/ - third party libraries to make it easy to pull down the source and go
src/
contrib/
core/
demo/
test/
contrib/
core/
demo/
 
>From here, I further suggested cleaning up the contrib folder - because we 
>have extra folders:
 
src/contrib/contrib.net/contrib.net/ -> src/contrib/contrib.net/
src/contrib/snowball/snowball.net/ -> src/contrib/Snowball.net/ 
 
Digy further suggested dropping the .net in all those folders above, and 
finding a better name for contrib.net.
 
 
 







> Date: Thu, 10 Mar 2011 09:41:17 +0200
> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project
>
> Well, not really "core".
> Codes under Analyzer(by DIGY) can be moved to /src/contrib/analyzers (but
> they are not ports from java).
> The others(by M.GARSKI) are extensions to the core(something like
> Lucene.Net.Core.Extensions)
>
> DIGY
>
>
> On Thu, Mar 10, 2011 at 1:36 AM, Troy Howard wrote:
>
> > Yeah -- I also changed the Contrib.Net project folder name to
> > ~/src/contrib/core ...
> >
> > IMO we should just roll these into the main library if they are solid,
> > tested and useful.. This is keeping in line with our new philosophy
> > about allowing .NET specific changes, even if it means diverging from
> > Java Lucene to do it.
> >
> > Thanks,
> > Troy
> >
> >
> > On Wed, Mar 9, 2011 at 12:56 PM, Prescott Nasser 
> > wrote:
> > >
> > > Actually what IS contrib.net? It looks like it replaces certain files in
> > Lucene.Net core - are they files better suited to .net? What are they?
> > >
> > > If they are plugins / additional contributions like snowball, etc - why
> > not just break it out and include the appropriate stuff in contrib? Do we
> > need to specify that they are not avaliable in the java version?
> > >
> > >
> > >
> > >
> > >
> > > 
> > >> Date: Wed, 9 Mar 2011 22:18:22 +0200
> > >> From: digyd...@gmail.com
> > >> To: lucene-net-dev@lucene.apache.org
> > >> Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project
> > >>
> > >> 0
> > >>
> > >> ".Net"s seem to be redundant under /src/contrib/ . It could be something
> > >> like
> > >> Analyzers
> > >> Highlighter
> > >> Similarity
> > >> ...
> > >>
> > >>
> > >>
> > >> (Maybe, we should find a different name for contrib.net. It contains
> > >> "contributions specific to Lucene.Net which are not available in
> > >> Lucene.java)
> > >>
> > >> DIGY
> > >>
> > >> On Wed, Mar 9, 2011 at 9:08 PM, Prescott Nasser wrote:
> > >>
> > >> >
> > >> > Probably just a miss - but under the src/contrib folder you also have
> > a
> > >> > number of tests in there...
> > >> >
> > >> >
> > >> > Also, is it necessary to have all the sub folders? For the most part
> > the
> > >> > stuff in contrib.net is contrib.net - why the secondary folder?
> > Unless
> > >> > that is a requirement of NUnit to have the structure that way it seems
> > a bit
> > >> > cluttered.
> > >> >
> > >> > I would think something like
> > >> >
> > >> > src/contrib/contrib.net/
> > >> > src/contrib/Snowball.net/
> > >> >
> > >> > instead of
> > >> >
> > >> > src/contrib/contrib.net/contrib.net/
> > >> > src/contrib/snowball/snowball.net/
> > >> >
> > >> > I don't know how people feel about that
> > >> >
> > >> >
> > >> > ~P
> > >> >
> > >> >
> > >> > 
> > >> > > Date: Wed, 9 Mar 2011 13:31:34 -0500
> > >> > > From: mhern...@wickedsoftware.net
> > >> > > To: lucene-net-dev@lucene.apache.org
> > >> > > CC: thowar...@gmail.com
> > >> > > Subject: Re: [Lu

RE: [Lucene.Net] [VOTE] New Directory Layout for Project

[Prescott Nasser]

formatting got screwed when sending..

>
> Any more thoughts on the directory structure?
>
> Quick Recap:
>
> We have Troy's original proposal here: 
> http://people.apache.org/~thoward/Lucene.Net/directory-structure-example/
>
> bin/
> build/ (various solution and project files)
>  vs2008/
>  vs2010/
> doc/
> lib/ - third party libraries to make it easy to pull down the source and go
> src/
>  contrib/
>  core/
> demo/
> test/
> contrib/
> core/
> demo/
>
> From here, I further suggested cleaning up the contrib folder - because we 
> have extra folders:
>
> src/contrib/contrib.net/contrib.net/ -> src/contrib/contrib.net/
> src/contrib/snowball/snowball.net/ -> src/contrib/Snowball.net/
>
> Digy further suggested dropping the .net in all those folders above, and 
> finding a better name for contrib.net.
>
>
>
>
>
>
>
>
>
> 
> > Date: Thu, 10 Mar 2011 09:41:17 +0200
> > From: digyd...@gmail.com
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project
> >
> > Well, not really "core".
> > Codes under Analyzer(by DIGY) can be moved to /src/contrib/analyzers (but
> > they are not ports from java).
> > The others(by M.GARSKI) are extensions to the core(something like
> > Lucene.Net.Core.Extensions)
> >
> > DIGY
> >
> >
> > On Thu, Mar 10, 2011 at 1:36 AM, Troy Howard wrote:
> >
> > > Yeah -- I also changed the Contrib.Net project folder name to
> > > ~/src/contrib/core ...
> > >
> > > IMO we should just roll these into the main library if they are solid,
> > > tested and useful.. This is keeping in line with our new philosophy
> > > about allowing .NET specific changes, even if it means diverging from
> > > Java Lucene to do it.
> > >
> > > Thanks,
> > > Troy
> > >
> > >
> > > On Wed, Mar 9, 2011 at 12:56 PM, Prescott Nasser
> > > wrote:
> > > >
> > > > Actually what IS contrib.net? It looks like it replaces certain files in
> > > Lucene.Net core - are they files better suited to .net? What are they?
> > > >
> > > > If they are plugins / additional contributions like snowball, etc - why
> > > not just break it out and include the appropriate stuff in contrib? Do we
> > > need to specify that they are not avaliable in the java version?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 
> > > >> Date: Wed, 9 Mar 2011 22:18:22 +0200
> > > >> From: digyd...@gmail.com
> > > >> To: lucene-net-dev@lucene.apache.org
> > > >> Subject: Re: [Lucene.Net] [VOTE] New Directory Layout for Project
> > > >>
> > > >> 0
> > > >>
> > > >> ".Net"s seem to be redundant under /src/contrib/ . It could be 
> > > >> something
> > > >> like
> > > >> Analyzers
> > > >> Highlighter
> > > >> Similarity
> > > >> ...
> > > >>
> > > >>
> > > >>
> > > >> (Maybe, we should find a different name for contrib.net. It contains
> > > >> "contributions specific to Lucene.Net which are not available in
> > > >> Lucene.java)
> > > >>
> > > >> DIGY
> > > >>
> > > >> On Wed, Mar 9, 2011 at 9:08 PM, Prescott Nasser wrote:
> > > >>
> > > >> >
> > > >> > Probably just a miss - but under the src/contrib folder you also have
> > > a
> > > >> > number of tests in there...
> > > >> >
> > > >> >
> > > >> > Also, is it necessary to have all the sub folders? For the most part
> > > the
> > > >> > stuff in contrib.net is contrib.net - why the secondary folder?
> > > Unless
> > > >> > that is a requirement of NUnit to have the structure that way it 
> > > >> > seems
> > > a bit
> > > >> > cluttered.
> > > >> >
> > > >> > I would think something like
> > > >> >
> > > >> > src/contrib/contrib.net/
> > > >> > src/contrib/Snowball.net/
> > > >> >
> > > >> > instead of
> > > >&

RE: [Lucene.Net] Creating a ASF fork of Sharpen under a dOCL license

[Prescott Nasser]

>
> > I haven't followed the discussion as to why you think a fork is
> > necessary. Do you think they'd understand your reasons and agree the
> > fork is a good idea?
>
 
Alex reached out to them. They said they are open to accepting patches, however 
their repo and response times that Alex could see were extremely slow. Further, 
it's likely we will want to do more Lucene Java -> .Net specific work that they 
might decide doesn't fit will with their overall goals.
 
I think at the end of the day, I feel (others maybe agree), that it's easier to 
just fork it at the start than attempt to give them patches and worry about lag 
time or rejection.
 

> Even if they did, the Apache Software License is the only one that could
> be used for the fork if it was to be developed inside the ASF repo.
>

Completely understood - I *think* that is possible. Obviously if it's not, we 
have to do it else where
 
There's back converation on the JIRA 
https://issues.apache.org/jira/browse/LUCENENET-380
 
~Prescott 

RE: [Lucene.Net] Creating a ASF fork of Sharpen under a dOCL license

[Prescott Nasser]

Stefan, how do you read their licensing:
 
http://www.db4o.com/about/company/legalpolicies/docl.aspx
 
By your reading is it possible to include this in our repo to keep everything 
together? or would this have to be outside the ASF?








> From: geobmx...@hotmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Thu, 24 Mar 2011 23:33:21 -0700
> Subject: RE: [Lucene.Net] Creating a ASF fork of Sharpen under a dOCL license
>
>
>
> >
> > > I haven't followed the discussion as to why you think a fork is
> > > necessary. Do you think they'd understand your reasons and agree the
> > > fork is a good idea?
> >
>
> Alex reached out to them. They said they are open to accepting patches, 
> however their repo and response times that Alex could see were extremely 
> slow. Further, it's likely we will want to do more Lucene Java -> .Net 
> specific work that they might decide doesn't fit will with their overall 
> goals.
>
> I think at the end of the day, I feel (others maybe agree), that it's easier 
> to just fork it at the start than attempt to give them patches and worry 
> about lag time or rejection.
>
>
> > Even if they did, the Apache Software License is the only one that could
> > be used for the fork if it was to be developed inside the ASF repo.
> >
>
> Completely understood - I *think* that is possible. Obviously if it's not, we 
> have to do it else where
>
> There's back converation on the JIRA 
> https://issues.apache.org/jira/browse/LUCENENET-380
>
> ~Prescott   

[Lucene.Net] release 2.9.4

[Prescott Nasser]

Hey all,

I know we have a number of outstanding JIRA issues, but I think most of them 
have been handled for the 2.9.4 release? Do we have anything outstanding that 
is holding back a new release?

~P

[Lucene.Net] new structure

[Prescott Nasser]

Hey Troy any status update on the new structure? I'm hesistant to do updates 
since I know you're going to be modifying it all shortly
 
~P
  

[Lucene.Net] var

[Prescott Nasser]

Where do we stand on use of the var keyword?
  

RE: [Lucene.Net] var

[Prescott Nasser]

I recall us discussing this a bit, but I don't recall the outcome (couldn't 
find it in the mailing list archives either).
 
Can anyone else find that thread? 
 
If not, what are people's feelings on this? I think at a certain point we can 
say we don't need .NET 2.0 going forward, but what point do we want to make 
that? We have the main trunk that people are testing, some feedback is good. 
And then the 2_9_4g branch that Digy started (and I semi-hijacked sorry!) 







> Date: Sat, 7 May 2011 01:55:40 -0400
> From: mhern...@wickedsoftware.net
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] var
>
> I think that is going to depend on if we are continuing .net 2.0 / C# 2.0
> support or dropping it.
>
>
> On Sat, May 7, 2011 at 1:19 AM, Prescott Nasser wrote:
>
> >
> > Where do we stand on use of the var keyword?
> >   

RE: [Lucene.Net] Incubator PMC/Board report for May 2011 (lucene-net-dev@lucene.apache.org)

[Prescott Nasser]

I've updated our report - please take a quick pass at it to see if anything is 
missing.







> From: no-re...@apache.org
> To: lucene-net-dev@lucene.apache.org
> Date: Sun, 1 May 2011 14:00:09 +
> Subject: [Lucene.Net] Incubator PMC/Board report for May 2011 
> (lucene-net-dev@lucene.apache.org)
>
> Dear Lucene.NET Developers,
>
> This email was sent by an automated system on behalf of the Apache Incubator 
> PMC.
> It is an initial reminder to give you plenty of time to prepare your quarterly
> board report.
>
> The board meeting is scheduled for Thurs, 19 May 2011, 10 am Pacific. The 
> report
> for your podling will form a part of the Incubator PMC report. The Incubator 
> PMC
> requires your report to be submitted one week before the board meeting, to 
> allow
> sufficient time for review.
>
> Please submit your report with sufficient time to allow the incubator PMC, and
> subsequently board members to review and digest. Again, the very latest you
> should submit your report is one week prior to the board meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
> --
>
> Your report should contain the following:
>
> * Your project name
> * A brief description of your project, which assumes no knowledge of the 
> project
> or necessarily of its field
> * A list of the three most important issues to address in the move towards
> graduation.
> * Any issues that the Incubator PMC or ASF Board might wish/need to be aware 
> of
> * How has the community developed since the last report
> * How has the project developed since the last report.
>
> This should be appended to the Incubator Wiki page at:
>
> http://wiki.apache.org/incubator/May2011
>
> Note: This manually populated. You may need to wait a little before this page 
> is
> created from a template.
>
> Mentors
> ---
> Mentors should review reports for their project(s) and sign them off on the
> Incubator wiki page. Signing off reports shows that you are following the
> project - projects that are not signed may raise alarms for the Incubator PMC.
>
> Incubator PMC
> 

RE: [Lucene.Net] var

[Prescott Nasser]

~Prescott Nasser
prescott.nas...@hotmail.com
650.208.4205

It's a 3.0 keyword, can't be used pre C# 3.0
 

> From: m...@aaron-powell.com
> To: lucene-net-dev@lucene.apache.org
> Date: Sat, 7 May 2011 07:28:36 +
> Subject: RE: [Lucene.Net] var
> 
> My understanding of the 'var' keyword is just C# syntactic sugar, which the 
> compiler will translate into the actual CLR type for variable assignment, so 
> the compiler is capable of compiling CLR 2.0 assemblies anyway.
> 
> Aaron Powell
> MVP - Internet Explorer (Development) | Umbraco Core Team Member | FunnelWeb 
> Team Member
> 
> http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | MSN: 
> aaz...@hotmail.com
> 
> -Original Message-
> From: Michael Herndon [mailto:mhern...@wickedsoftware.net] 
> Sent: Saturday, 7 May 2011 3:56 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] var
> 
> I think that is going to depend on if we are continuing .net 2.0 / C# 2.0 
> support or dropping it.
> 
> 
> On Sat, May 7, 2011 at 1:19 AM, Prescott Nasser wrote:
> 
> >
> > Where do we stand on use of the var keyword?
> >   

[Lucene.Net] separating project file from actual code files

[Prescott Nasser]

This seems like it should be obvious, but I'm trying to create a new 
Contrib.Regex project for the Regex stuff. However, when I do this, VS wants to 
put all the .cs files into the build directory where the project file is. How 
do I tell the project file that the actual files for the project should be 
located in another folder?
 
I've taken a look at some of hte other projects but I can't see where this is 
designated
 
~P

RE: [Lucene.Net] separating project file from actual code files

[Prescott Nasser]

most helpful, thanks!






> Date: Sat, 7 May 2011 15:27:37 -0400
> From: wyatt.barn...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] separating project file from actual code files
>
> Never worked in this kind of layout before, but I've moved things on
> solutions so this should work:
>
> 1) Create the project where you want it, with the solution file there.
> 2) Save and close visual studio.
> 3) Move the solution file over to where appropriate.
> 4) Open solution in text editor of your choice
> 5) Edit the Project line items to point to the appropriate relative path.
> 6) re-open solution.
>
> VS thinks relative to the project root, not solution root, so once you
> get the solution setup like that you should end up adding .cs files
> and such to the correct folder.
>
> On Sat, May 7, 2011 at 3:10 PM, Prescott Nasser wrote:
> >
> >
> > This seems like it should be obvious, but I'm trying to create a new 
> > Contrib.Regex project for the Regex stuff. However, when I do this, VS 
> > wants to put all the .cs files into the build directory where the project 
> > file is. How do I tell the project file that the actual files for the 
> > project should be located in another folder?
> >
> > I've taken a look at some of hte other projects but I can't see where this 
> > is designated
> >
> > ~P

RE: [Lucene.Net] svn commit: r1100639 - /incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs

[Prescott Nasser]

I'd be happy too - but I haven't looked at the trunk in a while - and I took a 
quick look at it today to get the latest, and well it was a bit confusing.
 
We have a trunk/C# directory which seems to have the old .NET after everything, 
and then we have what looks like the new directory structure right in trunk/
 
In other words, two copies of everything in a slightly different format or am I 
missing something?
 






> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Sun, 8 May 2011 01:23:49 +0300
> Subject: RE: [Lucene.Net] svn commit: r1100639 - 
> /incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
>
> Hi Prescott,
> Can you apply these fixes also to trunk? They don't diverge from java 2.9.4 
> and can be compiled targetting .NET 2.0.
>
> LUCENENET-361 Workaround for a Mono C# compiler issue
> LUCENENET-330 Search.Regex Minimal Port
> LUCENENET-371 Unit test for Search.Regex port
>
> DIGY
>
> -Original Message-
> From: pnas...@apache.org [mailto:pnas...@apache.org]
> Sent: Sunday, May 08, 2011 1:05 AM
> To: lucene-net-comm...@lucene.apache.org
> Subject: [Lucene.Net] svn commit: r1100639 - 
> /incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
>
> Author: pnasser
> Date: Sat May 7 22:04:43 2011
> New Revision: 1100639
>
> URL: http://svn.apache.org/viewvc?rev=1100639&view=rev
> Log:
> LUCENENET-361 Workaround for a Mono C# Compiler issue
>
> Modified:
> incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
>
> Modified: 
> incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
> URL: 
> http://svn.apache.org/viewvc/incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs?rev=1100639&r1=1100638&r2=1100639&view=diff
> ==
> --- 
> incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
>  (original)
> +++ 
> incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
>  Sat May 7 22:04:43 2011
> @@ -230,12 +230,16 @@ namespace Lucene.Net.Support
> return GetHashCode(this);
> }
>
> +#if __MonoCS__
> + public static int GetHashCode(System.Collections.Generic.IEnumerable source)
> +#else
> /// Gets the hash code for the list.
> - /// The 
> + /// The 
> /// implementation which will have all the contents hashed.
> /// The hash code value.
> public static int GetHashCode(System.Collections.Generic.IEnumerable source)
> - {
> +#endif
> + {
> // If source is null, then return 0.
> if (source == null) return 0;
>
>
> 

RE: [Lucene.Net] svn commit: r1100639 - /incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs

[Prescott Nasser]

That would make sense, I'm good on the new structure







> From: thowar...@gmail.com
> Date: Sun, 8 May 2011 01:31:46 -0700
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] svn commit: r1100639 - 
> /incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
>
> I was waiting for a round of testing/consensus regarding the trunk before
> deleting the old directory tree under C#.
>
> I suppose it's been enough time, and I'll just delete/commit that.
>
> Thanks,
> Troy
>
>
> On Sun, May 8, 2011 at 12:16 AM, Prescott Nasser wrote:
>
> >
> > I'd be happy too - but I haven't looked at the trunk in a while - and I
> > took a quick look at it today to get the latest, and well it was a bit
> > confusing.
> >
> > We have a trunk/C# directory which seems to have the old .NET after
> > everything, and then we have what looks like the new directory structure
> > right in trunk/
> >
> > In other words, two copies of everything in a slightly different format or
> > am I missing something?
> >
> >
> >
> >
> >
> >
> > 
> > > From: digyd...@gmail.com
> > > To: lucene-net-dev@lucene.apache.org
> > > Date: Sun, 8 May 2011 01:23:49 +0300
> > > Subject: RE: [Lucene.Net] svn commit: r1100639 - /incubator/
> > lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
> > >
> > > Hi Prescott,
> > > Can you apply these fixes also to trunk? They don't diverge from java
> > 2.9.4 and can be compiled targetting .NET 2.0.
> > >
> > > LUCENENET-361 Workaround for a Mono C# compiler issue
> > > LUCENENET-330 Search.Regex Minimal Port
> > > LUCENENET-371 Unit test for Search.Regex port
> > >
> > > DIGY
> > >
> > > -Original Message-
> > > From: pnas...@apache.org [mailto:pnas...@apache.org]
> > > Sent: Sunday, May 08, 2011 1:05 AM
> > > To: lucene-net-comm...@lucene.apache.org
> > > Subject: [Lucene.Net] svn commit: r1100639 - /incubator/
> > lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
> > >
> > > Author: pnasser
> > > Date: Sat May 7 22:04:43 2011
> > > New Revision: 1100639
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1100639&view=rev
> > > Log:
> > > LUCENENET-361 Workaround for a Mono C# Compiler issue
> > >
> > > Modified:
> > > incubator/
> > lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
> > >
> > > Modified: incubator/
> > lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs
> > > URL:
> > http://svn.apache.org/viewvc/incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs?rev=1100639&r1=1100638&r2=1100639&view=diff
> > >
> > ==
> > > --- incubator/
> > lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.cs(original)
> > > +++ incubator/
> > lucene.net/branches/Lucene.Net_2_9_4g/src/core/Support/EquatableList.csSat 
> > May 7 22:04:43 2011
> > > @@ -230,12 +230,16 @@ namespace Lucene.Net.Support
> > > return GetHashCode(this);
> > > }
> > >
> > > +#if __MonoCS__
> > > + public static int GetHashCode(System.Collections.Generic.IEnumerable
> > source)
> > > +#else
> > > /// Gets the hash code for the list.
> > > - /// The
> > > + /// The
> > > /// implementation which will have all the contents hashed.
> > > /// The hash code value.
> > > public static int GetHashCode(System.Collections.Generic.IEnumerable
> > source)
> > > - {
> > > +#endif
> > > + {
> > > // If source is null, then return 0.
> > > if (source == null) return 0;
> > >
> > >
> > >
> >   

RE: [Lucene.Net] Lucene.Net Hackathon (5/13-/516)

[Prescott Nasser]

+1 to getting 2.9.4 ready to roll + the changes to the directory structure we 
have going
 
Two and three on my list are :
 
-Sharpen stuff - I haven't had time to get it really working (not to mention I 
don't know eclipse from a hole in the ground). I haven't heard from Alex in a 
while, who I think is the most knowledgeable on the subject.
 
-.NET syntax.
 
-

That said, I think Luke is important. If we left with the idea of you could run 
Luke in java just find, we could also just say use lucene/solr and the api 
provided, no need for the Lucene.Net project. (I know it's a bit different). 
That said, I don't think it's top priority, but it would be nice to have a .net 
implimentation.
 
Sergey was working on a port of this in WPF - can he perhaps provide an update 
on what's going on with that? I think it was located at bit bucket at one 
point, and then I lost track..
 
 




> Date: Sun, 8 May 2011 23:51:08 +0300
> From: ita...@code972.com
> To: lucene-net-dev@lucene.apache.org
> CC: thowar...@gmail.com
> Subject: Re: [Lucene.Net] Lucene.Net Hackathon (5/13-/516)
>
> Making release 2.9.4 and performance tuning are the hottest items IMHO.
>
>
> If you ask me, there's no need for Luke.NET. Luke is just a tool, and we
> can run it just fine in Java. Same goes for docs - the Java version has
> this covered.
>
>
> Itamar.
>
>
> On 08/05/2011 23:29, Troy Howard wrote:
>
> > All,
> >
> > I'll be attending the Apache Retreat in Knockree next week (5/13-5/16). I
> > was thinking it would be fun to arrange a Lucene.Net Hackathon for the same
> > time frame. Even if you can't go to the event, we can hack together in a
> > distributed fashion. ;)
> >
> > Hackathons are usually focused on particular features/tasks. Some
> > outstanding tasks are:
> >
> > - Release 2.9.4
> > - Work on Sharpen/fully automated port (initial implementation)
> > - Luke.Net
> > - .Net idiomatic API (initial design)
> > - Improve website documentation, how tos, samples, etc
> > - Miscellaneous alternative framework support (Compact, Silverlight)
> > - ???
> >
> > Does this sound like a fun idea? Got any other tasks we could try to tackle
> > that didn't occur to me as I typed up this email?
> >
> > Even if no one else wants to get in on the Hackathon, I'll be working on
> > Lucene.Net all weekend, so which ones of these do you think is most
> > urgent/interesting?
> >
> > Thanks,
> > Troy
> >   

RE: [Lucene.Net] Lucene.Net Hackathon (5/13-/516)

[Prescott Nasser]

I think Troy has the structure ready to roll - I'm not sure if there is a 
coding difference between the C# stuff and the other directory stuff. If there 
isn't then we can probably branch C# to something like pre_NewStructure 
(someone help me with a better name), then remove it from the trunk.
 
Troy I believe was investigating the legal task - perhaps he can update us if 
he ever got an answer
 
If you want to jump into a smaller task take a look at 
https://issues.apache.org/jira/browse/LUCENENET-372 (currently assigned to me). 
I updated a ton of the analyers, but I believe them to be out of date from the 
java 2.9.4 branch because I used the attached files from Pasha without paying 
attention to the age of them. So those could use a review. I also never ported 
the test cases, which we definately should have.




> Date: Mon, 9 May 2011 10:04:03 +0200
> From: ma...@rotselleri.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] Lucene.Net Hackathon (5/13-/516)
>
> On Mon, May 9, 2011 at 1:12 AM, Prescott Nasser wrote:
> >
> > +1 to getting 2.9.4 ready to roll + the changes to the directory structure 
> > we have
> > going
>
> +1 for 2.9.4 and directory structure.
> To make that happen, I'd like to know what needs to be done and in
> what way I could be of any help. There are 10 open issues for 2.9.4,
> and (apart from the Luke issues mentioned below) none of them makes me
> feel that I can grab it and start coding.
>
> > -Sharpen stuff - I haven't had time to get it really working (not to 
> > mention I don't know
> > eclipse from a hole in the ground). I haven't heard from Alex in a while, 
> > who I think is
> > the most knowledgeable on the subject.
>
> Also most important to get closer to the java version.
>
> > -.NET syntax.
> +1, the API often feels quite awkward to use.
>
> > That said, I think Luke is important. If we left with the idea of you could 
> > run Luke in
> > java just find, we could also just say use lucene/solr and the api 
> > provided, no need
> > for the Lucene.Net project. (I know it's a bit different). That said, I 
> > don't think it's top
> > priority, but it would be nice to have a .net implimentation.
>
> Agree, it would be nice to have.
>
> > Sergey was working on a port of this in WPF - can he perhaps provide an 
> > update on
> > what's going on with that? I think it was located at bit bucket at one 
> > point, and then I
> > lost track..
>
> The WPF track was abandoned due to absent WPF support in mono. I
> adopted code attached to LUCENET-391 by Pasha Bizhan and it is
> continued on
> https://github.com/mammo/LukeSharp (mirror at
> https://bitbucket.org/mammo/lukesharp). Testing and reporting of
> broken or missing features would be most appreciated.
>
> I am not sure how to resolve the Luke legal sub-task LUCENET-397, is
> it enough that Pasha has attached the code or is more paper work
> required?
>
>
> /amanuel

RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Prescott Nasser]

This is my +1 as well






> Date: Tue, 10 May 2011 09:24:07 +0200
> From: simone.chiare...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache 
> Lucene.Net 2.9.4
>
> +1
> one option is that we could go forward with .NET 4, but still keep a "fix
> branch" that keeps the current .NET 2 based version free from bugs and
> security issues that ppl report.
>
> Simone
>
> On Tue, May 10, 2011 at 9:18 AM, Amanuel Workneh wrote:
>
> > +1 (According to Digy's suggestion)
> >
> >
> > On Mon, May 9, 2011 at 10:04 PM, Troy Howard wrote:
> > > All,
> > >
> > > Please cast your votes regarding the topic of .Net Framework support.
> > >
> > > The question on the table is:
> > >
> > > Should Apache Lucene.Net 2.9.4 be the last release which supports the
> > > .Net 2.0 Framework?
> > >
> > > Some options are:
> > >
> > > [+1] - Yes, move forward to the latest .Net Framework version, and drop
> > > support for 2.0 completely. New features and performance are more
> > important
> > > than backwards compatibility.
> > > [0] - Yes, focus on the latest .Net Framework, but also include patches
> > > and/or preprocessor directives and conditional compilation blocks to
> > include
> > > support for 2.0 when needed. New features, performance, and backwards
> > > compatibility are all equally important and it's worth the additional
> > > complexity and coding work to meet all of those goals.
> > > [-1] No, .Net Framework 2.0 should remain our target platform. Backwards
> > > compatibility is more important than new features and performance.
> > >
> > >
> > > This vote is not limited to the Apache Lucene.Net IPMC. All
> > > users/contributors/committers/mailing list lurkers are welcome to cast
> > their
> > > votes with an equal weight. This has been cross posted to both the dev
> > and
> > > user mailing lists.
> > >
> > > Thanks,
> > > Troy
> > >
> >
>
>
>
> --
> Simone Chiaretta
> Microsoft MVP ASP.NET - ASPInsider
> Blog: http://codeclimber.net.nz
> RSS: http://feeds2.feedburner.com/codeclimber
> twitter: @simonech
>
> Any sufficiently advanced technology is indistinguishable from magic
> "Life is short, play hard"  

RE: [Lucene.Net] Lucene.Net Hackathon (5/13-/516)

[Prescott Nasser]

1 at 1:38 PM, Michael Herndon
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> log out and log back in and verify permission changes.
> >> >> >> >>
> >> >> >> >> On Mon, May 9, 2011 at 4:22 PM, Troy Howard 
> >> >> >> wrote:
> >> >> >> >>
> >> >> >> >> > Re: "I'm not sure if there is a coding difference between the C#
> >> >> >>stuff
> >> >> >> and
> >> >> >> >> > the other directory stuff."
> >> >> >> >> >
> >> >> >> >> > There are a few minor code changes in the new branch vs the C#
> >> >> >>branch,
> >> >> >> but
> >> >> >> >> > those are things like framework target, copyright notices, etc..
> >> I
> >> >> >> didn't
> >> >> >> >> > change code significantly, and unit tests still pass.
> >> >> >> >> >
> >> >> >> >> > Re: "we can probably branch C# to something like
> >> pre_NewStructure"
> >> >> >> >> >
> >> >> >> >> > I made a tag right before committing the directory changes for
> >> this
> >> >> >> exact
> >> >> >> >> > purpose. It's here:
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >>
> >> >> >>
> >> >>
> >> https://svn.apache.org/repos/asf/incubator/lucene.net/tags/pre-layout-cha
> >> >> >>nge
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > Regarding the hackathon next week, I'd like to put together a
> >> list
> >> >> >>of
> >> >> >> tasks
> >> >> >> >> > specifically for this weekend to give people some focus on where
> >> >> >>they
> >> >> >> can
> >> >> >> >> > contribute. Some of these will be major tasks with high priority
> >> >> >>(like
> >> >> >> >> > finishing up the 2.9.4 release) and others will be of lower
> >> >> >>priority
> >> >> >> like
> >> >> >> >> > working on the samples/wiki/website... Those will great skills
> >> in
> >> >> >> creating
> >> >> >> >> > GUI apps, but less skills with writing back-end libraries might
> >> >> >>want
> >> >> >> to
> >> >> >> >> > contribute to Luke.Net, even if it's not a high priority.
> >> >> >> >> >
> >> >> >> >> > I agree with Michael that we should tweet/blog/wiki/mailing list
> >> >> >>the
> >> >> >> >> > details
> >> >> >> >> > of the event. I would make a wiki page on the topic, but it
> >> seems I
> >> >> >> don't
> >> >> >> >> > have sufficient privileges on our Confluence wiki to do that.
> >> Can
> >> >> >> whoever
> >> >> >> >> > the admin is give me rights to add/edit wiki pages? My login is
> >> >> >> 'thoward'.
> >> >> >> >> >
> >> >> >> >> > Thanks,
> >> >> >> >> > Troy
> >> >> >> >> >
> >> >> >> >> > On Mon, May 9, 2011 at 1:15 AM, Prescott Nasser <
> >> >> >> geobmx...@hotmail.com
> >> >> >> >> > >wrote:
> >> >> >> >> >
> >> >> >> >> > >
> >> >> >> >> > > I think Troy has the structure ready to roll - I'm not sure if
> >> >> >>there
> >> >> >> is a
> >> >> >> >> > > coding difference between the C# stuff and the other directory
> >> >> >> stuff. If
> >> >> >> >> > > there isn't then we can probably branch C# to something like
> >&g

RE: [Lucene.Net] Problem while creating index for the xml file

[Prescott Nasser]

What's the issue your having? Seems like you're indexing the entire XML 
document as one field, which likely isn't the best way to go
 
~P






> Date: Tue, 17 May 2011 11:04:30 +0530
> From: vlalithasivajyo...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] Problem while creating index for the xml file
>
> Dear Lucene team,
>
> I would like to create index files for the below xml file using
> Lucene.Net dll v2.9. I used the below code, but its not working.
> Please guide me to create index files for the below xml file. Thanks
> in advance
>
>
> 
> 
> 
> 8742656
> KDILI00D9L36
> 
> ORIGINAL
> ADD_1STPASS
> 25
> BN
> ENGLISH
> 20090115 13:30:00.000
> 2
> *U.S. INITIAL JOBLESS CLAIMS ROSE 54,000 TO 524,000
> LAST WEEK
> PLAIN
> China’s statistics bureau said it condemns leaks of
> economic data and those responsible
> 
> 
> 8742656
> KDILI03T6SQU
> 
> ORIGINAL
> ADD_1STPASS
> 25
> BN
> ENGLISH
> 20090115 13:30:00.000
> 0
> *U.S. INITIAL JOBLESS CLAIMS ROSE 54,000 TO 524,000
> LAST WEEK
> PLAIN
> China’s foreign-exchange reserves exceeded $3 trillion for
> the first time
> 
> 
> 
>
> Code
> ===
> indexFileLocation = @"C:\Index";
> Lucene.Net.Store.Directory dir =
> FSDirectory.GetDirectory(indexFileLocation, true);
>
> //create an analyzer to process the text
> Lucene.Net.Analysis.Analyzer analyzer = new
> Lucene.Net.Analysis.Standard.StandardAnalyzer();
>
> IndexWriter indexWriter = new IndexWriter(indexFileLocation, new
> StandardAnalyzer(), true);
>
> TextReader txtReader = new StreamReader(@"C:\NewsMetaData.xml");
>
> //create a document, add in a single field
> Document doc = new Document();
> Field fldContent = new Field("contents", txtReader, Field.TermVector.YES);
>
> doc.Add(fldContent);
>
> //write the document to the index
> indexWriter.AddDocument(doc);
>
> //optimize and close the writer
> indexWriter.Optimize();
> indexWriter.Close();

RE: [Lucene.Net] svn commit: r1129829 - /incubator/lucene.net/branches/vs2010/

[Prescott Nasser]

+1


> Date: Tue, 31 May 2011 17:53:30 +
> To: lucene-net-comm...@lucene.apache.org
> From: d...@apache.org
> Subject: [Lucene.Net] svn commit: r1129829 - 
> /incubator/lucene.net/branches/vs2010/
> 
> Author: digy
> Date: Tue May 31 17:53:30 2011
> New Revision: 1129829
> 
> URL: http://svn.apache.org/viewvc?rev=1129829&view=rev
> Log:
> removing unused branch:wq
> 
> 
> Removed:
> incubator/lucene.net/branches/vs2010/
> 

[Lucene.Net] Could not load assembly

[Prescott Nasser]

While trying to set up a test for Contrib.IsolatedStorage, I'm running into an 
issue I haven't been able to solve.
 
{System.TypeLoadException: Could not load type 'Lucene.Net.Documents.Document' 
from assembly 'Lucene.Net, Version=2.9.4.2, Culture=neutral, 
PublicKeyToken=null'.
   at System.Windows.Controls.Primitives.ButtonBase.OnClick()
   at System.Windows.Controls.Button.OnClick()
   at 
System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs
 e)
   at System.Windows.Controls.Control.OnMouseLeftButtonUp(Control ctrl, 
EventArgs e)
   at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr 
unmanagedObjArgs, Int32 argsTypeIndex, String eventName)
}
 
I'm not sure why I'm getting this. When I call the IsolatedStorageDirectory 
constructor, that runs fine, but when I try to call something from the 
Lucene.Net core I'm running into this error.
 
Directory isoDir = new IsolatedStorageDirectory("//", null);
Document doc; //this line throws the error, the above runs fine.
 
I've cleared the GAC, made sure I've got the latest binaries referenced etc.
 
Any thoughts?
 
Thanks,
~Prescott 

RE: [Lucene.Net] Could not load assembly

[Prescott Nasser]

I have - I wasn't sure how to fake IsolatedStorage and figured I'd just try and 
get it running in a wp7 app with the emulator, then go back and start filling 
in holes (like the test proj)





> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Sun, 12 Jun 2011 01:23:35 +0300
> Subject: RE: [Lucene.Net] Could not load assembly
>
> Hard to guess.
>
> Have you seen Contrib.IsolatedStorage.Test.csproj?
>
> DIGY
>
> -Original Message-
> From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> Sent: Sunday, June 12, 2011 12:33 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] Could not load assembly
>
>
> While trying to set up a test for Contrib.IsolatedStorage, I'm running into
> an issue I haven't been able to solve.
>
> {System.TypeLoadException: Could not load type
> 'Lucene.Net.Documents.Document' from assembly 'Lucene.Net, Version=2.9.4.2,
> Culture=neutral, PublicKeyToken=null'.
> at System.Windows.Controls.Primitives.ButtonBase.OnClick()
> at System.Windows.Controls.Button.OnClick()
> at
> System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButto
> nEventArgs e)
> at System.Windows.Controls.Control.OnMouseLeftButtonUp(Control ctrl,
> EventArgs e)
> at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr
> unmanagedObjArgs, Int32 argsTypeIndex, String eventName)
> }
>
> I'm not sure why I'm getting this. When I call the IsolatedStorageDirectory
> constructor, that runs fine, but when I try to call something from the
> Lucene.Net core I'm running into this error.
>
> Directory isoDir = new IsolatedStorageDirectory("//", null);
> Document doc; //this line throws the error, the above runs fine.
>
> I've cleared the GAC, made sure I've got the latest binaries referenced etc.
>
> Any thoughts?
>
> Thanks,
> ~Prescott =
> 

RE: [Lucene.Net] Could not load assembly

[Prescott Nasser]

Hmm, that's likely it. Do you know a fast way to compile Lucene.Net and the 
IsolatedStorage to the silverlight framework? I could create new wp7 class 
projects and import all the files, but surely there is another way?





> Date: Sat, 11 Jun 2011 18:34:02 -0400
> From: mhern...@wickedsoftware.net
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] Could not load assembly
>
> was it compiled against the wp7 version of silverlight? or .net full
> framework?
>
> On Sat, Jun 11, 2011 at 6:28 PM, Prescott Nasser wrote:
>
> >
> > I have - I wasn't sure how to fake IsolatedStorage and figured I'd just try
> > and get it running in a wp7 app with the emulator, then go back and start
> > filling in holes (like the test proj)
> >
> >
> >
> >
> > 
> > > From: digyd...@gmail.com
> > > To: lucene-net-dev@lucene.apache.org
> > > Date: Sun, 12 Jun 2011 01:23:35 +0300
> > > Subject: RE: [Lucene.Net] Could not load assembly
> > >
> > > Hard to guess.
> > >
> > > Have you seen Contrib.IsolatedStorage.Test.csproj?
> > >
> > > DIGY
> > >
> > > -Original Message-
> > > From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> > > Sent: Sunday, June 12, 2011 12:33 AM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: [Lucene.Net] Could not load assembly
> > >
> > >
> > > While trying to set up a test for Contrib.IsolatedStorage, I'm running
> > into
> > > an issue I haven't been able to solve.
> > >
> > > {System.TypeLoadException: Could not load type
> > > 'Lucene.Net.Documents.Document' from assembly 'Lucene.Net,
> > Version=2.9.4.2,
> > > Culture=neutral, PublicKeyToken=null'.
> > > at System.Windows.Controls.Primitives.ButtonBase.OnClick()
> > > at System.Windows.Controls.Button.OnClick()
> > > at
> > >
> > System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButto
> > > nEventArgs e)
> > > at System.Windows.Controls.Control.OnMouseLeftButtonUp(Control ctrl,
> > > EventArgs e)
> > > at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr
> > > unmanagedObjArgs, Int32 argsTypeIndex, String eventName)
> > > }
> > >
> > > I'm not sure why I'm getting this. When I call the
> > IsolatedStorageDirectory
> > > constructor, that runs fine, but when I try to call something from the
> > > Lucene.Net core I'm running into this error.
> > >
> > > Directory isoDir = new IsolatedStorageDirectory("//", null);
> > > Document doc; //this line throws the error, the above runs fine.
> > >
> > > I've cleared the GAC, made sure I've got the latest binaries referenced
> > etc.
> > >
> > > Any thoughts?
> > >
> > > Thanks,
> > > ~Prescott =
> > >
> >   

RE: [Lucene.Net] Could not load assembly

[Prescott Nasser]

Definitely a small project of changes ;) - for now it's a new branch that links 
to 2.9.4g (linking is definitely the way to go). At a certain point we might 
might merge the build and what into 2.9.4g directly.
 
We'll have to discuss in the future the best way to merge this back into 2.9.4g 
- there are some caveats - each will have a set of it's own files for some 
classes





> Date: Sat, 11 Jun 2011 19:15:55 -0400
> From: mhern...@wickedsoftware.net
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] Could not load assembly
>
> In the past people have used project linker. However there is something
> newer that could be use which is the portable class library:
> http://msdn.microsoft.com/en-us/library/gg597391.aspx
>
> Either way, unless someone knows an easier way (possibly changing the
> project guids), you'll have to use a separate project files to compile them
> against the silverlight framework.
>
> And that is even if the Lucene.Net core is currently compatible with the WP7
> apis. If it is not, that could be small project worth of changes within
> itself. (someone might have tried to compile it before hand).
>
> - Michael
>
> On Sat, Jun 11, 2011 at 6:58 PM, Prescott Nasser wrote:
>
> >
> > Hmm, that's likely it. Do you know a fast way to compile Lucene.Net and the
> > IsolatedStorage to the silverlight framework? I could create new wp7 class
> > projects and import all the files, but surely there is another way?
> >
> >
> >
> >
> > 
> > > Date: Sat, 11 Jun 2011 18:34:02 -0400
> > > From: mhern...@wickedsoftware.net
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: Re: [Lucene.Net] Could not load assembly
> > >
> > > was it compiled against the wp7 version of silverlight? or .net full
> > > framework?
> > >
> > > On Sat, Jun 11, 2011 at 6:28 PM, Prescott Nasser wrote:
> > >
> > > >
> > > > I have - I wasn't sure how to fake IsolatedStorage and figured I'd just
> > try
> > > > and get it running in a wp7 app with the emulator, then go back and
> > start
> > > > filling in holes (like the test proj)
> > > >
> > > >
> > > >
> > > >
> > > > 
> > > > > From: digyd...@gmail.com
> > > > > To: lucene-net-dev@lucene.apache.org
> > > > > Date: Sun, 12 Jun 2011 01:23:35 +0300
> > > > > Subject: RE: [Lucene.Net] Could not load assembly
> > > > >
> > > > > Hard to guess.
> > > > >
> > > > > Have you seen Contrib.IsolatedStorage.Test.csproj?
> > > > >
> > > > > DIGY
> > > > >
> > > > > -Original Message-
> > > > > From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> > > > > Sent: Sunday, June 12, 2011 12:33 AM
> > > > > To: lucene-net-dev@lucene.apache.org
> > > > > Subject: [Lucene.Net] Could not load assembly
> > > > >
> > > > >
> > > > > While trying to set up a test for Contrib.IsolatedStorage, I'm
> > running
> > > > into
> > > > > an issue I haven't been able to solve.
> > > > >
> > > > > {System.TypeLoadException: Could not load type
> > > > > 'Lucene.Net.Documents.Document' from assembly 'Lucene.Net,
> > > > Version=2.9.4.2,
> > > > > Culture=neutral, PublicKeyToken=null'.
> > > > > at System.Windows.Controls.Primitives.ButtonBase.OnClick()
> > > > > at System.Windows.Controls.Button.OnClick()
> > > > > at
> > > > >
> > > >
> > System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButto
> > > > > nEventArgs e)
> > > > > at System.Windows.Controls.Control.OnMouseLeftButtonUp(Control ctrl,
> > > > > EventArgs e)
> > > > > at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr
> > > > > unmanagedObjArgs, Int32 argsTypeIndex, String eventName)
> > > > > }
> > > > >
> > > > > I'm not sure why I'm getting this. When I call the
> > > > IsolatedStorageDirectory
> > > > > constructor, that runs fine, but when I try to call something from
> > the
> > > > > Lucene.Net core I'm running into this error.
> > > > >
> > > > > Directory isoDir = new IsolatedStorageDirectory("//", null);
> > > > > Document doc; //this line throws the error, the above runs fine.
> > > > >
> > > > > I've cleared the GAC, made sure I've got the latest binaries
> > referenced
> > > > etc.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > Thanks,
> > > > > ~Prescott =
> > > > >
> > > >
> >   

RE: [Lucene.Net] Could not load assembly

[Prescott Nasser]

I'll investigate it a bit. So far though there are issues with making lucene 
wp7 compatible ATM. As I fix things more issues  pop up.

Definitely something I'll look closely at though

Sent from my Windows Phone

-Original Message-
From: Michael Herndon
Sent: Saturday, June 11, 2011 6:30 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Could not load assembly



> If thats the case, I'd propose exploring the portable class library project
> for the long run.
> 
> Its supposed to constrain you to the shared APIs that are available in the
> target frameworks chosen. (xna/xbox, the full framework, silverlight,
> windows mobile 7 silverlight).
> 
> Then it should allow you to build against all of those using one project
> rather than having to maintain several csproj files or go through the hassle
> of linking files.
> 
> In the future MS is hoping to also get mono touch and mono droid as
> targets.
> 
> Getting Lucene.Net working on WP7, Mono Droid & Mono Touch would give
> Lucene.Net a leg up to it's java counterpart and enhance its long term
> viability.
> 
> - Michael
> 
> 
> 
> On Sat, Jun 11, 2011 at 8:33 PM, Prescott Nasser wrote:
> 
>>
>> Definitely a small project of changes ;) - for now it's a new branch that
>> links to 2.9.4g (linking is definitely the way to go). At a certain point we
>> might might merge the build and what into 2.9.4g directly.
>>
>> We'll have to discuss in the future the best way to merge this back into
>> 2.9.4g - there are some caveats - each will have a set of it's own files for
>> some classes
>>
>>
>>
>>
>> 
>> > Date: Sat, 11 Jun 2011 19:15:55 -0400
>> > From: mhern...@wickedsoftware.net
>> > To: lucene-net-dev@lucene.apache.org
>> > Subject: Re: [Lucene.Net] Could not load assembly
>> >
>> > In the past people have used project linker. However there is something
>> > newer that could be use which is the portable class library:
>> > http://msdn.microsoft.com/en-us/library/gg597391.aspx
>> >
>> > Either way, unless someone knows an easier way (possibly changing the
>> > project guids), you'll have to use a separate project files to compile
>> them
>> > against the silverlight framework.
>> >
>> > And that is even if the Lucene.Net core is currently compatible with the
>> WP7
>> > apis. If it is not, that could be small project worth of changes within
>> > itself. (someone might have tried to compile it before hand).
>> >
>> > - Michael
>> >
>> > On Sat, Jun 11, 2011 at 6:58 PM, Prescott Nasser wrote:
>> >
>> > >
>> > > Hmm, that's likely it. Do you know a fast way to compile Lucene.Net and
>> the
>> > > IsolatedStorage to the silverlight framework? I could create new wp7
>> class
>> > > projects and import all the files, but surely there is another way?
>> > >
>> > >
>> > >
>> > >
>> > > 
>> > > > Date: Sat, 11 Jun 2011 18:34:02 -0400
>> > > > From: mhern...@wickedsoftware.net
>> > > > To: lucene-net-dev@lucene.apache.org
>> > > > Subject: Re: [Lucene.Net] Could not load assembly
>> > > >
>> > > > was it compiled against the wp7 version of silverlight? or .net full
>> > > > framework?
>> > > >
>> > > > On Sat, Jun 11, 2011 at 6:28 PM, Prescott Nasser wrote:
>> > > >
>> > > > >
>> > > > > I have - I wasn't sure how to fake IsolatedStorage and figured I'd
>> just
>> > > try
>> > > > > and get it running in a wp7 app with the emulator, then go back and
>> > > start
>> > > > > filling in holes (like the test proj)
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > 
>> > > > > > From: digyd...@gmail.com
>> > > > > > To: lucene-net-dev@lucene.apache.org
>> > > > > > Date: Sun, 12 Jun 2011 01:23:35 +0300
>> > > > > > Subject: RE: [Lucene.Net] Could not load assembly
>> > > > > >
>> > > > > > Hard to guess.
>> > > > > >
>> > > > > > Have you seen Contrib.IsolatedStorage.Test.csproj?
>> > > > > 

[Lucene.Net] 2.9.4g branch - test

[Prescott Nasser]

Does anyone have the latest 2.9.4g branch they can run the tests on - I've done 
some WP7 stuff, and I'm coming up with 6 errors throughout all the tests. I 
didn't think to test before hand, and at the moment, I can't download a fresh 
copy of the branch
 
~P

RE: [Lucene.Net] svn commit: r1150205 - /incubator/lucene.net/site/trunk/content/lucene.net/index.mdtext

[Prescott Nasser]

I know :( ...I'm going to be updating the site to something different later 
today - in progress here 
http://lucene.net.staging.apache.org/lucene.net/index.html
 

> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Sat, 23 Jul 2011 23:31:46 +0300
> Subject: RE: [Lucene.Net] svn commit: r1150205 - 
> /incubator/lucene.net/site/trunk/content/lucene.net/index.mdtext
> 
> Get *invovled* to help shape our future
> 
> -Original Message-
> From: pnas...@apache.org [mailto:pnas...@apache.org] 
> Sent: Saturday, July 23, 2011 10:50 PM
> To: lucene-net-comm...@lucene.apache.org
> Subject: [Lucene.Net] svn commit: r1150205 - 
> /incubator/lucene.net/site/trunk/content/lucene.net/index.mdtext
> 
> Author: pnasser
> Date: Sat Jul 23 19:50:05 2011
> New Revision: 1150205
> 
> URL: http://svn.apache.org/viewvc?rev=1150205&view=rev
> Log:
> syntax updates
> 
> Modified:
> incubator/lucene.net/site/trunk/content/lucene.net/index.mdtext
> 
> Modified: incubator/lucene.net/site/trunk/content/lucene.net/index.mdtext
> URL: 
> http://svn.apache.org/viewvc/incubator/lucene.net/site/trunk/content/lucene.net/index.mdtext?rev=1150205&r1=1150204&r2=1150205&view=diff
> ==
> --- incubator/lucene.net/site/trunk/content/lucene.net/index.mdtext (original)
> +++ incubator/lucene.net/site/trunk/content/lucene.net/index.mdtext Sat Jul 
> 23 19:50:05 2011
> @@ -5,9 +5,10 @@
> Lucene.Net is a port of the Lucene search engine library, written in C# and 
> targeted at .NET runtime users. 
> Lucene.Net has three primary goals: 
> 
> -1. Maintain the existing line-by-line port from Java to C#, fully automating 
> and commoditizing the process such that the project can easily synchronize 
> with the Java Lucene release schedule;
> -2. Maintaining the high-performance requirements excepted of a first class 
> C# search engine library;
> -3. Maximize usability and power when used within the .NET runtime. To that 
> end, it will present a highly idiomatic, carefully tailored API that takes 
> advantage of many of the special features of the .NET runtime.
> +
> +1. Maintain the existing line-by-line port from Java to C#, fully automating 
> and commoditizing the process such that the project can easily synchronize 
> with the Java Lucene release schedule;
> +2. Maintaining the high-performance requirements excepted of a first class 
> C# search engine library;
> +3. Maximize usability and power when used within the .NET runtime. To that 
> end, it will present a highly idiomatic, carefully tailored API that takes 
> advantage of many of the special features of the .NET runtime.
> 
> 
> 
> 

[Lucene.Net] Staging Web page

[Prescott Nasser]

I've put an ounce of work into incorporating the new logo into a web layout - 
really simplifing everything. Please provide me any feedback you've got. The 
Getting Started page requires all the content - but I want to really spend some 
time on that, because it's important that it's thorough and clear to not 
disuade any users.



http://lucene.net.staging.apache.org/lucene.net/index.html


I'm probably going to publish this tonight or tomorrow

 

~P

RE: [Lucene.Net] Staging Web page

[Prescott Nasser]

Troy & Digy 

 

Do you see that as another tab on the navigation? I was kind of thinking the 
Tutorials Wiki page we somewhat have going would serve this purpose. 

 

I think I can definitely add some text about what exactly Lucene is on the main 
page

 

~P


> From: thowar...@gmail.com
> Date: Sat, 23 Jul 2011 16:46:20 -0700
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] Staging Web page
>
> I second that, and also a little background on the theoretical
> underpinnings of the Lucene project, in general... There are some
> great explanations of inverted indexing out there, and at least one
> presentation by Doug Cutting that explains the original design of
> Lucene, in a lot of detail, including reasoning, which I personally
> found really valuable when learning both how to use the library most
> effectively and how to hack on the library's internals.
>
> Here's some D. Cutting presentations I googled up. I think there are
> more out there.
>
> http://lucene.sourceforge.net/talks/pisa/
> http://lucene.sourceforge.net/talks/inktomi/
>
>
> Thanks,
> Troy
>
>
> On Sat, Jul 23, 2011 at 4:14 PM, Digy  wrote:
> > A "Some useful links" section?
> > like
> > http://wiki.apache.org/lucene-java/LuceneFAQ
> > http://wiki.apache.org/jakarta-lucene/BasicsOfPerformance
> > http://wiki.apache.org/lucene-java/ScoresAsPercentages
> >
> > and some other links to external sources about Lucene.Net
> >
> > DIGY
> >
> > -Original Message-
> > From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> > Sent: Sunday, July 24, 2011 1:45 AM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: [Lucene.Net] Staging Web page
> >
> >
> > I've put an ounce of work into incorporating the new logo into a web layout
> > - really simplifing everything. Please provide me any feedback you've got.
> > The Getting Started page requires all the content - but I want to really
> > spend some time on that, because it's important that it's thorough and clear
> > to not disuade any users.
> >
> >
> >
> > http://lucene.net.staging.apache.org/lucene.net/index.html
> >
> >
> > I'm probably going to publish this tonight or tomorrow
> >
> >
> >
> > ~P =
> >
> >   

RE: [Lucene.Net] style cop, fx cop rules

[Prescott Nasser]

>
> I don't think there's any harm in putting StyleCop in the project at this
> stage, but of course, no harm not putting it in either. It would be handy
> for people who already have VS2008/2010, as we could keep Lucene with the
> same style format across the project as a whole.
>


We should move forward to enhance the project imo. Those who are still using 
2005 can handle warnings if they pop up. It shoudln't be errors, so nothing 
should be breaking

 

> IMO, I think the Naming, Maintainability, and layour rules are the most
> important. I use R#, so many of the default ones there are the ones I'm
> partial to. For example, I like my private fields to start with
> underscores. I like my private properties, method names, public fields to be
> in pascal case. I like local variables and method parameters to use camel
> case. I dislike hungarian notation. I like only one class per file, and
> one namespace per file, those being in the maintainability rules.
>


+1, I'll also add I prefer one class per file as well, with some very rare 
exceptions (which for simplicity we could just say one class per file)

 


> > It might be prudent to wait on putting style cop int the project, it
> > currently doesn't have a command line client and if installed it would
> > generate warnings on each time someone builds on their local.
> >
> > - Michael.
> >

 

If I recall correctly, we agreed to move forward with our support, .Net 4 (or 
at least 3.5) and VS2008/2010. Since Stylecop there isn't much reason not to 
include it imo, if you're using 2005 still, then I think you should accept that 
you'll get warnings

 

 

~Prescott 

[Lucene.Net] 2.9.4

[Prescott Nasser]

Hey All,

 

How do people feel about the 2.9.4 code base? I've been using it for sometime, 
for my use cases it's be excellent. Do we feel we are ready to package this up 
and make it an official release? Or do we have some tasks left to take care of?

 

~Prescott 

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

Yeah, I looked at it as 2.9.4 has been around a while, I've been using it for a 
while, and I assume others have as well, and we haven't had any complaints (few 
exceptions). 

 

I hope people aren't waiting for a "last call" to provide feedback. It should 
be continous. When it dies down, I assume issues are shaken out and things are 
somewhat vetted.

 

~P

 



> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Tue, 6 Sep 2011 00:48:02 +0300
> Subject: RE: [Lucene.Net] 2.9.4
>
> To avoid misunderstanding...
>
> Community==all Lucene.Net users
>
> DIGY
>
> -Original Message-
> From: Digy [mailto:digyd...@gmail.com]
> Sent: Monday, September 05, 2011 11:46 PM
> To: 'lucene-net-dev@lucene.apache.org'
> Subject: RE: [Lucene.Net] 2.9.4
>
> Not bad idea, but I would prefer community's feedback instead of testing
> against all projects using Lucene.Net
> DIGY
>
> -Original Message-
> From: Matt Warren [mailto:mattd...@gmail.com]
> Sent: Monday, September 05, 2011 11:09 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] 2.9.4
>
> If you want to test it against a large project you could take a look at how
> RavenDB uses it?
>
> At the moment it's using 2.9.2 (
> https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
> )
> but if you were to recompile it against 2.9.4 and check that all it's
> unit-tests still run that would give you quite a large test case.
>
> On 5 September 2011 19:22, Prescott Nasser  wrote:
>
> >
> > Hey All,
> >
> > How do people feel about the 2.9.4 code base? I've been using it for
> > sometime, for my use cases it's be excellent. Do we feel we are ready to
> > package this up and make it an official release? Or do we have some tasks
> > left to take care of?
> >
> > ~Prescott
>
> -
> Bu iletide virüs bulunamadı.
> AVG tarafından kontrol edildi - www.avg.com
> Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
> 

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

Also +1 - but I don't mind waiting to hear back regarding the RavenDB stuff - 
but we can prepare assuming it's all good.

 

Digy can you elaborate on 414 
(https://issues.apache.org/jira/browse/LUCENENET-414). I must not have 
understood the complaint/question as adding that one method to me doesn't seem 
to resolve the issue brought up

 

Thanks,

~P


> From: digyd...@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Tue, 6 Sep 2011 23:14:37 +0300
> Subject: RE: [Lucene.Net] 2.9.4
>
> +1 for an official release.
> DIGY
>
> -----Original Message-
> From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> Sent: Monday, September 05, 2011 9:22 PM
> To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
> Subject: [Lucene.Net] 2.9.4
>
>
> Hey All,
>
>
>
> How do people feel about the 2.9.4 code base? I've been using it for
> sometime, for my use cases it's be excellent. Do we feel we are ready to
> package this up and make it an official release? Or do we have some tasks
> left to take care of?
>
>
>
> ~Prescott =
> -
> Bu iletide virüs bulunamadı.
> AVG tarafından kontrol edildi - www.avg.com
> Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
> 

RE: [Lucene.Net] Comparing APIs of two DLLs (something like Clirr for .NET)?

[Prescott Nasser]

I have heard people use http://www.bitwidgets.com/ to success. I have not used 
it myself though.


> From: bode...@apache.org
> To: lucene-net-dev@lucene.apache.org
> Date: Wed, 7 Sep 2011 06:05:01 +0200
> Subject: [Lucene.Net] Comparing APIs of two DLLs (something like Clirr for 
> .NET)?
>
> Hi,
>
> this is not about Lucene.NET even though it might be useful here as
> well.
>
> Over in log4net land we are trying to get our act together and finally
> do a new release.
>
> Given that many years have passed and the people active now haven't been
> around all the time we are looking for a tool that compares the public
> APIs of two assemblies so we can be sure we don't break any of the
> existing APIs of the last release.
>
> In a Java project I'd use Clirr[1], does anybody know a similar tool for
> .NET assemblies?
>
> Stefan
>
> [1] http://clirr.sourceforge.net/   

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

Thanks Itamar!


> Date: Sat, 10 Sep 2011 20:22:59 +0300
> From: ita...@code972.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] 2.9.4
>
> We have been running some extensive tests >30hrs now against the 2.9.4
> branch, and did not detect any leaks. We will have it running a few more
> days, if you wish to wait for more conclusive findings.
>
> On Wed, Sep 7, 2011 at 5:07 PM, Prescott Nasser wrote:
>
> > 2.9.4 would make it in I assume because that will be our next official
> > release.
> >
> >
> > Sent from my Windows Phone
> >
> > -Original Message-
> > From: Michael Herndon
> > Sent: Wednesday, September 07, 2011 5:12 AM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: [Lucene.Net] 2.9.4
> >
> > > What version is going to make it to nuget? 2.9.4 or 2.9.4g?
> > ooo totally forgot about nuget. we definitely need to get that setup.
> >
> >
> > On Wed, Sep 7, 2011 at 6:46 AM, digy digy  wrote:
> >
> > > Since it includes some level of divergence from java I committed it to
> > only
> > > 2.9.4g branch.
> > >
> > > https://issues.apache.org/jira/browse/LUCENE-1930
> > > https://issues.apache.org/jira/browse/LUCENENET-431
> > >
> > > DIGY
> > >
> > > On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko  > > >wrote:
> > >
> > > > Ok, core compiles, and all tests pass. We are now running long tests to
> > > > measure memory usage among other things.
> > > >
> > > > There is one show stopper tho. There was a patch sent by Matt Warren
> > for
> > > > Spatial.Net, that doesn't seem to be in. See
> > > > http://groups.google.com/group/ravendb/msg/7517f095810c48f3
> > > >
> > > > Any chance you can get it in to 2.9.4?
> > > >
> > > > On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko  > > > >wrote:
> > > >
> > > > > Ok, great, we will run RavenDB on top of 2.9.4 in the next few days
> > and
> > > > > will let you know how it went.
> > > > >
> > > > >
> > > > > On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon <
> > > > > mhern...@wickedsoftware.net> wrote:
> > > > >
> > > > >> I can't tell if the apache git mirror is updated via scheduler or
> > from
> > > > >> commit hooks, but its generally stays close to being on par with
> > svn.
> > > > >> I'll
> > > > >> check next time I push something to svn.
> > > > >>
> > > > >> But both of those items have made it to the mirror.
> > > > >>
> > > > >> - michael
> > > > >>
> > > > >>
> > > > >> On Tue, Sep 6, 2011 at 1:44 PM, Digy  wrote:
> > > > >>
> > > > >> > I don't know how often github mirror is updated.
> > > > >> > These are the original locations
> > > > >> > 2.9.4
> > https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/
> > > > >> > 2.9.4g
> > > > >> >
> > > > >> >
> > > > >>
> > > >
> > >
> > https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
> > > > >> > 9_4g/
> > > > >> >
> > > > >> > Both versions include ThreadLocal fix + Signing.
> > > > >> >
> > > > >> > Thanks,
> > > > >> > DIGY
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > -Original Message-
> > > > >> > From: itamar.synhers...@gmail.com [mailto:
> > > itamar.synhers...@gmail.com
> > > > ]
> > > > >> On
> > > > >> > Behalf Of Itamar Syn-Hershko
> > > > >> > Sent: Tuesday, September 06, 2011 2:34 AM
> > > > >> > To: lucene-net-dev@lucene.apache.org
> > > > >> > Subject: Re: [Lucene.Net] 2.9.4
> > > > >> >
> > > > >> > Not a problem, we will test RavenDB on a separate branch, also for
> > > > >> > potential
> > > > >> > memory leaks
> > > > >>

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

>
> We should probably fix the ClsCompliance warnings if they have not already
> been fixed 

 

 

We will have some issues with this - some are marked volatile - which basically 
have to be a non-CLS compliant type (as far as my research is finding) Anyone 
have thoughts? I went through and replaced sbyte -> Int16, and uint -> Int64, 
but I'm having an issue with this, and I don't think removing the volatile 
keyword is the right solution.

 

> find a place to put the generated documentation.


We have a folder /trunk/docs, shouldn't this be the place for that?

 

>
> I remember someone mentioning he/she was unable to access a class from
> VB.NET. The class had public fields & properties with the same names but
> different casing. The fields should be private.
>


 

 

> The link in the readme is a dead link:
> http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
> sandcastle & SHFB require a server that allows aspx files to be executed.
> We should either remove the link from the readme or find the docs a new
> home and update the link.


We should generate new documentation and update the link

 

>
> I'll see if I can setup automating Lucene.Net <http://lucene.net> nuget
> package creation for trunk in the next day or so.
>
> - Michael
>
> On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser wrote:
>
> > Hey all seems like we are set with 2.9.4? Feedback has been positive and
> > its been quiet. Do we feel ready to vote for a new release?
> >
> > -Prescott
> >
> > Sent from my Windows Phone

RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts

[Prescott Nasser]

> Right now there are two packages: Lucene & Lucene.Contrib. My question to
> the community is do you wish to finer grain packages, i.e. a package for
> each contrib project or continue to keep it simple.
>


+1 Granular, we just need to be good about descriptions.


>
> Another topic to converse about is would you like to see an out-of-band
> project nuget feed for nightly builds, branches with new or experimental
> features, or stable code snapshots for a projected release?


Having a package for the latest RC would probably be a good idea
  

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

Before I go replacing all the volatile fields I wanted to run this past the 
list:

 

private System.IO.StreamWriter infoStream;


into

 

private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
 get
 {
lock (o)
{
return _infoStream;
}
 }
set
{
lock (o)
{
_infoStream = value;
}
}
 }  

 

 

Sorry, I don't normally deal with locks..

 

Thanks for any guidance

 

~P

>
> @Prescott,
> Can the volatile fields be wrapped in a lock statement and code that access
> those fields with replaced with call to a property /method that wraps access
> to that field?
>
>
>
>
> On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard  wrote:
>
> > I thought it was:
> >
> > 2.9.2 and before are 2.0 compatible
> > 2.9.4 and before are 3.5 compatible
> > After 2.9.4 are 4.0 compatible
> >
> > Thanks,
> > Troy
> >
> > On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
> >  wrote:
> > > if thats the case, then well need conditional statements for including
> > > ThreadLocal
> > >
> > > On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser  > >wrote:
> > >
> > >> I thought this was after 2.9.4
> > >>
> > >> Sent from my Windows Phone
> > >>
> > >> -Original Message-
> > >> From: Michael Herndon
> > >> Sent: Wednesday, September 21, 2011 8:30 AM
> > >> To: lucene-net-dev@lucene.apache.org
> > >> Cc: lucene-net-...@incubator.apache.org
> > >> Subject: Re: [Lucene.Net] 2.9.4
> > >>
> > >> @Robert,
> > >>
> > >> I believe the overwhelming consensus on the mailing list vote was to
> > move
> > >> to
> > >> .NET 4.0 and drop support for previous versions.
> > >>
> > >> I'll take care of build scripts issue while they being refactored into
> > >> smaller chunks this week.
> > >>
> > >> @Troy, Agreed.
> > >>
> > >> On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan  wrote:
> > >>
> > >> > On 20.09.2011 23:48, Prescott Nasser wrote:
> > >> >
> > >> >> Hey all seems like we are set with 2.9.4? Feedback has been positive
> > and
> > >> >> its been quiet. Do we feel ready to vote for a new release?
> > >> >>
> > >> >
> > >> > I don't know if the build infrastructure is part of the
> > >> > release. If yes, then there is an open issue:
> > >> >
> > >> > Contrib doesn't build right now because there
> > >> > are some assembly name mismatches between certain *.csproj
> > >> > files and build/scripts/contrib.targets.
> > >> >
> > >> > The following patches should fix the issue:
> > >> >
> > >> > https://github.com/robert-j/**lucene.net/commit/**
> > >> > c5218bca56c19b3407648224781eec**7316994a39<
> > >>
> > https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
> > >> >
> > >> >
> > >> > https://github.com/robert-j/**lucene.net/commit/**
> > >> > 50bad187655d59968d51d472b57c2a**40e201d663<
> > >>
> > https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
> > >> >
> > >> >
> > >> >
> > >> > Also, the fix for [LUCENENET-358] is basically making
> > >> > Lucene.Net.dll a .NET 4.0-only assembly:
> > >> >
> > >> > https://github.com/apache/**lucene.net/commit/**
> > >> > 23ea6f52362fc7dbce48fd012cea12**9a7350c73c<
> > >>
> > https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
> > >> >
> > >> >
> > >> > Did we agree about abandoning .NET <= 3.5?
> > >> >
> > >> > Robert
> > >> >
> > >> >
> > >>
> > >
> >   

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

The line before had volatile in it..

 

private volatile System.IO.StreamWriter infoStream;


> From: geobmx...@hotmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Thu, 22 Sep 2011 20:14:41 -0700
> Subject: RE: [Lucene.Net] 2.9.4
>
>
> Before I go replacing all the volatile fields I wanted to run this past the 
> list:
>
>
>
> private System.IO.StreamWriter infoStream;
>
>
> into
>
>
>
> private object o = new object();
> private System.IO.StreamWriter _infoStream;
> private System.IO.StreamWriter infoStream
> {
> get
> {
> lock (o)
> {
> return _infoStream;
> }
> }
> set
> {
> lock (o)
> {
> _infoStream = value;
> }
> }
> }
>
>
>
>
>
> Sorry, I don't normally deal with locks..
>
>
>
> Thanks for any guidance
>
>
>
> ~P
>
> >
> > @Prescott,
> > Can the volatile fields be wrapped in a lock statement and code that access
> > those fields with replaced with call to a property /method that wraps access
> > to that field?
> >
> >
> >
> >
> > On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard  wrote:
> >
> > > I thought it was:
> > >
> > > 2.9.2 and before are 2.0 compatible
> > > 2.9.4 and before are 3.5 compatible
> > > After 2.9.4 are 4.0 compatible
> > >
> > > Thanks,
> > > Troy
> > >
> > > On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
> > >  wrote:
> > > > if thats the case, then well need conditional statements for including
> > > > ThreadLocal
> > > >
> > > > On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser  > > >wrote:
> > > >
> > > >> I thought this was after 2.9.4
> > > >>
> > > >> Sent from my Windows Phone
> > > >>
> > > >> -Original Message-
> > > >> From: Michael Herndon
> > > >> Sent: Wednesday, September 21, 2011 8:30 AM
> > > >> To: lucene-net-dev@lucene.apache.org
> > > >> Cc: lucene-net-...@incubator.apache.org
> > > >> Subject: Re: [Lucene.Net] 2.9.4
> > > >>
> > > >> @Robert,
> > > >>
> > > >> I believe the overwhelming consensus on the mailing list vote was to
> > > move
> > > >> to
> > > >> .NET 4.0 and drop support for previous versions.
> > > >>
> > > >> I'll take care of build scripts issue while they being refactored into
> > > >> smaller chunks this week.
> > > >>
> > > >> @Troy, Agreed.
> > > >>
> > > >> On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan  wrote:
> > > >>
> > > >> > On 20.09.2011 23:48, Prescott Nasser wrote:
> > > >> >
> > > >> >> Hey all seems like we are set with 2.9.4? Feedback has been positive
> > > and
> > > >> >> its been quiet. Do we feel ready to vote for a new release?
> > > >> >>
> > > >> >
> > > >> > I don't know if the build infrastructure is part of the
> > > >> > release. If yes, then there is an open issue:
> > > >> >
> > > >> > Contrib doesn't build right now because there
> > > >> > are some assembly name mismatches between certain *.csproj
> > > >> > files and build/scripts/contrib.targets.
> > > >> >
> > > >> > The following patches should fix the issue:
> > > >> >
> > > >> > https://github.com/robert-j/**lucene.net/commit/**
> > > >> > c5218bca56c19b3407648224781eec**7316994a39<
> > > >>
> > > https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
> > > >> >
> > > >> >
> > > >> > https://github.com/robert-j/**lucene.net/commit/**
> > > >> > 50bad187655d59968d51d472b57c2a**40e201d663<
> > > >>
> > > https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
> > > >> >
> > > >> >
> > > >> >
> > > >> > Also, the fix for [LUCENENET-358] is basically making
> > > >> > Lucene.Net.dll a .NET 4.0-only assembly:
> > > >> >
> > > >> > https://github.com/apache/**lucene.net/commit/**
> > > >> > 23ea6f52362fc7dbce48fd012cea12**9a7350c73c<
> > > >>
> > > https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
> > > >> >
> > > >> >
> > > >> > Did we agree about abandoning .NET <= 3.5?
> > > >> >
> > > >> > Robert
> > > >> >
> > > >> >
> > > >>
> > > >
> > > 

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

I see, so you're essentially saying, I can simply remove the volatile keyword 
in this case, and it's exactly the same becuase I am only using it for read and 
writes?

 

So the case I'd need to be more careful of is if an manipulation method is 
called on the object itself - suppose:

 

public person {

_name = "Me"   

 

public changeName(string n)

{

   _name = n;

}

 

}

 

If one were to write 

 

public volatile person p = new person();

p.changeName("You");

 

the call to the method would in this case need a lock (which volatile gives) to 
gaurentee that changeName occurs before other items read or overwrite variable 
p?

 

but a straight read or write won't matter:

 

p = new person();

p = new person():

x = p;

p = new person();

 

Here, I wouldn't need the volatile keyword becuase those are merely reads and 
wrights?



> CC: lucene-net-dev@lucene.apache.org
> From: casper...@caspershouse.com
> Date: Thu, 22 Sep 2011 23:58:42 -0400
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] 2.9.4
>
> Prescott,
>
> You really don't need to do that; reads and writes of reference fields are 
> guaranteed to be atomic as per section 5.5 of the C# Language Specufication 
> (Atomicity of variable references)
>
> If you were doing other operations beyond the read and write that you wanted 
> to be atomic, then the lock statement is appropriate, but in this case it's 
> not.
>
> The volatile keyword in this case (assuming no lock) would absolutely be 
> needed to guarantee that the variable has the most up-to-date value at the 
> time of access; using lock does this for you and makes volatile unnecessary.
>
> - Nick
>
>
>
> On Sep 22, 2011, at 11:14 PM, Prescott Nasser  wrote:
>
> >
> > Before I go replacing all the volatile fields I wanted to run this past the 
> > list:
> >
> >
> >
> > private System.IO.StreamWriter infoStream;
> >
> >
> > into
> >
> >
> >
> > private object o = new object();
> > private System.IO.StreamWriter _infoStream;
> > private System.IO.StreamWriter infoStream
> > {
> > get
> > {
> > lock (o)
> > {
> > return _infoStream;
> > }
> > }
> > set
> > {
> > lock (o)
> > {
> > _infoStream = value;
> > }
> > }
> > }
> >
> >
> >
> >
> >
> > Sorry, I don't normally deal with locks..
> >
> >
> >
> > Thanks for any guidance
> >
> >
> >
> > ~P
> >
> >>
> >> @Prescott,
> >> Can the volatile fields be wrapped in a lock statement and code that access
> >> those fields with replaced with call to a property /method that wraps 
> >> access
> >> to that field?
> >>
> >>
> >>
> >>
> >> On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard  wrote:
> >>
> >>> I thought it was:
> >>>
> >>> 2.9.2 and before are 2.0 compatible
> >>> 2.9.4 and before are 3.5 compatible
> >>> After 2.9.4 are 4.0 compatible
> >>>
> >>> Thanks,
> >>> Troy
> >>>
> >>> On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
> >>>  wrote:
> >>>> if thats the case, then well need conditional statements for including
> >>>> ThreadLocal
> >>>>
> >>>> On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser  >>>> wrote:
> >>>>
> >>>>> I thought this was after 2.9.4
> >>>>>
> >>>>> Sent from my Windows Phone
> >>>>>
> >>>>> -Original Message-
> >>>>> From: Michael Herndon
> >>>>> Sent: Wednesday, September 21, 2011 8:30 AM
> >>>>> To: lucene-net-dev@lucene.apache.org
> >>>>> Cc: lucene-net-...@incubator.apache.org
> >>>>> Subject: Re: [Lucene.Net] 2.9.4
> >>>>>
> >>>>> @Robert,
> >>>>>
> >>>>> I believe the overwhelming consensus on the mailing list vote was to
> >>> move
> >>>>> to
> >>>>> .NET 4.0 and drop support for previous versions.
> >>>>>
> >>>>> I'll take care of build scripts issue while they being refactored into
> >>>>> smaller chunks this week.
> >>>>>
> >>>>> @Troy, Agreed.
> >>>>>
> >>>>&g

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

That helps thanks. No Jira although I will put one in.

Sent from my Windows Phone

-Original Message-
From: casper...@caspershouse.com
Sent: Friday, September 23, 2011 6:05 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] 2.9.4

Prescott,


You can do one of two things:


- Remove the volatile keyword, but keep the lock statement around the
access to the field

- Remove the lock, and add the volatile keyword to the field


This will allow you to assign to the _infoStream variable (read/write) and
be sure to have the most up-to-date value in the variable, as well as
guarantee atomic reads/writes to that variable.


Your example is incorrect.  The volatile on "p" only guarantees that
reads/writes will be current if p is changed.  In other words, if you
assign a new person instance to p, you can do so without using a lock
statement and guarantee that the reads/writes from p will be atomic.


However, any calls you make to p are not protected, not because of
volatile.  Volatile will *never* be able to protect calls, it only protects
variables.


Lock, on the other hand, can protect calls, assuming that you cover all the
calls with the same lock.  You can also group other operations and make
sure that synchronization occurs.


Note that a lock *only* guarantees atomicity/mutual exclusion; when applied
to multiple statements, there's no guarantee that you won't corrupt
something.  If an exception is thrown inside of a lock statement (the
second line in three lines of code in the lock block, for example) then the
previous values don't roll back or anything.


Because atomicity with a variable assignment is mutually exclusive around
*one* operation, there's no chance of corruption.


Let me know if you want further clarification.


Additionally, if you have a specific patch/issue in JIRA you want me to
look at, let me know, I'll let you know if the solution is right from a
thread-safety point of view.


- Nick

--------

From: "Prescott Nasser" 

Sent: Friday, September 23, 2011 1:17 AM

To: lucene-net-dev@lucene.apache.org

Subject: RE: [Lucene.Net] 2.9.4


I see, so you're essentially saying, I can simply remove the volatile
keyword in this case, and it's exactly the same becuase I am only using it
for read and writes?


So the case I'd need to be more careful of is if an manipulation method is
called on the object itself - suppose:


public person {


_name = "Me"


public changeName(string n)


{


_name = n;


}


}


If one were to write


public volatile person p = new person();


p.changeName("You");


the call to the method would in this case need a lock (which volatile
gives) to gaurentee that changeName occurs before other items read or
overwrite variable p?


but a straight read or write won't matter:


p = new person();


p = new person():


x = p;


p = new person();


Here, I wouldn't need the volatile keyword becuase those are merely reads
and wrights?




> CC: lucene-net-dev@lucene.apache.org

> From: casper...@caspershouse.com

> Date: Thu, 22 Sep 2011 23:58:42 -0400

> To: lucene-net-dev@lucene.apache.org

> Subject: Re: [Lucene.Net] 2.9.4

>

> Prescott,

>

> You really don't need to do that; reads and writes of reference fields
are guaranteed to be atomic as per section 5.5 of the C# Language
Specufication (Atomicity of variable references)

>

> If you were doing other operations beyond the read and write that you
wanted to be atomic, then the lock statement is appropriate, but in this
case it's not.

>

> The volatile keyword in this case (assuming no lock) would absolutely be
needed to guarantee that the variable has the most up-to-date value at the
time of access; using lock does this for you and makes volatile
unnecessary.

>

> - Nick

>

>

>

> On Sep 22, 2011, at 11:14 PM, Prescott Nasser 
wrote:

>

> >

> > Before I go replacing all the volatile fields I wanted to run this past
the list:

> >

> >

> >

> > private System.IO.StreamWriter infoStream;

> >

> >

> > into

> >

> >

> >

> > private object o = new object();

> > private System.IO.StreamWriter _infoStream;

> > private System.IO.StreamWriter infoStream

> > {

> > get

> > {

> > lock (o)

> > {

> > return _infoStream;

> > }

> > }

> > set

> > {

> > lock (o)

> > {

> > _infoStream = value;

> > }

> > }

> > }

> >

> >

> >

> >

> >

> > Sorry, I don't normally deal with locks..

> >

> >

> >

> > Thanks for any guidance

> >

> >

> >

> > ~P

> >

> >&g

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

Alright, I've really dug into changing a lot of the non CLS stuff - but I don't 
think it's worth doing for 2.9.4. Please see 
https://issues.apache.org/jira/browse/LUCENENET-446 for more details.

 

Unless anyone disagrees and still thinks we should attempt to clear the CLS 
warnings - is there anything else holding us up from a 2.9.4 release at this 
point?

 

~P



> From: casper...@caspershouse.com
> To: geobmx...@hotmail.com; lucene-net-dev@lucene.apache.org
> Date: Fri, 23 Sep 2011 06:33:03 -0700
> Subject: RE: [Lucene.Net] 2.9.4
>
> NP
>
> ----
>
> From: "Prescott Nasser" 
>
> Sent: Friday, September 23, 2011 9:31 AM
>
> To: lucene-net-dev@lucene.apache.org, casper...@caspershouse.com
>
> Subject: RE: [Lucene.Net] 2.9.4
>
>
> That helps thanks. No Jira although I will put one in.
>
>
> Sent from my Windows Phone
>
>
> -Original Message-
>
> From: casper...@caspershouse.com
>
> Sent: Friday, September 23, 2011 6:05 AM
>
> To: lucene-net-dev@lucene.apache.org
>
> Subject: RE: [Lucene.Net] 2.9.4
>
>
> Prescott,
>
>
> You can do one of two things:
>
>
> - Remove the volatile keyword, but keep the lock statement around the
>
> access to the field
>
>
> - Remove the lock, and add the volatile keyword to the field
>
>
> This will allow you to assign to the _infoStream variable (read/write) and
>
> be sure to have the most up-to-date value in the variable, as well as
>
> guarantee atomic reads/writes to that variable.
>
>
> Your example is incorrect. The volatile on "p" only guarantees that
>
> reads/writes will be current if p is changed. In other words, if you
>
> assign a new person instance to p, you can do so without using a lock
>
> statement and guarantee that the reads/writes from p will be atomic.
>
>
> However, any calls you make to p are not protected, not because of
>
> volatile. Volatile will *never* be able to protect calls, it only
> protects
>
> variables.
>
>
> Lock, on the other hand, can protect calls, assuming that you cover all
> the
>
> calls with the same lock. You can also group other operations and make
>
> sure that synchronization occurs.
>
>
> Note that a lock *only* guarantees atomicity/mutual exclusion; when
> applied
>
> to multiple statements, there's no guarantee that you won't corrupt
>
> something. If an exception is thrown inside of a lock statement (the
>
> second line in three lines of code in the lock block, for example) then
> the
>
> previous values don't roll back or anything.
>
>
> Because atomicity with a variable assignment is mutually exclusive around
>
> *one* operation, there's no chance of corruption.
>
>
> Let me know if you want further clarification.
>
>
> Additionally, if you have a specific patch/issue in JIRA you want me to
>
> look at, let me know, I'll let you know if the solution is right from a
>
> thread-safety point of view.
>
>
> - Nick
>
>
> 
>
>
> From: "Prescott Nasser" 
>
>
> Sent: Friday, September 23, 2011 1:17 AM
>
>
> To: lucene-net-dev@lucene.apache.org
>
>
> Subject: RE: [Lucene.Net] 2.9.4
>
>
> I see, so you're essentially saying, I can simply remove the volatile
>
> keyword in this case, and it's exactly the same becuase I am only using it
>
> for read and writes?
>
>
> So the case I'd need to be more careful of is if an manipulation method is
>
> called on the object itself - suppose:
>
>
> public person {
>
>
> _name = "Me"
>
>
> public changeName(string n)
>
>
> {
>
>
> _name = n;
>
>
> }
>
>
> }
>
>
> If one were to write
>
>
> public volatile person p = new person();
>
>
> p.changeName("You");
>
>
> the call to the method would in this case need a lock (which volatile
>
> gives) to gaurentee that changeName occurs before other items read or
>
> overwrite variable p?
>
>
> but a straight read or write won't matter:
>
>
> p = new person();
>
>
> p = new person():
>
>
> x = p;
>
>
> p = new person();
>
>
> Here, I wouldn't need the volatile keyword becuase those are merely reads
>
> and wrights?
>
>
> 
>
>
> > CC: lucene-net-dev@lucene.apache.org
>
>
> > From: casper...@caspershouse.com
>
>
> > Date: Thu, 22 Sep 2011 23:58:42 -0

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

I was looking into the possibility of making it cls compliant - but that's 
really out the window for this. I think we're ready, i just dont know the 
procedures to call a vote.

Sent from my Windows Phone

From: Itamar Syn-Hershko
Sent: 10/3/2011 2:08 AM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4

Hi guys,

What's the status of this? Is there anything I can do to help to wrap
everything up and make a release?

You can also grab whatever you want from
https://github.com/synhershko/Lucene.Net.Contrib - send me the docs you want
me to sign.

Itamar.

On Tue, Sep 20, 2011 at 11:48 PM, Prescott Nasser wrote:

> Hey all seems like we are set with 2.9.4? Feedback has been positive and
> its been quiet. Do we feel ready to vote for a new release?
>
> -Prescott
>
> Sent from my Windows Phone

[Lucene.Net] 2.9.4 RC1

[Prescott Nasser]

Alright- this took me way too long, I'm sorry for that. 

 

Could you guys please take a look at: 
http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/ hopefully 
I've done this right, once you guys think it looks good, I'd like to call a 
vote to release this 

 

~Prescott 

RE: [Lucene.Net] 2.9.4 RC1

[Prescott Nasser]

Done - i've uploaded the new files to the same place. I actually found an issue 
with the bin.zip file, so it was good that I merged that bug fix in.

 

If you guys don't mind taking a look, I'd like to submit it to the incubator 
mailing list for a vote tomorrow if we have no issues with these

 

~Prescott


> Date: Mon, 31 Oct 2011 01:14:52 +0200
> From: ita...@code972.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] 2.9.4 RC1
>
> Any chance you guys fix and merge this
> https://issues.apache.org/jira/browse/LUCENENET-450 before releasing?
>
> On Sun, Oct 30, 2011 at 11:12 PM, Prescott Nasser 
> wrote:
>
> >
> >
> >
> > Alright- this took me way too long, I'm sorry for that.
> >
> >
> >
> > Could you guys please take a look at:
> > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/hopefully 
> > I've done this right, once you guys think it looks good, I'd like
> > to call a vote to release this
> >
> >
> >
> > ~Prescott
> >   

RE: [Lucene.Net] 2.9.4 RC1

[Prescott Nasser]

>
> > Done - i've uploaded the new files to the same place. I actually found
> > an issue with the bin.zip file, so it was good that I merged that bug
> > fix in.
>
> I'm pretty sure you know that, but if you decide to do something like
> this after you've started the vote, please cancel the vote, bump the RC
> number and start a new vote.


Check

 

>
> > If you guys don't mind taking a look, I'd like to submit it to the
> > incubator mailing list for a vote tomorrow if we have no issues with
> > these
>
> Start a VOTE thread on this list and if it passes go to the general
> list. If all mentors vote on this list the VOTE on the general list is
> more informational than anything else.
>

 

Done!


> I'll look into the ZIPs myself in a few hours so you'll know how I'm
> going to vote 8-)
>
> Stefan  

[Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Prescott Nasser]

Artifacts are located here: 
http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/


If the vote passes here, I will move the artifacts to staging and call a vote 
on the general incubator mailing list

 

Please verify the release and cast your vote.  The vote will be open for 72 
hours.

[ ] +1
[ ]  0
[ ] -1

 

 

~Prescott 

RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Prescott Nasser]

+1



> From: geobmx...@hotmail.com
> To: lucene-net-dev@lucene.apache.org
> Date: Sun, 30 Oct 2011 22:08:32 -0700
> Subject: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
>
>
> Artifacts are located here: 
> http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
>
>
> If the vote passes here, I will move the artifacts to staging and call a vote 
> on the general incubator mailing list
>
>
>
> Please verify the release and cast your vote. The vote will be open for 72 
> hours.
>
> [ ] +1
> [ ] 0
> [ ] -1
>
>
>
>
>
> ~Prescott   

RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Prescott Nasser]

bleh - forgot to update the branch.

 

And yay for windows hiding those svn files.. 

 

I'll give it a day or so and see what others might say then update it and call 
a new vote.

 

Thanks for taking the time to review

 

~P


> From: bode...@apache.org
> To: lucene-net-...@incubator.apache.org
> Date: Mon, 31 Oct 2011 07:00:08 +0100
> Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
>
> On 2011-10-31, Prescott Nasser wrote:
>
> > Artifacts are located here:
> > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
>
> Is there a tag in svn that is supposed to correspond to them? My guess
> is <http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/>.
> But then I find
>
> diff -ur svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 
> Apache-Lucene.Net-2.
> 9.4-incubating-RC1.src/src/contrib/Similarity/Similar/MoreLikeThis.cs
> --- svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 2011-04-23 
> 01:53:05.3476
> 64000 +0200
> +++ 
> Apache-Lucene.Net-2.9.4-incubating-RC1.src/src/contrib/Similarity/Similar/Mo
> reLikeThis.cs 2011-10-30 19:35:42.0 +0100
> @@ -769,7 +769,7 @@
> {
> for (int j = 0; j < text.Length; j++)
> {
> - AddTermFrequencies(new System.IO.StreamReader(text[
> j]), termFreqMap, fieldName);
> + AddTermFrequencies(new System.IO.StringReader(text[
> j]), termFreqMap, fieldName);
> }
> }
> }
> @@ -820,7 +820,7 @@
> /// 
> /// Used by analyzer for any special per-field
> analysis
> /// 
> - private void AddTermFrequencies(System.IO.StreamReader r, 
> System.Collections.IDictionary termFreqMap, System.String fieldName)
> + private void AddTermFrequencies(System.IO.TextReader r, 
> System.Collections.IDictionary termFreqMap, System.String fieldName)
> {
> TokenStream ts = analyzer.TokenStream(fieldName, r);
> Lucene.Net.Analysis.Token token;
>
> so they don't match.
>
> The src ZIP doesn't contain build.cmd nor the doc and lib folders. Is
> this intentional?
>
> Signatures and checksums match.
>
> The src ZIP contains .svn folders which I don't think they should. No
> biggie just something to fix for the next release or RC. Same for some
> .suo files and obj folders.
>
> The binary distribution needs LICENSE.txt and NOTICE.txt that I can't
> seem to find. This forces a -1 from me.
>
> The only other test I'd perform was running RAT which I'll do shortly
> and post the results here.
>
> Stefan