Re: twitter questions

[Michael Herndon]

@wyatt,

Part of the problem was that notifications were just set to "by people
I follow" vs "by anyone" so that is now fixed.



On Mon, Aug 20, 2012 at 11:03 AM, Wyatt Barnett  wrote:
> Without getting all social media saavy like Itamar here you can
> automate that pretty easily.
>
> I've got no idea what email account is backing the @LuceneDotNet, but
> you can setup twitter to automatically email you when you are
> mentioned (ie -- someone puts @LuceneDotNet in a tweet); should be
> pretty trivial to setup a mail forwarding rule that forwards these to
> the list.
>
> Slightly fancier would be to use twitter's search API to search for
> tweets mentioning @LuceneDotNet which could be grabbed, formatted and
> mailed to the list.
>
> Downside is that, once we get some decent twitter traffic going we'll
> get bad signal to noise ratios. Hard to identify questions versus "hey
> @LuceneDotNet look what I did".
>
> On Mon, Aug 20, 2012 at 10:55 AM, Itamar Syn-Hershko  
> wrote:
>> Get MetroTwit or TwitDeck and create your own Twitter account while at it :)
>>
>> On Mon, Aug 20, 2012 at 5:52 PM, Prescott Nasser 
>> wrote:
>>
>>> I'm terrible with social media- is there any way to have tweets directed
>>> at @LuceneDotNet sent to one of our mailing lists? Or should I just get on
>>> top of monitoring it more often?
>>>
>>> > From: casper...@caspershouse.com
>>> > To: lucene-net-dev@lucene.apache.org
>>> > CC: lucene-net-dev@lucene.apache.org
>>> > Subject: Re: twitter questions
>>> > Date: Mon, 20 Aug 2012 14:46:57 +
>>> >
>>> > Answered:
>>> >
>>> > http://stackoverflow.com/a/12039811/50776
>>> >
>>> >
>>> >
>>> > On Aug 20, 2012, at 10:42 AM, "Michael Herndon" <
>>> mhern...@wickedsoftware.net> wrote:
>>> >
>>> > > Thanks Nicholas for having a look at the SO question. Anyone know
>>> > > about the NIOFSDirectory off the top of their head?
>>> > >
>>> > > Cheers,
>>> > > Michael
>>> > >
>>> > >
>>> > >
>>> > > On Mon, Aug 20, 2012 at 10:28 AM, Nicholas Paldino [.NET/C# MVP]
>>> > >  wrote:
>>> > >> I've also found the question on SO, I'll give it a shot later today.
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Aug 20, 2012, at 10:18 AM, "Michael Herndon" <
>>> mhern...@wickedsoftware.net> wrote:
>>> > >>
>>> > >>> I went to update the twitter feed and saw these questions in case
>>> > >>> anyone wants to answer these:
>>> > >>>
>>> > >>> @Nick_Craver
>>> > >>> @LuceneDotNet - is anyone already working on a NIOFSDirectory port?
>>> > >>> Unless I misunderstand, it would be a huge boost to our SSD
>>> > >>> environment'
>>> > >>>
>>> > >>> @intelligibabble
>>> > >>> would love it if some #lucene or @LuceneDotNet gurus took a look at
>>> my
>>> > >>> SO question stackoverflow.com/questions/1135…
>>> > >>>
>>> http://stackoverflow.com/questions/11354455/using-lucene-net-thread-safe-from-asp-net-web-application
>>> > >>>
>>> > >>
>>> > >
>>> >
>>>
>>>

Re: twitter questions

[Michael Herndon]

Prescott, you already handle enough of the load as it is. I've dropped
the ball on social media thing, I'll make sure things get posted on
the list from here on out.

If we send notifications to the mailing list, my guess is that it
would be security issue with password reset notifications and such, so
we don't want to go that route.






On Mon, Aug 20, 2012 at 10:52 AM, Prescott Nasser  wrote:
> I'm terrible with social media- is there any way to have tweets directed at 
> @LuceneDotNet sent to one of our mailing lists? Or should I just get on top 
> of monitoring it more often?
>
>> From: casper...@caspershouse.com
>> To: lucene-net-dev@lucene.apache.org
>> CC: lucene-net-dev@lucene.apache.org
>> Subject: Re: twitter questions
>> Date: Mon, 20 Aug 2012 14:46:57 +
>>
>> Answered:
>>
>> http://stackoverflow.com/a/12039811/50776
>>
>>
>>
>> On Aug 20, 2012, at 10:42 AM, "Michael Herndon" 
>>  wrote:
>>
>> > Thanks Nicholas for having a look at the SO question. Anyone know
>> > about the NIOFSDirectory off the top of their head?
>> >
>> > Cheers,
>> > Michael
>> >
>> >
>> >
>> > On Mon, Aug 20, 2012 at 10:28 AM, Nicholas Paldino [.NET/C# MVP]
>> >  wrote:
>> >> I've also found the question on SO, I'll give it a shot later today.
>> >>
>> >>
>> >>
>> >> On Aug 20, 2012, at 10:18 AM, "Michael Herndon" 
>> >>  wrote:
>> >>
>> >>> I went to update the twitter feed and saw these questions in case
>> >>> anyone wants to answer these:
>> >>>
>> >>> @Nick_Craver
>> >>> @LuceneDotNet - is anyone already working on a NIOFSDirectory port?
>> >>> Unless I misunderstand, it would be a huge boost to our SSD
>> >>> environment'
>> >>>
>> >>> @intelligibabble
>> >>> would love it if some #lucene or @LuceneDotNet gurus took a look at my
>> >>> SO question stackoverflow.com/questions/1135…
>> >>> http://stackoverflow.com/questions/11354455/using-lucene-net-thread-safe-from-asp-net-web-application
>> >>>
>> >>
>> >
>>
>

Re: Graduation

[Michael Herndon]

can we post this on twitter?

On Wed, Aug 15, 2012 at 6:46 PM, Prescott Nasser wrote:

> Hey All -
> Just an FYI, the board voted unanimously to allow us to graduate. I will
> push forward with the various tasks in the next week.
> Congrats to everyone who has helped us get this far -
> ~Prescott

Re: Lucene.NET 3.0.3 Build issues

[Michael Herndon]

, the nifty new vs feature find of the day goes to Mr. Currens.

I've been using it for tons of JavaScript style development with requireJS,
kendo, my own set of scripts, and custom stuff for the day job. It actually
provides intellisense for JS inheritance so life is good.




On Thu, Aug 9, 2012 at 1:43 AM, Christopher Currens  wrote:

> It used to be that way.  VS2012 is the first version that produces
> backwards compatible projects *and* solutions.  There's an msdn blog
> entry[1] that discusses it. It does focus more projects, but starts with
> discussing solutions and how having it all backwards compatible would ease
> transitions for most companies.  There are a few project types that aren't
> backwards compatible, but I think the solution will still open in both,
> with a notification that it can't load the project type.
>
> Excerpt: "In other words, we now have project round-tripping capability so
> you can work with the latest features but still keep the solution
> compatible with team members using an older version of Visual Studio."
>
> Anyway, it's about time they did this.  Supporting multiple versions of VS
> files has been an annoying missing feature.
>
> [1]
>
> http://blogs.msdn.com/b/zainnab/archive/2012/06/05/visual-studio-2012-compatibility-aka-project-round-tripping.aspx
>
>
> On Wed, Aug 8, 2012 at 5:41 PM, Michael Herndon <
> mhern...@wickedsoftware.net
> > wrote:
>
> > I think it's usually the project files that are backwards compatible not
> > the solution files. So you need a solution for each vs version but should
> > be able to keep the proj files the same.
> >
> > On Wed, Aug 8, 2012 at 7:27 PM, Prescott Nasser  > >wrote:
> >
> > > Yes
> > >
> > > Sent from my Windows Phone
> > > 
> > > From: Christopher Currens
> > > Sent: 8/8/2012 4:22 PM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: Re: Lucene.NET 3.0.3 Build issues
> > >
> > > Oh, did you do that so we'd have a branch to do bug fixes?  I had
> > forgotten
> > > about that.
> > >
> > > On Wed, Aug 8, 2012 at 2:23 PM, Prescott Nasser  > > >wrote:
> > >
> > > > I just created 3.0.3 last weekend - it should be incredibly up to
> date.
> > > > Anything in trunk should be there
> > > >
> > > > Sent from my Windows Phone
> > > > 
> > > > From: Christopher Currens
> > > > Sent: 8/8/2012 1:35 PM
> > > > To: lucene-net-dev@lucene.apache.org
> > > > Subject: Re: Lucene.NET 3.0.3 Build issues
> > > >
> > > > Thanks for the feedback.  Let us know if you run into any more
> > > > issues/concerns.
> > > >
> > > >
> > > > Thanks,
> > > > Christopher
> > > >
> > > > On Wed, Aug 8, 2012 at 1:33 PM, Granroth, Neal V. <
> > > > neal.granr...@thermofisher.com> wrote:
> > > >
> > > > > Yes I pulled from the branch not the trunk. I apparently made the
> > > > > incorrect assumption that it would be slightly more stable than the
> > > > current
> > > > > work-in-progress.
> > > > >
> > > > > Thanks for the quick attention and clarifications.  Especially for
> > > those
> > > > > that rely upon the binary packages.
> > > > >
> > > > > - Neal
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Christopher Currens [mailto:currens.ch...@gmail.com]
> > > > > Sent: Wednesday, August 08, 2012 3:21 PM
> > > > > To: lucene-net-dev@lucene.apache.org
> > > > > Subject: Re: Lucene.NET 3.0.3 Build issues
> > > > >
> > > > > FYI - SVN has been updated with corrected VS2010 solutions and
> added
> > > > VS2012
> > > > > directory/solution files.
> > > > >
> > > > > On Wed, Aug 8, 2012 at 1:12 PM, Christopher Currens <
> > > > > currens.ch...@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > See inline comments.
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Christopher
> > > > > >
> > > > > > On Wed, Aug 8, 2012 at 12:07 PM, Granroth, Neal V. <
> > > > > > neal.granr.

Re: Lucene.NET 3.0.3 Build issues

[Michael Herndon]

I think it's usually the project files that are backwards compatible not
the solution files. So you need a solution for each vs version but should
be able to keep the proj files the same.

On Wed, Aug 8, 2012 at 7:27 PM, Prescott Nasser wrote:

> Yes
>
> Sent from my Windows Phone
> 
> From: Christopher Currens
> Sent: 8/8/2012 4:22 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: Lucene.NET 3.0.3 Build issues
>
> Oh, did you do that so we'd have a branch to do bug fixes?  I had forgotten
> about that.
>
> On Wed, Aug 8, 2012 at 2:23 PM, Prescott Nasser  >wrote:
>
> > I just created 3.0.3 last weekend - it should be incredibly up to date.
> > Anything in trunk should be there
> >
> > Sent from my Windows Phone
> > 
> > From: Christopher Currens
> > Sent: 8/8/2012 1:35 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: Lucene.NET 3.0.3 Build issues
> >
> > Thanks for the feedback.  Let us know if you run into any more
> > issues/concerns.
> >
> >
> > Thanks,
> > Christopher
> >
> > On Wed, Aug 8, 2012 at 1:33 PM, Granroth, Neal V. <
> > neal.granr...@thermofisher.com> wrote:
> >
> > > Yes I pulled from the branch not the trunk. I apparently made the
> > > incorrect assumption that it would be slightly more stable than the
> > current
> > > work-in-progress.
> > >
> > > Thanks for the quick attention and clarifications.  Especially for
> those
> > > that rely upon the binary packages.
> > >
> > > - Neal
> > >
> > >
> > > -Original Message-
> > > From: Christopher Currens [mailto:currens.ch...@gmail.com]
> > > Sent: Wednesday, August 08, 2012 3:21 PM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: Re: Lucene.NET 3.0.3 Build issues
> > >
> > > FYI - SVN has been updated with corrected VS2010 solutions and added
> > VS2012
> > > directory/solution files.
> > >
> > > On Wed, Aug 8, 2012 at 1:12 PM, Christopher Currens <
> > > currens.ch...@gmail.com
> > > > wrote:
> > >
> > > > See inline comments.
> > > >
> > > >
> > > > Thanks,
> > > > Christopher
> > > >
> > > > On Wed, Aug 8, 2012 at 12:07 PM, Granroth, Neal V. <
> > > > neal.granr...@thermofisher.com> wrote:
> > > >
> > > >> I just pulled down the 3.0.3 branch from SVN and have encountered an
> > > >> initial problem with the VisualStudio solution file
> > Lucene.Net.Core.sln
> > > in
> > > >> the VS2010 folder.
> > > >>
> > > >> Did you pull down the 3.0.3 branch or trunk?  Trunk is 3.0.3, I'm
> not
> > > > even sure the 3.0.3 branch exists anymore, and if it does, it is
> very,
> > > very
> > > > out of date.
> > > >
> > > >
> > > >> This solution will not load in VS2010, Visual Studio complains that
> it
> > > >> was created with a newer version.
> > > >> Opening the solution file in notepad reveals that it was created
> with
> > > >> VS2012 (a not yet released product)
> > > >>
> > > >> They are supposed to be VS2010, if the pathing didn't give it away.
>  I
> > > > believe it was my fault, as I usually will change them back to VS2010
> > > > manually, but forgot to do that while I was adding .NET 3.5 support
> > back
> > > > in.  In order to automate the change, I needed to use the RC and
> forgot
> > > to
> > > > change the solution files back. As an aside, VS2012 solution files
> are
> > > (or
> > > > at least supposed to be) backwards compatible with VS2010.  On my
> > laptop,
> > > > which only has VS2010 SP1, they open and compile just fine.
> > > >
> > > >
> > > >> It would be very helpful if those maintaining the source
> distribution
> > > >> limit themselves to released development tools only.
> > > >>
> > > >> Since that's our normal policy, this isn't really an issue.
> > > >
> > > >
> > > >> It also make me wonder of the viability of any binary distributions;
> > > they
> > > >> certainly should not have been created with VS2012RC
> > > >>
> > > >
> > > > Prescott used VS2010 to make the binary, so I don't think you need to
> > > > worry about this.
> > > >
> > > >
> > > >>
> > > >> - Neal G.
> > > >>
> > > >>
> > > >
> > >
> >
>

Re: Outstanding issues for 3.0.3

[Michael Herndon]

fork it and git r done? I couldn't resist. +1 for git.



On Thu, Aug 2, 2012 at 3:04 AM, Itamar Syn-Hershko wrote:

> Nowadays git works just great for Windows, and it's much easier to work
> with than Hg
>
> On Wed, Aug 1, 2012 at 9:41 PM, Zachary Gramana  >wrote:
>
> > On Aug 1, 2012, at 12:51 PM, Itamar Syn-Hershko wrote:
> >
> > > And for heaven's sake, can we move to git when graduating?
> >
> > Given that we're a .NET-focused community, and many of us are likely
> > primarily using Windows as both our primary development and deployment
> > platforms, I'd suggest looking at Mercurial before committing to git.
> >
> > Either way, +1 for any DVCS.
> >
>

Re: Why the use of Utils.Paths in TestBackwardsCompability?

[Michael Herndon]

* cause obviously we can not* exactly hard code paths.

On Sun, Jul 29, 2012 at 2:43 PM, Michael Herndon <
mhern...@wickedsoftware.net> wrote:

> to explain further, the shadow copy feature basically copies the test
> assemblies to a different location and executes them from that location.
>  However, to my knowledge it does not copy the file resources. The location
> of where a test assembly is located and execute is not guaranteed which
> makes using relative paths fickle, but its required cause obviously we can
> exactly hard code paths.
>
> Shadow copy breaks using relative paths in test code.  However if you turn
> shadow copy off, then it kills the workflow of writing tests from within
> visual studio since the test assembly is seen being used by another process
> and blocks VS from rebuilding the test assembly which can be really
> frustrating as you would imagine.
>
> The thing to do is attempt to account for all situations so that people
> can download on whatever box using whatever test tools with as little
> friction as possible. I'm open to suggestions.
>
>
>
> On Sun, Jul 29, 2012 at 2:20 PM, Michael Herndon <
> mhern...@wickedsoftware.net> wrote:
>
>> because of the shadow copy feature in nunit.
>>
>> simply using
>> Path.Combine("Index", "index." + oldNames[i]);
>>
>> won't work when the test assemblies are located in funky places.
>>
>> On Sun, Jul 29, 2012 at 4:56 AM, Simon Svensson  wrote:
>>
>>> I'm looking into running the tests in MonoDevelop (Mono 2.10.9) on a
>>> Mac, debugging one failure at a time. The TestBackwardsCompability tests
>>> fails when unzipping because the paths for the source zip files are
>>> incorrectly calculated. It originates in Paths.AssemblyDirectory, where it
>>> returns a rooted path on Windows ("C:\Users\sisve\..."), but a relative
>>> path on Mac ("Users/sisve/...").
>>>
>>> We could use the existing Path.Combine, and choose to copy to
>>> input.xxx.zip files to the output directory. This would remove  the need
>>> for the Paths class completely [if I understand it correctly]. (It's also
>>> used from LuceneTestCase to initialize a variable no-one uses.)
>>>
>>> Old: System.String dirName = Paths.CombinePath(Paths.**ProjectRootDirectory,
>>> "test/core/index/index." + oldNames[i]);
>>> New: System.String dirName = Path.Combine("Index", "index." +
>>> oldNames[i]);
>>>
>>> But this makes me wondering, why was the Paths class introduced at all?
>>>
>>> // Simon
>>>
>>
>>
>

Re: Why the use of Utils.Paths in TestBackwardsCompability?

[Michael Herndon]

to explain further, the shadow copy feature basically copies the test
assemblies to a different location and executes them from that location.
 However, to my knowledge it does not copy the file resources. The location
of where a test assembly is located and execute is not guaranteed which
makes using relative paths fickle, but its required cause obviously we can
exactly hard code paths.

Shadow copy breaks using relative paths in test code.  However if you turn
shadow copy off, then it kills the workflow of writing tests from within
visual studio since the test assembly is seen being used by another process
and blocks VS from rebuilding the test assembly which can be really
frustrating as you would imagine.

The thing to do is attempt to account for all situations so that people can
download on whatever box using whatever test tools with as little friction
as possible. I'm open to suggestions.



On Sun, Jul 29, 2012 at 2:20 PM, Michael Herndon <
mhern...@wickedsoftware.net> wrote:

> because of the shadow copy feature in nunit.
>
> simply using
> Path.Combine("Index", "index." + oldNames[i]);
>
> won't work when the test assemblies are located in funky places.
>
> On Sun, Jul 29, 2012 at 4:56 AM, Simon Svensson  wrote:
>
>> I'm looking into running the tests in MonoDevelop (Mono 2.10.9) on a Mac,
>> debugging one failure at a time. The TestBackwardsCompability tests fails
>> when unzipping because the paths for the source zip files are incorrectly
>> calculated. It originates in Paths.AssemblyDirectory, where it returns a
>> rooted path on Windows ("C:\Users\sisve\..."), but a relative path on Mac
>> ("Users/sisve/...").
>>
>> We could use the existing Path.Combine, and choose to copy to
>> input.xxx.zip files to the output directory. This would remove  the need
>> for the Paths class completely [if I understand it correctly]. (It's also
>> used from LuceneTestCase to initialize a variable no-one uses.)
>>
>> Old: System.String dirName = Paths.CombinePath(Paths.**ProjectRootDirectory,
>> "test/core/index/index." + oldNames[i]);
>> New: System.String dirName = Path.Combine("Index", "index." +
>> oldNames[i]);
>>
>> But this makes me wondering, why was the Paths class introduced at all?
>>
>> // Simon
>>
>
>

Re: Why the use of Utils.Paths in TestBackwardsCompability?

[Michael Herndon]

because of the shadow copy feature in nunit.

simply using
Path.Combine("Index", "index." + oldNames[i]);

won't work when the test assemblies are located in funky places.

On Sun, Jul 29, 2012 at 4:56 AM, Simon Svensson  wrote:

> I'm looking into running the tests in MonoDevelop (Mono 2.10.9) on a Mac,
> debugging one failure at a time. The TestBackwardsCompability tests fails
> when unzipping because the paths for the source zip files are incorrectly
> calculated. It originates in Paths.AssemblyDirectory, where it returns a
> rooted path on Windows ("C:\Users\sisve\..."), but a relative path on Mac
> ("Users/sisve/...").
>
> We could use the existing Path.Combine, and choose to copy to
> input.xxx.zip files to the output directory. This would remove  the need
> for the Paths class completely [if I understand it correctly]. (It's also
> used from LuceneTestCase to initialize a variable no-one uses.)
>
> Old: System.String dirName = Paths.CombinePath(Paths.**ProjectRootDirectory,
> "test/core/index/index." + oldNames[i]);
> New: System.String dirName = Path.Combine("Index", "index." + oldNames[i]);
>
> But this makes me wondering, why was the Paths class introduced at all?
>
> // Simon
>

Re: build scripts

[Michael Herndon]

heh, I thought the peculiar thing was that it was just building the .NET
3.5 version randomly instead of being an actual deliberate change.  I was
trying to think how that was possible. =)


On Sun, Jul 22, 2012 at 2:55 PM, Christopher Currens <
currens.ch...@gmail.com> wrote:

> It is, but I didn't want to deal with changing our CI server configuration
> to get what is a little bit of benefit (at the moment) for the amount of
> time it would have taken me to figure it all out.  At the moment, the kind
> of packaging we need for a release would be both frameworks, so as of now,
> I have it outputting both.  I am not oblivious to the awkwardness of the
> build scripts how they are now, as the most glaringly obvious flaw with
> outputting both, is that nunit runs the tests for .NET35 and .NET4 at the
> same time. There are several things wrong with the way that works.
>
> It's not a hefty change, though, that needs to be done if you wanted to
> change it to a build parameter, I have a mostly finished patch for that
> since that was original first goal.  There's an extra build step that can
> be removed and a variable added to each project page.  The larger(?) change
> would the actual packaging for NUnit.  Even though it's already it's own
> separate target, I'm sure we want to validate that both .NET35 and .NET4
> builds have been run before packaging the output.
>
>
> Thanks,
> Christopher
>
>
> On Sun, Jul 22, 2012 at 11:27 AM, Michael Herndon <
> mhern...@wickedsoftware.net> wrote:
>
> > that is a peculiar behavior.
> >
> > On Sun, Jul 22, 2012 at 4:41 AM, Christopher Currens <
> > currens.ch...@gmail.com> wrote:
> >
> > > Right now, it outputs both automatically.  I didn't put in a switch, it
> > > just does it be default.
> > >
> > >
> > > On Sat, Jul 21, 2012 at 2:38 PM, Michael Herndon <
> > > mhern...@wickedsoftware.net> wrote:
> > >
> > > > you would need create a build variable for the .net framework version
> > > > parameter for msbuild and have it run a second build and switch out
> the
> > > > version.
> > > >
> > > > On Sat, Jul 21, 2012 at 3:08 PM, Prescott Nasser <
> > geobmx...@hotmail.com
> > > > >wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > There was a commit for updating the build scripts - is there a
> > command
> > > I
> > > > > can run to output both 4.0 and 3.5 binaries of everything?
> > > > >
> > > >
> > >
> >
>

Re: build scripts

[Michael Herndon]

that is a peculiar behavior.

On Sun, Jul 22, 2012 at 4:41 AM, Christopher Currens <
currens.ch...@gmail.com> wrote:

> Right now, it outputs both automatically.  I didn't put in a switch, it
> just does it be default.
>
>
> On Sat, Jul 21, 2012 at 2:38 PM, Michael Herndon <
> mhern...@wickedsoftware.net> wrote:
>
> > you would need create a build variable for the .net framework version
> > parameter for msbuild and have it run a second build and switch out the
> > version.
> >
> > On Sat, Jul 21, 2012 at 3:08 PM, Prescott Nasser  > >wrote:
> >
> > >
> > >
> > >
> > >
> > > There was a commit for updating the build scripts - is there a command
> I
> > > can run to output both 4.0 and 3.5 binaries of everything?
> > >
> >
>

[jira] [Commented] (LUCENENET-446) Make Lucene.Net CLS Compliant

[michael herndon (JIRA)]

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

michael herndon commented on LUCENENET-446:
---

That is probably fine for now. We still get a big win here as all your hard 
work so far should get Lucene.Net back to playing nice for VB.Net consumers.  

> Make Lucene.Net CLS Compliant
> -
>
> Key: LUCENENET-446
> URL: https://issues.apache.org/jira/browse/LUCENENET-446
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.4
>Reporter: Prescott Nasser
>Assignee: Prescott Nasser
> Fix For: Lucene.Net 3.0.3, Lucene.Net 3.6
>
> Attachments: Lucene2.9.4-CLS-partial-fix
>
>
> Make Lucene.Net CLS Compliant

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: build scripts

[Michael Herndon]

you would need create a build variable for the .net framework version
parameter for msbuild and have it run a second build and switch out the
version.

On Sat, Jul 21, 2012 at 3:08 PM, Prescott Nasser wrote:

>
>
>
>
> There was a commit for updating the build scripts - is there a command I
> can run to output both 4.0 and 3.5 binaries of everything?
>

Re: Lets talk graduation

[Michael Herndon]

Stefan, I think you've more than proved your value.

Re: broken link to 3.0.3 on website.

[Michael Herndon]

http://incubator.apache.org/lucene.net/download.html   on the downloads page

On Sun, Apr 22, 2012 at 7:35 PM, Prescott Nasser wrote:

>
> 3.0.3 started as a branch while we were releasing 2.9.4. But it was since
> merged into the trunk. Where is the link? we should update it to point to
> the trunk.
>  > Date: Sun, 22 Apr 2012 19:09:18 -0400
> > Subject: broken link to 3.0.3 on website.
> > From: mhern...@wickedsoftware.net
> > To: lucene-net-...@incubator.apache.org
> >
> >
> https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net.3.0.3//
> >
> >
> > is broken link on
> >
> https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net.3.0.3//
> >
> > was there meant to be a -pre release so that users/developers can tinker
> > with the bits?
>
>

broken link to 3.0.3 on website.

[Michael Herndon]

https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net.3.0.3//


is broken link on
https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net.3.0.3//

was there meant to be a -pre release so that users/developers can tinker
with the bits?

Re: user feedback on 3.0.3

[Michael Herndon]

silly question. I script my tweets using powershell and my RMS-styled text
only browser built using C# where all the strings are UTF-16.  Real men use
powershell.

There should be an award for using that much satire and sass within 3
statements or less.

On Fri, Apr 13, 2012 at 2:24 PM, Troy Howard  wrote:

> Michael - How did you manage to get a Unicode dot into your tweet in the
> first place? ;)
>
>
>
> On Fri, Apr 13, 2012 at 10:22 AM, Michael Herndon <
> mhern...@wickedsoftware.net> wrote:
>
> > Done.  For future reference to tweeting things with dots.  We have to use
> > ascii with Lucene.Net on tweets. Otherwise twitter will transform the
> > "Lucene.Net" text into a link that points to its Java counterpart.
> >
> > Lucene.Net
> >
> >
> >
> > On Fri, Apr 13, 2012 at 12:37 PM, Christopher Currens <
> > currens.ch...@gmail.com> wrote:
> >
> > > Okay, I looked over the properties, and after a few slight changes, I
> > think
> > > they nearly all of them are within reason (either doing a
> > > small mathematical computation or null check).  I'm actually very eager
> > to
> > > start hearing feedback on the API changes.  I think most people will be
> > > able to figure it out easily.
> > >
> > > It would also be nice if people could find bugs we could fix before
> > > releasing it.  Actually, it would be nice if people knew there was a
> > 3.0.3
> > > version  coming out.  So, I say go for it.
> > >
> > >
> > > Thanks,
> > > Christopher
> > >
> > > On Thu, Apr 12, 2012 at 6:14 PM, Christopher Currens <
> > > currens.ch...@gmail.com> wrote:
> > >
> > > > Michael,
> > > >
> > > > Not quite yet.  I think I was overly aggressive with some of the
> > > > conversions I made with Get/Set functions to Properties, and I want
> to
> > > > revert any that I find do too much work back into a method.
> > > >
> > > > After that, I think most of the API changes left to make are fairly
> > > > minimal, and it would be nice to get some feedback from the
> community.
> > > >  Maybe I'll work on those properties tonight.
> > > >
> > > >
> > > > Thanks,
> > > > Christopher
> > > >
> > > >
> > > > On Thu, Apr 12, 2012 at 5:17 PM, Michael Herndon <
> > > > mhern...@wickedsoftware.net> wrote:
> > > >
> > > >> Chris, Prescotts, others awesome committers working on trunk,
> > > >>
> > > >> Do you wish the project to start attempting to gain attention for
> > 3.0.3
> > > >> and
> > > >> possibly gain some community testing / wear and tear on it?
> > > >>
> > > >> Also are there any pressing matters you wish to gain more feedback
> on
> > > from
> > > >> the community?  Our twitter account has been too silent.
> > > >>
> > > >> -Michael
> > > >>
> > > >> P.S.  really great work on trunk.  I've been playing with the bits
> as
> > > time
> > > >> permits and might even use the upcoming release at work.  If I do,
> > I'll
> > > >> put
> > > >> some time into contributing some docs / tutorials.
> > > >>
> > > >
> > > >
> > >
> >
>

Re: user feedback on 3.0.3

[Michael Herndon]

Done.  For future reference to tweeting things with dots.  We have to use
ascii with Lucene.Net on tweets. Otherwise twitter will transform the
"Lucene.Net" text into a link that points to its Java counterpart.

Lucene.Net



On Fri, Apr 13, 2012 at 12:37 PM, Christopher Currens <
currens.ch...@gmail.com> wrote:

> Okay, I looked over the properties, and after a few slight changes, I think
> they nearly all of them are within reason (either doing a
> small mathematical computation or null check).  I'm actually very eager to
> start hearing feedback on the API changes.  I think most people will be
> able to figure it out easily.
>
> It would also be nice if people could find bugs we could fix before
> releasing it.  Actually, it would be nice if people knew there was a 3.0.3
> version  coming out.  So, I say go for it.
>
>
> Thanks,
> Christopher
>
> On Thu, Apr 12, 2012 at 6:14 PM, Christopher Currens <
> currens.ch...@gmail.com> wrote:
>
> > Michael,
> >
> > Not quite yet.  I think I was overly aggressive with some of the
> > conversions I made with Get/Set functions to Properties, and I want to
> > revert any that I find do too much work back into a method.
> >
> > After that, I think most of the API changes left to make are fairly
> > minimal, and it would be nice to get some feedback from the community.
> >  Maybe I'll work on those properties tonight.
> >
> >
> > Thanks,
> > Christopher
> >
> >
> > On Thu, Apr 12, 2012 at 5:17 PM, Michael Herndon <
> > mhern...@wickedsoftware.net> wrote:
> >
> >> Chris, Prescotts, others awesome committers working on trunk,
> >>
> >> Do you wish the project to start attempting to gain attention for 3.0.3
> >> and
> >> possibly gain some community testing / wear and tear on it?
> >>
> >> Also are there any pressing matters you wish to gain more feedback on
> from
> >> the community?  Our twitter account has been too silent.
> >>
> >> -Michael
> >>
> >> P.S.  really great work on trunk.  I've been playing with the bits as
> time
> >> permits and might even use the upcoming release at work.  If I do, I'll
> >> put
> >> some time into contributing some docs / tutorials.
> >>
> >
> >
>

user feedback on 3.0.3

[Michael Herndon]

Chris, Prescotts, others awesome committers working on trunk,

Do you wish the project to start attempting to gain attention for 3.0.3 and
possibly gain some community testing / wear and tear on it?

Also are there any pressing matters you wish to gain more feedback on from
the community?  Our twitter account has been too silent.

-Michael

P.S.  really great work on trunk.  I've been playing with the bits as time
permits and might even use the upcoming release at work.  If I do, I'll put
some time into contributing some docs / tutorials.

Re: [Lucene.Net] FW: trouble getting cms content to work correctly

[Michael Herndon]

Is it safe to add content to the site through the CMS again?  Anything to
be wary of or not explicitly do?

On Wed, Feb 15, 2012 at 6:30 PM, Prescott Nasser wrote:

>
> Took all day, but Joe was there babysitting and correcting things for us.
> Basically there is a bug in svn 1.6.17 that the CMS is based on, which is
> making our commits a pain at the moment. Once that gets upgraded it should
> be relatively smooth sailing. It won't help us though if we want still
> planning on updating massive amounts of documentation on a regular basis.
> Thanks Joe, I can't thank you enough for the help today.
>  ~PrescottDate: Wed, 15 Feb 2012 14:49:48 -0800
> From: joe_schae...@yahoo.com
> Subject: Re: trouble getting cms content to work correctly
> To: geobmx...@hotmail.com
>
> After some testing it appears that this performancebug is fixed in svn
> 1.7, but the CMS is currentlyrunning 1.6.17.  I hope to have the host
> upgradedwithin the next 30 days or so, but for now I stillrecommend using
> the script.
>
>From: Prescott Nasser 
>  To: joe_schae...@yahoo.com
>  Sent: Wednesday, February 15, 2012 5:28 PM
>  Subject: RE: trouble getting cms content to work correctly
>
>
>
>
>
>
> Alright - sounds good
>
> Thanks again!
>
> ~P
>
> Date: Wed, 15 Feb 2012 14:25:45 -0800
> From: joe_schae...@yahoo.com
> Subject: Re: trouble getting cms content to work correctly
> To: geobmx...@hotmail.com
>
> I'm having some svn people look at the merge issues.Right now all I can
> suggest is that you publish usingthe publish.pl script on
> people.apache.org.  It's takingme about 10 min total to carry that out,
> which is certainlytoo long given the nature of the changes it's merging,but
> I'll let you know what I find
>  out.
>
>From: Prescott Nasser 
>  To: joe_schae...@yahoo.com
>  Sent: Wednesday, February 15, 2012 5:13 PM
>  Subject: RE: trouble getting cms content to work correctly
>
>
>
>
>
>
> It's butt ugly - all in one directory, 8206 files. I'd prefer a more
> natural docs structure, but that's how it gets generated
>
> ~P
>
> Date: Wed, 15 Feb 2012 14:10:47 -0800
> From: joe_schae...@yahoo.com
> Subject: Re: trouble getting cms content to work correctly
> To: geobmx...@hotmail.com
>
> Ok lemee kill it and use the publish.pl scripton people to see if I can
> get it to work right.Just curious tho- about how many files do youhave
> within that docs dir- all in one dir I presume?
>From: Prescott Nasser 
>  To: joe_schae...@yahoo.com
>  Sent: Wednesday, February 15, 2012
>  5:08 PM
>  Subject: RE: trouble getting cms content to work correctly
>
>
>
>
>
>
> I'm thinking still merge funk
>
> Date: Wed, 15 Feb 2012 14:05:21 -0800
> From: joe_schae...@yahoo.com
> Subject: Re: trouble getting cms content to work correctly
> To: geobmx...@hotmail.com
>
> Looks like it just completed.  Hmm, goahead and publish and lets try this
> onemore time.
>
>From: Joe Schaefer
>  
>  To: Prescott Nasser 
>  Sent: Wednesday, February 15, 2012 5:02 PM
>  Subject: Re: trouble getting cms content to work correctly
>
>
> Yeah more merge funk. Leave it run for now,but don't take any further
> action until youhear from me.
>
>From: Prescott Nasser 
>  To: joe_schae...@yahoo.com
>  Sent: Wednesday, February
>  15, 2012 4:59 PM
>  Subject: RE: trouble getting cms content to work correctly
>
>
>
>
>
>
> I hate to be the bearer of bad news... still taking days to publish (I'm
> not sure if there is a merge error or not) let me know I'll kill this quick
>
> Date: Wed, 15 Feb 2012 13:54:52 -0800
> From: joe_schae...@yahoo.com
> Subject: Re: trouble getting cms content to work correctly
> To: geobmx...@hotmail.com
>
> Yeah try out the webgui and edit/commit/publisha minor change.  It should
> take you no more thana minute or so total.
>
>From: Prescott Nasser 
>  To: joe_schae...@yahoo.com
>  Sent: Wednesday, February 15, 2012 4:52 PM
>  Subject: RE: trouble getting cms content to work correctly
>
>
>
>
>
>
> Man that sounds like a tool full of awesome!
>
> Ok - so for the moment no new docs, a simple edit should be quick?
> Date: Wed, 15 Feb 2012 13:48:40 -0800
> From: joe_schae...@yahoo.com
> Subject: Re: trouble getting cms content to work correctly
> To: geobmx...@hotmail.com
>
> Ok it's now fixed and your site should work as expectedat this point.  I
> had to redact the lazy_publish featureand reserve it for admins only
> because you don't actuallyhave permission to completely remove your
> publication
>  sitefrom svn and
>  that's not something I can offer
>  without
>  providingyou and every other
>  committer with the ability to nukeeach other's entire sites.
>
>
> From: Joe Schaefer 
>  To: Prescott Nasser 
>  Sent: Wednesday, February 15, 2012 4:20 PM
>  Subject: Re: trouble getting cms content to work correctly
>
>
> Yeah well it's probably timing out somewhere along the line.I'm looking
> into your svn tree now to see if I can figure outwhat's going on.
>  Basically the svn merge it's running isdoin

Re: [Lucene.Net] do we have a board report due?

[Michael Herndon]

even though we're not voting on this. +1

On Tue, Jan 31, 2012 at 1:30 PM, Prescott Nasser wrote:

> I've updated the board report: wiki.apache.org/incubator/February2012
>
> if you guys could take a moment to review.
>
> Sent from my Windows Phone
> 
> From: Stefan Bodewig
> Sent: 1/30/2012 8:59 PM
> To: lucene-net-...@incubator.apache.org
> Subject: Re: [Lucene.Net] do we have a board report due?
>
> On 2012-01-31, Prescott Nasser wrote:
>
> > I didn't see a notice,
>
> me neither
>
> > but something on general caught my eye.
>
>  says: yes.
>
> Thank you for reminding us.
>
> Personally I'd like to see Lucene.NET graduate over the next three
> months so it would be good if we could identify what is preventing the
> project from just doing that.
>
> Stefan
>

Re: [Lucene.Net] [VOTE] Apache-Lucene-2.9.4g-incubating-RC1 Release (take 2)

[Michael Herndon]

Stefan what did you use to check the eof of files for svn?

I'm setting up RAT on my local.  Are there any other tools that you or ASF
recommends in general to validate releases?

- Michael





On Mon, Jan 23, 2012 at 12:02 PM, Stefan Bodewig  wrote:

> On 2012-01-23, Prescott Nasser wrote:
>
> > I've created a wiki page with the checklist:
> >
> https://cwiki.apache.org/confluence/display/LUCENENET/Release+Checklist+and+steps+once+a+release+is+approved
> .
>
> Thanks, I've added the points from my list.
>
> > I've also called a vote in general for 2.9.4g.
>
> Personally I would have preferred it if you had waited until you got
> three +1s from this list.  So far I've only seen Christopher's (and
> imply yours even though you didn't vote explicitly ;-).
>
> Once/if Michael gets around voting I'll throw in my +1 as well (on
> general and here).
>
> Stefan
>

Re: [Lucene.Net] 3.0.3

[Michael Herndon]

Do we have a standard of copy or tag of Java's version source that we're
doing a compare against?  I only see the 3_1 and above in the tags.

I could attempt to do something similar I did with core and version 4 and
use beyond compare between 2.9.4 and 3.0.3  and make a list of files that
were touched and script out wiki links.  Or I could try to generate of
beyond compare's diff reports and see how that stacks up and post to the
above link.









On Sat, Jan 14, 2012 at 5:15 AM, Prescott Nasser wrote:

>
>
>
>
> I've updated the confluence page to hopefully give us some direction:
> https://cwiki.apache.org/confluence/display/LUCENENET/Lucene.Net+3.0.3I'd 
> think it's just easier if as you take down a Java Lucene Issue, you
> create a JIRA issue for Lucene.Net and associate it with 3.0.3, rather than
> me making a ton of issues. ~P

Re: [Lucene.Net] I want to help! Also, where are we at?

[Michael Herndon]

> Where would my effort best go?

My advice is to play to strengths or work on things that seem interesting
or challenging to you.

Looking through the tickets on jira is a good place to start.
https://issues.apache.org/jira/browse/LUCENENET

Look at recent threads on the mailing lists.
http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/

Another option is to pair with a committer looking for help on something in
particular in order to get it done.
( you have to admit this was a beautifully placed segway/opener for
committers to jump in. ;)  ).

> What are we currently working on?

10+ mana points for using the word "we".

There is a push to get 2.9.4g released and to work on porting 3.0.3 in
trunk.

> Can I join this mailing list?

Anyone is welcome to join the mailing list, unless it's your pet goldfish.
They're kinda shady.

On Tue, Jan 24, 2012 at 6:48 AM, Sean Newham
wrote:

> Hey,
>
> I want to help port Lucene.net. I'm starting to work with it at work (in
> fact my first job here was to port spellchecker from 3.5.3 to lucene.net2.3.2 
> (please don't ask)) and I want to help make it better.
> Questions:
> Where would my effort best go?
> What are we currently working on?
> Can I join this mailing list?
>
> Best wishes,
> Sean
> ps. My "home" email is seansevilt...@gmail.com and I might use this to
> email in.
>
>

Re: [Lucene.Net] [VOTE] Apache-Lucene-2.9.4g-incubating-RC1 Release (take 2)

[Michael Herndon]

Not be a miser, but I'm abstaining till we get a checklist for releases
going.

I know that we need to check
svn-eof
readme
use rat - apache license in files (if there is a tutorial on how to use
that, I can take that over)
docs
tickets
some form release info (whats in the release)

and I'm sure I'm missing stuff.


On Wed, Jan 18, 2012 at 3:53 AM, Troy Howard  wrote:

> I can't speak for anyone else but I've been inordinately busy since before
> the holidays. I'll take a look over the release tomorrow.
>
> Thanks so much to Prescott and Stephan for keeping things moving along.
>
> Thanks,
> Troy
> On Jan 18, 2012 12:33 AM, "Stefan Bodewig"  wrote:
>
> > Hi Prescott,
> >
> > First of all, I should have said "thank you".  Thank you for putting
> > together the release, thank you for dealing with my "formal"
> > requirements that some may consider nit-picking and thank you for being
> > persistent.
> >
> > On 2012-01-18, Prescott Nasser wrote:
> >
> > > What do you mean I wouldn't get three +1s? From the license devs? (
> > > this group seems a bit dead atm) or do you mean from the general?
> >
> > I meant "this group".  A release should be backed by the developers of
> > the project and so far I doesn't look that way.  Maybe people have just
> > waited for me to perform the "legal checks" in order to avoid spending
> > time reviewing a release that has to be recalled for non-technical
> > reasons, I don't know.
> >
> > As for general.  It sure would be nice if we could get all three mentors
> > to vote before informing the general list.  By the time you start the
> > vote on general, you'll have my +1 and we will get two more of them by
> > asking repeatedly, as usual.
> >
> > Stefan
> >
>

Re: [Lucene.Net] Lucene.Net Faceting Library (port of BoboBrowse)

[michael herndon]

I'm not familiar enough with the licenses or procedures for incorporating
another project outside the ASF to speak on that. Others might have input
on that.

Another thing that must be considered about is who would be the
responsibility party to in order to keep the project up-to-date against its
own Java project version as well as against Lucene.Net.

One of the bigger discussions of late is how to best use our limited
resources on a concentrated effort of continually moving Lucene.Net
forward, so there might be some push-back on something like this. It won't
be towards you or the project, but it would stem from the limited time we
all have to work on Lucene.Net

What I can suggest for the short term is make sure that the library is
compiled and written against  the latest 2.9.4 nuget packages.   Then
create your own nuget package, if that has not already been done.

Then write up a concise but enthusiastic description of bobo so that we can
post it on the wiki (or possibly later on a community section of the site
once vetted by committers). We can also use that material post tweets on it
from @LuceneDotNet

I would also suggest providing list of features and tutorials that make
easy for developers to incorporate it into their own projects that we could
post with the description.

- Michael

On Thu, Dec 22, 2011 at 12:53 PM, Alexey Shcherbachev <
ale...@renaissance-it.ru> wrote:

> Hi,
>
> Some time ago I ported the amazing Bobo Browse library (
> http://javasoze.github.com/bobo/ ) from Java to .Net.
> We've been using the port since that time, and it works well so far.
> Right now it is published here http://bobo.codeplex.com/ (binaries are a
> bit outdated, so better check source code directly).
> Initially Bobo was licensed under LGPL license, so we had to keep our port
> as LGPL too.
> But recently they changed the license to Apache 2.0, so our version is
> under Apache2.0 license too now.
>
> I think such faceting library could be useful for many Lucene.Net
> developers.
> Would it make sense to add it to the contrib folder so more people can use
> it?
>
> I know the Java version has now the built-in faceting module (
> https://issues.apache.org/jira/browse/LUCENE-3079 ) .
> But this version could be used with 2.9.2 and probably with 2.9.4 (not
> tested yet) right now.
>
> Kind Regards,
> Alexey Shcherbachev
>

Re: [Lucene.Net] 2.9.4 release couldn't be compiled for .Net3.5

[Michael Herndon]

Hi Alexey,

I believe this version of Lucene.Net will be the last version that can be
compiled with the .NET 2.0 runtime which is what .NET 3.5 runs on. There
was a vote on supported runtime versions by the community this past year,
The community widely supported to drop .NET 2.0 runtime after the 2.9.4
release in favor of the .NET 4.0 runtime.

I also believe most of the committers will be focused on using generics
with the next version and possibly .NET 4.0 specific code. However, since
the code is open source, anyone can contribute branches that can be
compiled on the .NET 2.0 runtime. There is plenty of work and only a
handful of committers with a limited amount of time to work on the project
and there is a need for a narrow focus from the committers in order to move
the project forward with releases.  But we're more than open to discussing
what it would take to accomplish something like that if it has enough
support from the community if that is something that interests you or
anyone else reading this thread.

If you search the mailing list, DIGY has some instructions on how to
compile the 2.9.4 tag in a way that is compatible with .NET 2.0.

If I stumble across it or someone else knows the steps, it will re-posted
in this thread.  But it does have to do with commenting out the ThreadLocal
and uncommenting out another portion of the code.

- Michael



On Tue, Dec 6, 2011 at 7:42 AM, Alexey Shcherbachev <
ale...@renaissance-it.ru> wrote:

> Hi,
>
> First of all thank you for the new release 2.9.4. That makes me really
> happy.
>
> However, I noted that current binaries are build for .Net 4.0 framework
> only, which is very inconvenient.
> The reason is we have a hard requirement to use .Net3.5sp1.
> We were going to build it manually as usual, but stumbled upon .Net 4.0
> specific code (file CloseableThreadLocal.cs):
>
> > private ThreadLocal t = new ThreadLocal();
>
> For now we just replaced CloseableThreadLocal file with a version from
> 2.9.2, but still.
>
> What is an official strategy of the Lucene.Net team about framework
> versions?
> Is there a chance that Lucene.Net will be released in future not only for
> 4.0, but for 3.5 too?
>
> Kind Regards,
> Alexey Shcherbachev
> Rebel Search team
> Skype: Leha-2304
> Web: http://rebelsearch.net/
>

Re: [Lucene.Net] Lucene.net twitter account and chat room

[michael herndon]

Maybe we use should build a mail/chat/social media search with
lucene.netat some point in the future?  I'm sure there is a way to log
the chat.

I posted up a tweet tonight on the release. better later than never.

I have two more tweets scheduled using hootsuite, one to thank Simone for
the packages, another to ask for article and application submissions on
monday.  If anyone else has ideas for the branding aspect, do share. I'll
try to check the feed daily.

hashtag: #lucenenet

- Michael.

On Fri, Dec 2, 2011 at 2:14 PM, Troy Howard  wrote:

> Re: Twitter
>
> Sadly not a single tweet has been sent out on our twitter account.
> Really need to remedy that.
>
> Re: IRC/realtime chat
>
> There have been some good reasons expressed by various folks at Apache
> (and in our team)  that realtime chat in channels which are not
> publicly logged should generally be discouraged. This is because it's
> all too easy to have a discussion in which only a few members of the
> community are present, and make decisions without any opportunity for
> the rest of the community to have input and without the ability to
> review the reasoning or discourse later. The same holds true for user
> support, as it's much better to have that public and logged in a
> mailing list message so that others might find that through searches
> and use as a reference.
>
> That said, people do use IRC/IM from time to time, but we prefer to
> keep most if not all of the communications public and on the Apache
> mailing lists. So feel free to set up a chat room and chat with
> whomever wants to join about whatever topic, but for most things at
> Apache the philosophy is "mailing list, or it didn't happen". :)
>
> Thanks,
> Troy
>
>
> On Fri, Dec 2, 2011 at 10:03 AM, Prescott Nasser 
> wrote:
> >
> >>
> >> I just saw that there is a twitter account for Lucene.net
> >> http://twitter.com/#!/LuceneDotNet
> >> is anybody using it?
> >
> >
> > Login information is in the private repo - does anyone know how I get to
> that, I can make an announcement
> >
> >
> >
> >
> >
>

Re: [Lucene.Net] Lucene.net nuget

[Michael Herndon]

Keep in mind tho that having the token checked in somewhere in the source
repository is not a good idea b/c someone could use it and publish malware
or trojans under your identity. So unless the token is stored outside the
source repository, it's not a good idea to have it in the CI.

-  stored in an ASF private repo.

the a new key probably needs to be generated and stored in the private ASF
repo as well.


The CI build is at builds.apache.org, however its not complete.

On Thu, Dec 1, 2011 at 2:45 PM, Simone Chiaretta  wrote:

> Mine below
>
> On Thu, Dec 1, 2011 at 7:28 PM, Michael Herndon <
> mhern...@wickedsoftware.net
> > wrote:
>
> > On Thu, Dec 1, 2011 at 1:04 PM, Simone Chiaretta <
> > simone.chiare...@gmail.com
> > > wrote:
> >
> > > You mean a different impersonal Nuget account?
> > >
> >
> > yes. the goal of the impersonal account was to allow committers to push
> > nuget packages in an automated way without the need of having their own
> > account. there was some preliminary work of building nuget packages using
> > the build scripts.
> >
>
> Sorry, I haven't followed a lot lately: at the end, did we end up using
> teamcity on codebetter or another build system? I remember there were
> discussion on that but don't remember how they ended.
>
>
>
> >
> > there has been talk on various nuget channels about allowing nuget to
> have
> > --pre tag or having a separate build channel. If you're not familiar with
> > gems/bundler, its basically a way to push packages that are not official
> > releases. (nightly, ctp, beta, etc).   So in theory the CI could build
> > packages nightly if the build does not fail into a channels.
> >
> > its also helps from an overall branding perspective.
> >
>
> The author that appears on the nuget gallery page can be different from the
> owner that puts the package online.
>
>
> >
> >
> > > From what I've seen also used in MS pkgs devs have their in accounts
> but
> > > pkgs have multiple owners.
> > >
> >
> > If its possible to do so link your account as an owner & prescott's
> account
> > with the impersonal one.
> >
>
> Keep in mind tho that having the token checked in somewhere in the source
> repository is not a good idea b/c someone could use it and publish malware
> or trojans under your identity. So unless the token is stored outside the
> source repository, it's not a good idea to have it in the CI.
>
> One last thing: I notice that the official lib is strongly named... again,
> not a good idea to have the key checked in the source control. I guess now
> someone owns the key for the strong naming and does the signing offline
> from the CI. Is that correct?
>
>
> >
> >
> > > But if you want we can also go with the Lucene.net team account.
> > > Simo
> > >
> > >
> >
>
>
>
> --
> 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 nuget

[Michael Herndon]

there is actually registered for the lucene.net account for nuget.org.  I'd
suggest we use that one since the committers have access the credentials
stored for the account.

If others are ok with Simone taking lead on this, I can forward those
credentials to him.



On Thu, Dec 1, 2011 at 12:04 PM, Simone Chiaretta <
simone.chiare...@gmail.com> wrote:

> One last thing:
> the binaries are just of .NET 4.0? or do we have different bins of 2.0 and
> 4.0?
>
> Simone
>
> On Thu, Dec 1, 2011 at 6:03 PM, Simone Chiaretta <
> simone.chiare...@gmail.com
> > wrote:
>
> > Ok, I'll starting working on them (the nuspecs files in build folder).
> > When I get access to the Lucene.Net pkg id I'll upload them.
> >
> > If you give me your nuget gallery username I'll add you to the package
> > owners.
> >
> > I'll also contact all other projects that are referencing to Lucene to
> > tell them to update the pkg id to depend on, or to fix the dep to 2.9.2
> > (and not >2.9.2)
> >
> > Simone
> >
> >
> > On Thu, Dec 1, 2011 at 5:56 PM, Prescott Nasser  >wrote:
> >
> >>
> >> > - Lucene.Net to contain the core
> >> > - Lucene.Contrib to contain the contrib and dep on Lucene.Net (there
> is
> >> > no point in shipping contrib alone)
> >> > - Lucene.Net.Sample to contain some samples (and a reference to
> >> > Lucene.Net)
> >>
> >>
> >> +1
> >>
> >>
> >>
> >> > - Lucene: either empty with just a reference to Lucene.Net or just a
> >> > README and description that asks to update reference to another
> package
> >> >
> >> > What do you think? Biggest problem is that Lucene is the de-facto
> >> offical
> >> > pkg id. Is it ok to switch to the Lucene.Net brand? or do you think we
> >> > should use keep the Lucene brand? IIUC we want to use our .NET brand
> >> > instead of the "java" one.
> >> >
> >>
> >>
> >> I think we want to change to .Net, even if we have to blank out Lucene
> or
> >> put in a readme (I'd vote for blanking it out imo).
> >>
> >>
> >>
> >> > I can grant ownership right to other people so someone else can work
> on
> >> it
> >> > if I get hit by a bus.
> >> > Prescott and Michael?
> >> >
> >>
> >>
> >>
> >> Those are probably good
> >>
> >>
> >>
> >>
> >> >
> >> > Simone
> >> >
> >> > On Thu, Dec 1, 2011 at 4:21 PM, Simone Chiaretta <
> >> simone.chiare...@gmail.com
> >> > > wrote:
> >> >
> >> > > Guys, if you want I can take ownership of the whole NuGet thing,
> from
> >> > > getting hold of the right package id, to publishing the nuget pkgs,
> >> and
> >> > > maybe adding a quickstart pkg
> >> > > Let me know if it's ok, or someone is already working on that.
> >> > >
> >> > > Simone
> >> > >
> >> > >
> >> > > On Thu, Dec 1, 2011 at 3:58 PM, Michael Herndon <
> >> > > mhern...@wickedsoftware.net> wrote:
> >> > >
> >> > >> if you look inside of trunk/build/scripts/ there are three nuspecs
> >> > >> under their respective folder names.
> >> > >> all, contrib, and core.
> >> > >>
> >> > >> all is basically a dependency on contrib & core.
> >> > >>
> >> > >>
> >> > >>
> >> > >> On Thu, Dec 1, 2011 at 4:06 AM, Prescott Nasser <
> >> geobmx...@hotmail.com
> >> > >> >wrote:
> >> > >>
> >> > >> >
> >> > >> > We also discussed a contrib package - but we never really had a
> >> decision
> >> > >> > if we should be doing one package per contrib project or a single
> >> > >> contrib
> >> > >> > project.
> >> > >> >
> >> > >> > 
> >> > >> > > Date: Thu, 1 Dec 2011 10:00:24 +0100
> >> > >> > > From: simone.chiare...@gmail.com
> >> > >> > > To: lucene-net-dev@lucene.apache.org
> >> > >> > > Subject: [Lucene.Net] Lucene.net nuget
> >> > >

Re: [Lucene.Net] Lucene.net nuget

[Michael Herndon]

if you look inside of   trunk/build/scripts/  there are three nuspecs
under their respective folder names.
all, contrib, and core.

all is basically a dependency on contrib & core.



On Thu, Dec 1, 2011 at 4:06 AM, Prescott Nasser wrote:

>
> We also discussed a contrib package - but we never really had a decision
> if we should be doing one package per contrib project or a single contrib
> project.
>
> 
> > Date: Thu, 1 Dec 2011 10:00:24 +0100
> > From: simone.chiare...@gmail.com
> > To: lucene-net-dev@lucene.apache.org
> > Subject: [Lucene.Net] Lucene.net nuget
> >
> > Dears,
> > now, in the .NET ecosystem of opensource libraries it is super important
> to
> > have the nuget package released in sync with the binary release. Actually
> > many project are even just releasing the nuget package.
> >
> > Currently there is a bit of confusion in the list of packages:
> >
> > - There is "Lucene" with project id "lucene"by Apache SF relased on jan
> > 11 frozen on version 2.9.2.2 http://nuget.org/List/Packages/Lucene
> > - There is "Lucene.Net - (strong named 2.0/4.0) - 2.9.2.2" with project
> > id "lucene.net" released on Sept 11 still by Apache SF on version
> > 2.9.2.2 http://nuget.org/List/Packages/Lucene.Net
> >
> > I guess ppl think the good one is "lucene" b/c it has 3k download vs 173
> of
> > the other (almost 300 x month vs 85 x month)
> >
> > But nothing yet on 2.9.4.
> >
> > I suggest we reorganize the Nuget packages doing:
> > 1 - *delete *the "lucene" package (or add a new version with just a
> readme
> > file that clearly marks it is obsolete if not possible to remove the
> > project)
> > 2 - *rename *the "lucene.net" package public title to "Lucene.net"
> (remove
> > the version number as they are not supposed to stay in the name)
> > 3 - *create *a "lucene.net.strong" and move here the strongly signed
> > libraries
> > 4 - *upgrade both* to 2.9.4
> >
> > I think the script to create the nuget pkg is already in place, if not,
> let
> > me know and I'll look into making one.
> >
> > As last thing, I just want to stress on the importance of having a NuGet
> > pkg nowadays to be relevant in the .NET space
> >
> > Simone
> >
> > --
> > 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] Memory Leak 2.9.2.2

[Michael Herndon]

Did you mean to create 2 new threads? Also have you read Christopher's
response?



Hi Trevor,

What kind of memory increase are we talking about?  Also, how big are the
documents that you are indexing, the ones returned from getFileInfoDoc()?
 Is it putting an entire file into the index?  Pre 2.9.3 versions had
issues with holding onto allocated byte arrays far beyond when they were
used.  The memory could only be freed via closing the IndexWriter.

I'm a little unclear on exactly what's happening.  Are you noticing memory
spike and stay constant at that level or is it a gradual increase?  Is it
causing your application to error, (ie OutOfMemory exception, etc)?


Thanks,
Christopher

On Mon, Nov 28, 2011 at 5:43 PM, Trevor Watson <
powersearchsoftw...@gmail.com> wrote:

> I replaced the UpdateDocument with the following lines:
>
> iw.DeleteDocuments(new Lucene.Net.Index.Term("FileId",
> this.FileID.ToString("0")));
> iw.AddDocument(doc, analyzer);
>
>
> The memory usage still climbs constantly when updating.
>

Re: [Lucene.Net] Roadmap

[Michael Herndon]

>
>
> In the same vain: sort out the build process in a way that doesn't
> require the tools to be checked into svn.


https://cwiki.apache.org/confluence/display/LUCENENET/Road+Map

Posting these under floating goals on wiki. I already have some ideas on
how this can be done, so I've linked the above goal to a planning page for
the build.  We'll revisit once the other major items are accomplished on
the planning page.

Edit as necessary =)

- Michael

Re: [Lucene.Net] Contrib and releases

[Michael Herndon]

Some of the stuff currently in core were moved to contrib projects in newer
versions of Lucene

An example of this is the standard analyzer for 4x, is no longer in the
core project. So that is a scenario to be wary of.

As previously mentioned by chris, we should probably continue to maintain
what we have and slowly increase as contributors invest the time in porting
a contrib project, but otherwise concentrate on the essential.

Though I would imagine we should define what is considered to be essential
for a release and what is not.  Its also possible to put contrib projects
not essential on a different release cycle altogether.








On Tue, Nov 22, 2011 at 1:38 PM, Prescott Nasser wrote:

> I'd like to port over as much as possible. There is a lot of great stuff
> there and it only opens our user base up. That said I think they are nice
> to haves not requirements
>
> 
> From: Christopher Currens
> Sent: 11/22/2011 10:13 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] Contrib and releases
>
> I wanted to take some time to discuss our position on the Contrib projects.
>  Digy and I were a little off topic in the roadmap thread and I brought it
> up.  Digy mentioned he always felt that it was a "nice to have" but
> not necessarily required for a release.  I can't say I disagree.
>
> I had some time to look over a lot of the contrib code in Java, and there
> are quite a few projects that cannot be ported directly, as they rely on
> 3rd party Java libraries that have no direct .Net equivalent.  Porting them
> could delay releases a long time, which is why I think it hasn't really
> been kept up to date as it is.
>
> I think a requirement for releases should be to have whatever projects that
> are currently in contrib to be up to date and building, with valid and
> passing tests (our 2.9.4 Contrib.Analyzers project is missing tests for 9
> namespaces).  I think it should be as simple as that.  I don't think we
> should worry about adding new projects, unless you feel compelled to do so.
>  My opinion is that if someone wants a Contrib added to the project,
> someone can port and donate the code to our project, or if they request it,
> someone can volunteer to port it themselves.
>
> People do use our Contrib assemblies, I personally think this is a fair
> trade-off to only have to maintain what we already have.  I would like to
> know how everyone else feels about it.
>
>
> Thanks,
> Christopher
>

Re: [Lucene.Net] Roadmap

[Michael Herndon]

other possible goals (these can be assigned to any milestone and pushed
back when needed)

*  Enhanced BCL support - interfaces, operator overloads, etc.
*  FxCop support - fix or suppress messages
*  Investigate CLSCompliance  - already partially done by prescott and many
thanks for that.
*  Enhance developer experience - provide updated demos and common
out-of-the box scenarios. i.e. use Attributes & Types to index POCOs, Auto
Complete (jquery/jquery ui, etc), basic website/app search.


Other thoughts. Maybe we should stagger major releases a bit more in order
to have smaller more manageable milestones and get bits into the hands of
people sooner and thus not putting so much pressure on major releases to
get it right the first time.

Work on core, release core as a CTP.  Work on bugs from CTP & Contrib,
release second 2nd CTP, then release Beta, Then RTW.


As for 4x
I'd suggest everyone look the Lucene trunk to gauge the work required and
new changes. A release by next summer would be too agressive even if it was
scaled to just simply porting without thinking about it.

Also 4x would be the best time to make breaking changes since the Java
version breaks changes significantly. This is the one version I would not
want to just get out the door in order to maintain parity with Java. I also
hope passing out of incubation would not depend on this version's release.





On Tue, Nov 22, 2011 at 12:44 PM, Prescott Nasser wrote:

> My goal is to release 2.9.4 this month - it looks like we have no -1s from
> our dev list so in the next day or so I will put that to the general
> incubator list.
>
> I'd then like to release 2.9.4g the first or second week of January.
>
> My thoughts would be to try and have 3.0.3 ready by march and 4.0 in the
> middle of the year. Im not sure how aggressive people think that is.
>
> With the 4.0 release we should be at or near parity with Java and ready to
> roll out of the incubator. We could do the 4 release and the graduation
> process at the same time as well
>
> Sent from my Windows Phone
> 
> From: Scott Lombard
> Sent: 11/22/2011 8:56 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [Lucene.Net] Roadmap
>
> Mike,
>
> You're right about putting together a higher level discussion.  Here are
> the
> road map items I see.  I am interested in other have to say.
>
> None of the items I have listed are contigent on the other so they can be
> done in parallel or out of order.
>
>
> 1) Complete the release of 2.9.4
> 2) Create and release 3.0.3
>
> 3) Graduate from the incubator
> 4) Document a porting process that the community can reference.
> 5) Port 4.0
>
>
>
> Scott
>
> > -Original Message-
> > From: Michael Herndon [mailto:mhern...@wickedsoftware.net]
> > Sent: Tuesday, November 22, 2011 10:28 AM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: [Lucene.Net] Roadmap
> >
> > While much of the content in this thread is valid and is
> > important, especially concerns, pain points, and
> > implementation details... we've gotten way off topic.
> >
> > road map != implementation details. We should keep to a much
> > a higher level discussion to get this knocked out.
> >
> > Lets outline the roadmap, put it in a wiki page.
> >
> > Then discuss how to go about each major milestone in separate
> > threads to discuss implementation details. Or at least let
> > the people who are going to work on that particular milestone
> > publish their intentions to keep everyone else informed since
> > we're currently in a do-ocracy like state.
> >
> > And by all means, discuss the next immediate milestones first
> > so people who want to dive into that can proceed.
> >
> > So what are the next two major milestones?  And from a higher
> > level perspective what are the major items that deem those
> > milestones complete?
> >
> > What would be the the next 3 ideal milestones after the first
> > two? And what would be the intentions for those milestones to
> > accomplish?
> >
> > - Michael
> >
> >
> >
> > On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens <
> > currens.ch...@gmail.com> wrote:
> >
> > > Next to impossible/really, really hard.  There are just some things
> > > that don't map quite right.  Sharpen is great, but it seems
> > you need
> > > to code written in a way that makes it easily convertible,
> > and I don't
> > > see the folks at Lucene changing their coding style to do that.
> > >
> > > An example: 3.0.3 changes classes that inherited from
> >

Re: [Lucene.Net] Roadmap

[Michael Herndon]

While much of the content in this thread is valid and is important,
especially concerns, pain points, and implementation details... we've
gotten way off topic.

road map != implementation details. We should keep to a much a higher
level discussion to get this knocked out.

Lets outline the roadmap, put it in a wiki page.

Then discuss how to go about each major milestone in separate threads to
discuss implementation details. Or at least let the people who are going to
work on that particular milestone publish their intentions to keep everyone
else informed since we're currently in a do-ocracy like state.

And by all means, discuss the next immediate milestones first so people who
want to dive into that can proceed.

So what are the next two major milestones?  And from a higher level
perspective what are the major items that deem those milestones complete?

What would be the the next 3 ideal milestones after the first two? And what
would be the intentions for those milestones to accomplish?

- Michael



On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens <
currens.ch...@gmail.com> wrote:

> Next to impossible/really, really hard.  There are just some things that
> don't map quite right.  Sharpen is great, but it seems you need to code
> written in a way that makes it easily convertible, and I don't see the
> folks at Lucene changing their coding style to do that.
>
> An example: 3.0.3 changes classes that inherited from util.Parameter, to
> java enums.  Java enums are more similar to classes than they are in C#.
>  They can have methods, fields, etc.  I wound up converting them into enums
> with extension methods and/or static classes (usually to generate the
> enum).  The way the code was written in Java, there's no way a automated
> tool could figure that out on its own, unless you had some sort of way to
> tell it what to do before hand.
>
> I imagine porting it by hand is probably easier, though it would be nice if
> there was a tool that would at least convert the syntax from Java to C#, as
> well as changing the naming scheme to a .NET compatible one.  However, that
> only really helps if you're porting classes from scratch.  It could, also,
> hide bugs, since it's possible, however unlikely, something could port
> perfectly, but not behave the same way.
>
> A class that has many calls to string.Substring is a good example of this.
>  If the name of the function is changed to the .Net version (.substring to
> .Substring), it would compile no problems, but they are very different.
>  C#'s signatures is Substring(int start, int count) while Java's is
> Substring(int startIndex, int endIndex).  It may work hiding issues, it may
> throw an exception, depending on the data.  A porting tool would probably
> know many of the differences like this, so it's sorta a moot point, in that
> this relies on the skills of the developer anyway.
>
> I may be wrong, but I just don't see this being a fully automated process
> ever.  I would love to have something automated that at least fixed syntax
> errors, though this would only work on a line-by-line port.  (Slightly off
> topic, I think we should always have a line-by-line port, even if our
> primary goals become focusing on a fully .Net style port)  Either way, any
> sort of manual or partly-automated process would still require a lot of
> work to make sure things are ported correctly.  I also think it's most
> manageable if it were a tool that did it on a file per file basis (instead
> of project level like Sharpen), for easy review and testing.
>
>
> Thanks,
> Christopher
>
> On Mon, Nov 21, 2011 at 3:30 PM, Scott Lombard  >wrote:
>
> > Chris,
> >
> > Now that you have spent some time dealing with the porting what is your
> > view
> > on creating a fully automated porting tool?
> >
> > Scott
> >
> > > -Original Message-
> > > From: Christopher Currens [mailto:currens.ch...@gmail.com]
> > > Sent: Monday, November 21, 2011 5:23 PM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: Re: [Lucene.Net] Roadmap
> > >
> > > Digy,
> > >
> > > No worries.  I wasn't taking them personally.  You've been
> > > doing this for a lot longer than I have, but I didn't
> > > understand you pain until I had to go through it personally. :P
> > >
> > > Have you looked at Contrib in a while?  There's a lot of
> > > projects that are in Java's Contrib that are not in
> > > Lucene.Net?  Is this because there are some that can't easily
> > > (if at all) be ported over to .NET or just because they've
> > > been neglected?  I'm trying to get a handle on what's
> > > important to port and what isn't.  Figured someone with
> > > experience could help me with a starting point over deciding
> > > where to start with everything that's missing.
> > >
> > >
> > > Thanks,
> > > Christopher
> > >
> > > On Mon, Nov 21, 2011 at 2:13 PM, Digy  wrote:
> > >
> > > >
> > > > Chris,
> > > >
> > > > Sorry, if you took my comments about "pain of porting" personally.
> > > > That wasn't my int

Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

[Michael Herndon]

+1 for wiki checklist & ticket for for build scripts to bundle all this
stuff for you.

On Sun, Nov 20, 2011 at 1:51 AM, Prescott Nasser wrote:

> Damn It - knew i was missing something
>
> Sent from my Windows Phone
> 
> From: Stefan Bodewig
> Sent: 11/19/2011 10:34 PM
> To: lucene-net-...@incubator.apache.org
> Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3
>
> On 2011-11-18, Prescott Nasser wrote:
>
> > Third time is the charm:
>
> I'm afraid it is not.
>
> > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/
>
> Sigs and hashes are good.  Source zip and tag match except for the
> build/lib/doc dirs that are only inside the tag and which I agree is a
> good thing for now.
>
> LICENSE, NOTICE, DISCLAIMER look good in src.
>
> There is no NOTICE and no DISCLAIMER in the binary zip.  Has it been
> this way before?  If so I'm sorry I didn't catch it.  This is a blocker
> for me and probably would be for the other IPMC members as well.
>
> RAT is reasonably happy with the source tree.
>
> I can't give a +1 because of the missing files in the binary zip.  If
> you just recreated the binary with the two files added (and obviously
> resigned it and recalculated the hashes) I'd be happy to change that.
>
> Cheers
>
>Stefan
>

Re: [Lucene.Net] [jira] [Commented] (LUCENENET-453) Many files need proper svn properties to set the linefeeds

[Michael Herndon]

Just in case anyone else following this that are still fuzzy on the details
due to the acronyms.

CRLF is the windows version of a new line.  "\r\n"   carriage return,line
feed. or in c# Environment.NewLine;
eol = end of line.
eof = end of file.

FOSS projects that will possibly run on multiple platforms generally have
to be more aware of this than others.

http://en.wikipedia.org/wiki/Newline

I sometimes forget about this kind of thing myself. but scm generally has
ways to checkout in one format and commit back in the other.  I know that
git has options for this.

You might get notices from visual studio about switching the line breaks to
crlf if the file is not in that format.  text-editor behavior varies.


On Sun, Nov 13, 2011 at 2:25 AM, Stefan Bodewig (Commented) (JIRA) <
j...@apache.org> wrote:

>
>[
> https://issues.apache.org/jira/browse/LUCENENET-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149241#comment-13149241]
>
> Stefan Bodewig commented on LUCENENET-453:
> --
>
> Basically I did something like
>
> find . -name \*.cs -print0 | xargs -0 -e svn ps svn:eol-style native
>
> i.e. I set the eol-style to native for all C# sources and then used "svn
> status" to see which ones didn't have that already.  Repeat for the other
> file types I expected to have bad line-ends.  Another approach would be to
> run Ant's fixcrlf task over the tree and see what gets changed.  I'm sure
> there are other ways to do this.
>
> svn will complain if you try to set the svn:eol-style property on a file
> with a binary MIME type.  When I started to write the comment I expected to
> find more files than the one, that's why it reads a bit weird.  Yes, AFAIR
> this was the only binary source file.
>
> svn tracks line-feed information in the svn:eol-style property.  By
> default it doesn't do any transformations at all.  If you set it to native
> then all line-feeds will be transformed when checking out files (I think
> svn uses \n internally) to your platform's default and back on commit.
>  Apart from native there are explicit values for "always \n" and so on.
>  You use that for files that are only meaningful on specific platforms
> (shell scripts and batch files, mostly).  build.cmd is Windows only so it
> makes sense to set the property to "CRLF".
>
> See
> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style
>
> > Many files need proper svn properties to set the linefeeds
> > --
> >
> > Key: LUCENENET-453
> > URL: https://issues.apache.org/jira/browse/LUCENENET-453
> > Project: Lucene.Net
> >  Issue Type: Bug
> >Reporter: Stefan Bodewig
> >Priority: Minor
> > Attachments: LUCENENET-453.inconsistent-eol.patch,
> LUCENENET-453.list-of-files-with-missing-svn_eol-style.txt
> >
> >
> > Many files are lacking the svn:eol-style proper which should be set to
> native, I'll attach a list later.
> > Some files have inconsistent linefeeds, I'll attach a patch.
> > Some files even have bad mine-types.  You need to run
> > svn pd svn:mime-type
> > on
> > test/contrib/Core/Analysis/Ext/Analysis.Ext.Test.cs
> > build.cmd should likely get an svn:eol-style of crlf
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators:
> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>

Re: [Lucene.Net] Final patches for rc3

[Michael Herndon]

I'm guessing we'll need the xml & docs regenerated. do you know if we need
to commit a small segment and then publish to the cms?

or just do small commits and publish all the small commits at once?

I probably won't attempt that till this weekend.

On Thu, Nov 10, 2011 at 3:18 PM, Prescott Nasser wrote:

> Im reviewing all the issues before I cut rc3. Looks like I have the
> following:
>
> •apply lucenenet-453 patch from Stefan to fix the line endings
> •couple of license headers
> •update the readme
> •add an rc3 tag.
>
> Is there anything im missing? I will have some time tonight to fix these
> items and then prepare new files for another vote.
>
> -P
>
> Sent from my Windows Phone

Re: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation

[Michael Herndon]

I can rebuild it, but the trick is replacing the version of it in svn so
that it does not cause svnsync and cms to choke. Last time I just pushed it
into branch/site/docs.  However, that is not publicly visible for the
incubation website, so Prescott had to do an svn move.

I'm not quite sure how to go about it this time around. I would push it to
jira, but it caps uploads at 10 mb.  And I definitely don't want to cause
infra any grief.  Thoughts/Suggestions on how to proceed ?


On Sun, Nov 6, 2011 at 1:28 AM, Christopher Currens  wrote:

> I've committed the changes to the xml documentation to the repo.
>
> I built the documentation, but I wasn't sure how Michael packaged the
> documentation in [LUCENENET-452].  If someone could either rebuild the
> documentation or let me know how it was done for the release, then we can
> open it up for another vote to release it.
>
>
> Thanks,
> Christopher
>
> On Fri, Nov 4, 2011 at 8:55 PM, Prescott Nasser  >wrote:
>
> > I dont mind
> >
> > Sent from my Windows Phone
> > 
> > From: Christopher Currens
> > Sent: 11/4/2011 5:08 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation
> >
> > A few days ago, after RC1 was put up for a vote to release, I started
> > working on [LUCENENET-438] by cleaning up the documentation.  The current
> > state of the documentation is pretty bad, there are many unconverted
> > remnants of javadoc comments (ie, @link, @see, etc..).  I wanted to do
> this
> > simply to get our documentation up to a more readable level.
> >
> > I had expected this to take quite a long time, but with the magic of
> > regular expressions and find and replace, I'm nearly done with the
> > conversion, this all on the heels of the RC2 that was just put up to
> vote.
> >  I will probably wind up finishing the cleanup of the documentation
> > comments before Monday.  I would have said something earlier had I known
> it
> > wouldn't take me long and I likely wouldn't have made a vote on releasing
> > RC2.
> >
> > So, if no one is opposed to it, we may consider to wait on RC2,
> regenerate
> > new documentation after I push the changes to SVN, and package it for
> > another RC (Sorry, Prescott!!).  It might be nice to have those
> > documentation issues fixed.  Like I said before, I hadn't really expected
> > to finish it so quickly, and hadn't even though it could be ready in time
> > for 2.9.4 release.
> >
> >
> > Thanks,
> > Christopher
> >
>

[Lucene.Net] [jira] [Commented] (LUCENENET-454) MSBuild may wipe entire root drive if bad parameters are passed to build.targets

[Michael Herndon (Commented) (JIRA)]

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

Michael Herndon commented on LUCENENET-454:
---

Jira comments wouldn't work from my phone

Let me know if you need any help. I've debating on creating custom
build tasks for clean and such since it does not handle folders and its
harder to script preventative measures than it should be. Powershell
would have been easier, build the scripts need to work with mono as
well.

Sent from my Windows Phone From: Christopher Currens (Created) (JIRA)
Sent: Saturday, November 05, 2011 10:01 PM
To: lucene-net-dev@lucene.apache.org
Subject: [Lucene.Net] [jira] [Created] (LUCENENET-454) MSBuild may wipe
entire root drive if bad parameters are passed to build.targets
MSBuild may wipe entire root drive if bad parameters are passed to build.targets


 Key: LUCENENET-454
 URL: https://issues.apache.org/jira/browse/LUCENENET-454
 Project: Lucene.Net
  Issue Type: Bug
  Components: Build Automation
Reporter: Christopher Currens
Priority: Critical


If the Area variable is passed to MSBuild and includes quotes or
doesn't match a valid target area, MSBuild populates the "CleanFiles"
ItemGroup with every file on the local harddrive.  When the clean step
is run, all files on the drive will be deleted!

This can be reproduced with the following command (I do not recommend
reproducing this unless you've taken precautions to protect your
data).

MSBuild.exe build.targets /t:all /p:Area=invalidareaname

The causes "ArtifactsFolder" to never be populated.  "CleanFiles" then
gathers a list of files from "\**\*.*" instead of "valid\path\**\*.*"
which, at least on windows computers, evaluates out to "D:\**\*.*", or
all files on my local hard drive.

One solution would be to force MSBuild to throw an error if
"ArtifactsFolder" is empty during the clean target.  In fact, we
should make a note to check every place we're calling the Delete task,
and make sure we do sanity checks on the variables involved in
gathering the files to delete.

I'm testing a fix for it right now, and if it seems to work, I'll be
committing it tonight.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


> MSBuild may wipe entire root drive if bad parameters are passed to 
> build.targets
> 
>
> Key: LUCENENET-454
> URL: https://issues.apache.org/jira/browse/LUCENENET-454
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Build Automation
>Reporter: Christopher Currens
>Priority: Critical
>
> If the Area variable is passed to MSBuild and includes quotes or doesn't 
> match a valid target area, MSBuild populates the "CleanFiles" ItemGroup with 
> every file on the local harddrive.  When the clean step is run, all files on 
> the drive will be deleted!
> This can be reproduced with the following command (I do not recommend 
> reproducing this unless you've taken precautions to protect your data).
> MSBuild.exe build.targets /t:all /p:Area=invalidareaname
> The causes "ArtifactsFolder" to never be populated.  "CleanFiles" then 
> gathers a list of files from "\**\*.*" instead of "valid\path\**\*.*" which, 
> at least on windows computers, evaluates out to "D:\**\*.*", or all files on 
> my local hard drive.
> One solution would be to force MSBuild to throw an error if "ArtifactsFolder" 
> is empty during the clean target.  In fact, we should make a note to check 
> every place we're calling the Delete task, and make sure we do sanity checks 
> on the variables involved in gathering the files to delete.
> I'm testing a fix for it right now, and if it seems to work, I'll be 
> committing it tonight.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: [Lucene.Net] [jira] [Created] (LUCENENET-454) MSBuild may wipe entire root drive if bad parameters are passed to build.targets

[Michael Herndon]

Jira comments wouldn't work from my phone

Let me know if you need any help. I've debating on creating custom
build tasks for clean and such since it does not handle folders and its
harder to script preventative measures than it should be. Powershell
would have been easier, build the scripts need to work with mono as
well.

Sent from my Windows Phone From: Christopher Currens (Created) (JIRA)
Sent: Saturday, November 05, 2011 10:01 PM
To: lucene-net-dev@lucene.apache.org
Subject: [Lucene.Net] [jira] [Created] (LUCENENET-454) MSBuild may wipe
entire root drive if bad parameters are passed to build.targets
MSBuild may wipe entire root drive if bad parameters are passed to build.targets


 Key: LUCENENET-454
 URL: https://issues.apache.org/jira/browse/LUCENENET-454
 Project: Lucene.Net
  Issue Type: Bug
  Components: Build Automation
Reporter: Christopher Currens
Priority: Critical


If the Area variable is passed to MSBuild and includes quotes or
doesn't match a valid target area, MSBuild populates the "CleanFiles"
ItemGroup with every file on the local harddrive.  When the clean step
is run, all files on the drive will be deleted!

This can be reproduced with the following command (I do not recommend
reproducing this unless you've taken precautions to protect your
data).

MSBuild.exe build.targets /t:all /p:Area=invalidareaname

The causes "ArtifactsFolder" to never be populated.  "CleanFiles" then
gathers a list of files from "\**\*.*" instead of "valid\path\**\*.*"
which, at least on windows computers, evaluates out to "D:\**\*.*", or
all files on my local hard drive.

One solution would be to force MSBuild to throw an error if
"ArtifactsFolder" is empty during the clean target.  In fact, we
should make a note to check every place we're calling the Delete task,
and make sure we do sanity checks on the variables involved in
gathering the files to delete.

I'm testing a fix for it right now, and if it seems to work, I'll be
committing it tonight.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [Lucene.Net] .xml files

[Michael Herndon]

The Lucene.Net projects were set up so they only generate when you build
the solution or a project in release mode.

There were also copies of those files in the zip file attached to that one
ticket as well just in case.

On Wed, Nov 2, 2011 at 2:59 AM, Prescott Nasser wrote:

>
> How do I generate those? I thought they were generated on compile, but I'm
> unable to find them

Re: [Lucene.Net] [jira] [Commented] (LUCENENET-452) Add docs to release

[Michael Herndon]

I'll have to look. RapidSVN's GUI froze when pushing that many files up. so
its possible the static files did not make it up.

On Tue, Nov 1, 2011 at 1:40 PM, Prescott Nasser wrote:

>
>
> Michael -
>
>
>
> I'm looking through the docs, and it looks like the much of the contrib
> stuff is MIA - if I navigate to Lucene.Net.Analysis.Cz the page is MIA.
> It's similar for most of contrib
>
>
>
> Are we missing something that would allow this documentation to be
> produced?
>
>
>
> ~P
>
>
> 
> > Date: Tue, 1 Nov 2011 02:38:32 +
> > From: j...@apache.org
> > To: lucene-net-dev@lucene.apache.org
> > Subject: [Lucene.Net] [jira] [Commented] (LUCENENET-452) Add docs to
> release
> >
> >
> > [
> https://issues.apache.org/jira/browse/LUCENENET-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140863#comment-13140863]
> >
> > michael herndon commented on LUCENENET-452:
> > ---
> >
> > html docs & chm for 2.9.4 are now in svn at
> https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4
> >
> > > Add docs to release
> > > ---
> > >
> > > Key: LUCENENET-452
> > > URL: https://issues.apache.org/jira/browse/LUCENENET-452
> > > Project: Lucene.Net
> > > Issue Type: Task
> > > Components: ASF Process
> > > Affects Versions: Lucene.Net 2.9.4
> > > Reporter: michael herndon
> > > Assignee: Prescott Nasser
> > > Labels: docuentation, process, release
> > > Fix For: Lucene.Net 2.9.4
> > >
> > > Attachments: lucene.net.xml.zip
> > >
> > >
> > > Here are the generated chm & website files for the site.
> > > https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4
> > > The docs were too big to save as a zip attachment, jira has a 10 mb
> limit.
> > > the xml files and nupkg will be attached as a zip file.
> > > The .nupkg function as zip files. This is in case the packages were
> not made when the binaries were. Use the official release binaries to
> replace the ones in the packages, zip, rename to nupkg. You can also use
> the package GUI for nuget.
> >
> > --
> > This message is automatically generated by JIRA.
> > If you think it was sent incorrectly, please contact your JIRA
> administrators:
> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> > For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >
> >
>

Re: [Lucene.Net] Windows Phone 7

[Michael Herndon]

The 4e branch is exploring using PLT (portable library tools)  for that as
well, which in theory would allow you to compile one assembly that runs
against multiple versions of .NET. including Silverlight 4 and Silverlight
4 for WP7 and hopefully MonoDroid & MonoTouch in the future.

PLT:
http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981

Porting to WP7 poses some decent challenges.  The windows mobile 7 version
of Silverlight does not support the [ThreadStatic] attribute,
WeakReference, Data Slots for threads, and and quite a few other things.

No matter which approach is used, it will need more resources (time, code
contributions, contributors, committers etc) from the community for it to
make any substantial forward progress on a version that supports WP7 any
time soon.

I'm not trying to dissuade you or anyone from pursuing it, in fact it would
be awesome to see mobile version of Lucene.Net. I just want people aware of
the challenges to curb any frustration and offer the advice of make small
milestones, keep a steady pace whatever that may be, do not go at it alone,
and continuously recruit others to contribute.


- Michael









On Tue, Nov 1, 2011 at 12:02 PM, Prescott Nasser wrote:

> I started working on it - but it was really ugly. My thoughts were to
> instead push lucene.net trunk toward using the common libraries so that
> we could utilize the same code base across all platforms, rather than
> trying to maintain a second branch.
>
>
> Sent from my Windows Phone
> 
> From: Paul Shealy
> Sent: 11/1/2011 8:21 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: [Lucene.Net] Windows Phone 7
>
> What's the status of Windows Phone 7 support for lucene.net? I found
> some test cases, but no code.
>
> If it's not being worked on, I'll pick it up. It's something I could use
> and I know other people want it too.
>

[Lucene.Net] [jira] [Commented] (LUCENENET-452) Add docs to release

[michael herndon (Commented) (JIRA)]

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

michael herndon commented on LUCENENET-452:
---

html docs & chm for 2.9.4 are now in svn at 
https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4  

> Add docs to release
> ---
>
> Key: LUCENENET-452
> URL: https://issues.apache.org/jira/browse/LUCENENET-452
> Project: Lucene.Net
>  Issue Type: Task
>  Components: ASF Process
>Affects Versions: Lucene.Net 2.9.4
>Reporter: michael herndon
>Assignee: Prescott Nasser
>  Labels: docuentation, process, release
> Fix For: Lucene.Net 2.9.4
>
> Attachments: lucene.net.xml.zip
>
>
> Here are the generated chm & website files for the site. 
> https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4
> The docs were too big to save as a zip attachment, jira has a 10 mb limit. 
> the xml files and nupkg will be attached as a zip file. 
> The .nupkg function as zip files. This is in case the packages were not made 
> when the binaries were. Use the official release binaries to replace the ones 
> in the packages, zip, rename to nupkg. You can also use the package GUI for 
> nuget.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-452) Add docs to release

[michael herndon (Updated) (JIRA)]

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

michael herndon updated LUCENENET-452:
--

Attachment: lucene.net.xml.zip

xml & nupkg files. 

> Add docs to release
> ---
>
> Key: LUCENENET-452
> URL: https://issues.apache.org/jira/browse/LUCENENET-452
> Project: Lucene.Net
>  Issue Type: Task
>  Components: ASF Process
>Affects Versions: Lucene.Net 2.9.4
>    Reporter: michael herndon
>Assignee: Prescott Nasser
>  Labels: docuentation, process, release
> Fix For: Lucene.Net 2.9.4
>
> Attachments: lucene.net.xml.zip
>
>
> Here are the generated chm & website files for the site. 
> https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4
> The docs were too big to save as a zip attachment, jira has a 10 mb limit. 
> the xml files and nupkg will be attached as a zip file. 
> The .nupkg function as zip files. This is in case the packages were not made 
> when the binaries were. Use the official release binaries to replace the ones 
> in the packages, zip, rename to nupkg. You can also use the package GUI for 
> nuget.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Updated] (LUCENENET-452) Add docs to release

[michael herndon (Updated) (JIRA)]

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

michael herndon updated LUCENENET-452:
--

Description: 
Here are the generated chm & website files for the site. 
https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4

The docs were too big to save as a zip attachment, jira has a 10 mb limit. 

the xml files and nupkg will be attached as a zip file. 

The .nupkg function as zip files. This is in case the packages were not made 
when the binaries were. Use the official release binaries to replace the ones 
in the packages, zip, rename to nupkg. You can also use the package GUI for 
nuget.  

  was:
Here are the generated xml files, chm & website files for the site. 

These also include the nuget packages since, the .nupkg are zip files. This is 
in case the packages were not made when the binaries were. Use the official 
release binaries to replace the ones in the packages, zip, rename to nupkg. You 
can also use the package Gui.  


> Add docs to release
> ---
>
> Key: LUCENENET-452
> URL: https://issues.apache.org/jira/browse/LUCENENET-452
> Project: Lucene.Net
>  Issue Type: Task
>  Components: ASF Process
>Affects Versions: Lucene.Net 2.9.4
>Reporter: michael herndon
>Assignee: Prescott Nasser
>  Labels: docuentation, process, release
> Fix For: Lucene.Net 2.9.4
>
>
> Here are the generated chm & website files for the site. 
> https://svn.apache.org/repos/asf/incubator/lucene.net/site/docs/2.9.4
> The docs were too big to save as a zip attachment, jira has a 10 mb limit. 
> the xml files and nupkg will be attached as a zip file. 
> The .nupkg function as zip files. This is in case the packages were not made 
> when the binaries were. Use the official release binaries to replace the ones 
> in the packages, zip, rename to nupkg. You can also use the package GUI for 
> nuget.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Lucene.Net] [jira] [Created] (LUCENENET-452) Add docs to release

[michael herndon (Created) (JIRA)]

Add docs to release
---

 Key: LUCENENET-452
 URL: https://issues.apache.org/jira/browse/LUCENENET-452
 Project: Lucene.Net
  Issue Type: Task
  Components: ASF Process
Affects Versions: Lucene.Net 2.9.4
Reporter: michael herndon
Assignee: Prescott Nasser
 Fix For: Lucene.Net 2.9.4


Here are the generated xml files, chm & website files for the site. 

These also include the nuget packages since, the .nupkg are zip files. This is 
in case the packages were not made when the binaries were. Use the official 
release binaries to replace the ones in the packages, zip, rename to nupkg. You 
can also use the package Gui.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[Michael Herndon]

@Troy,

Now I don't feel as bad for my long e-mails. ;)

-build scripts

Except for building on mono or running NCover, the scripts work as
intended. Also end users would need to install the required tools they
intend to run with the build scripts. The scripts can be included, but it
would be wise to include those caveats in a read-me somewhere.

And there are ways to override the build scripts for user/custom build
configurations.  For those interested, post questions on a new thread.

When you run the build scripts they should be including the xml files in
the trunk/bin folder on successful builds. Please do let me know if that
was not the case on your local machine if you used the scripts to build the
binaries.

-.snk
The .snk in the lib folder is the original.  When you create a new csproj,
that is the file you use sign the binary with a strong key. The project
defaults to creating a copy of the .snk file in its own folder.  I can't
remember if there is a way to just link it to only one file or not, but
that was the default behavior.

So to answer your question, if users/developers to create their own contrib
projects or their own ci based upon a stable release tag and plan to use
the same .snk, then it would be wise to include all of lib.  If they are
just building from a stable branch, you can exclude the .snk file as each
project that uses it will have its own copy.

- docs
Generating both chm/html at the moment.  I'll push the html version into
source tonight for the website. and push a zip file with both the chm &
static html site into a jira ticket.  The chm is handy when you're in
facility that is locked down and need to move around good deal of help
files on a thumb drive.

The xml files should be included. The xml files are only generated when you
currently build a binary in Release mode for trunk & 2.9.4g branch. So if
you build the binaries and the xml files are not there, that is the most
likely cause.

Unless someone picks up the task of improving the overall xml doc comments
between versions and generating them, most likely the documents will only
be updated between releases.

- Michael





On Mon, Oct 31, 2011 at 3:41 PM, Troy Howard  wrote:

> Prescott,
>
> Good job figuring out the signing and creating the release packages!
> It's non-trivial to figure out the first time from the docs, for sure.
> Sorry, I have been so busy this month that I wasn't able to provide
> help before you figured it out on your own. :)
>
> Some nitpicky details about the release packages:
>
> - Superfluous subfolders: There's an extra layer of subfolders named
> the same as the zip file which is unneeded
> - Root should be "trunk" all the time, even in the release packages,
> to keep relative pathing consistently rooted. So the binary release
> should have a "bin" subfolder at it's root to match the repo layout
> - XML doc files should be included in binary release. We have had
> users state a desire to have them for VS intellisense integration.
> This was an issue that came up during the last release package build
> cycle
> - Various notice files should be included in binary release as well
> - I don't know about the.SNK file from lib, maybe that should be in
> the source package, maybe not. I notice it's also in the core project
> folder. Which one does the project file reference?
> - .svn folder/files should be removed from source package
> - Empty subfolders should be left out (\build\vs2008 and \test\demo
> are the ones I noticed)
> - \docs are missing from source package as well
>
> Regarding docs, generally speaking, I think we should make a decision
> about what we want to provide and set a standard.
>
> Some considerations are:
> - XML doc files in binary package: Integrate with Visual Studio,
> providing a rich Intellisense experience, Generated at build time from
> source code. Where should they go in the folder structure to make it
> "just work" with VS from binary package?
> - Hosted HTML "Single Version of the Truth" vs HTML/CHM doc files in
> binary/source package: One one hand, we could only host docs on the
> website vs distributing them. We can update as needed, and they are
> the only reference. Can host docs for multiple versions, etc..
> HTML/CHM in packages, are good for offline use, but can't be updated.
> Both can be generated from XML files using Sandcastle. We could do
> either one, or both of those.
>
> Using sandcastle, we can include the Apache license in the headers of
> all generated files, solving a lot of the RAT complaints.
>
> Also, there's a lot of new material in the repo for CI related
> things.. Do we want to include any of the in the source package, to
> assist our users with setting up their own CI servers? How simple
> would it be to modify those files to work in a different environment
> (assuming they are also using Hudkins)?
>
> So all that said, I think there's more work to be done and I'm -1 for
> these artifacts.
>
> Thanks,
> Troy
>
>
> On Sun, Oct 30, 2011 at

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

[Michael Herndon]

@Prescott,

In name of getting this out the door and keeping momentum I'll put those
together and push that into svn sometime late tonight. **

Other things to do once released  official nuget package, some website
love. and start using the twitter: LuceneDotNet account.  I can help with
these as well.

@all,

If everyone involved for this release could put some time aside after this
release to co-write a checklist/steps to put on the wiki for the release
process in one place, that would be awesome.


**reasoning.
We've yet to get the SHFB installed on builds and thus I need to write up
some instructions for the installer as it been causing some pain for CI.
Once that hurdle is crossed, I'd like to work with a few people
contributors or committers to make sure others can create docs.  But for
now, there is no point in obstructing the release with that. We've made an
hard line effort at all things outstanding in the last few months and we
should keep with the momentum of getting this out the door.


- Michael





On Mon, Oct 31, 2011 at 2:14 AM, Prescott Nasser wrote:

>
>
>
>
>
> Michael - how do we stand with the sandcastle documentation generation?.
> I'm not familiar with using it, but we basically have no real documentation
> for this. It would be great to be able to generate documentation that we
> can then bundle with 2.9.4.
>
>
> Stefan - doc folder was left out intentionally for this reason. Also the
> Lib folder, I left out, I thought it was additional dll's that weren't part
> of Lucene that others might need. I can put that back in. Not even sure
> what the build.cmd file is, but I'll investigate and get it in there.
>
>
>
>
>
>
>
>
> 
> > 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 .
> > 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
>

[Lucene.Net] Barebones CI is setup.

[Michael Herndon]

A bare bones version for trunk CI builds have been setup.

[Trunk]
https://builds.apache.org/job/Lucene.Net-Trunk-Contrib-Poll-Changes/
https://builds.apache.org/job/Lucene.Net-Trunk-Contrib-Nightly/
https://builds.apache.org/job/Lucene.Net-Trunk-All-Poll-Changes/
https://builds.apache.org/job/Lucene.Net-Trunk-All-Nightly/


Lucene.Net-Trunk-All-Nightly & Lucene.Net-Trunk-All-Poll-Changes   will fail
till the tests are in working order for gallio test runner invoking nunit.
 I think the fact that gallio is running as a 64 bit process might have
something to do with it.  I believe nunit tends to run as x86 by default.

I put up a separate build for contrib projects because their test projects
are smaller and the build for it runs quickly.  So if you're working on a
contrib project, the build update will not take as long. Those builds are
currently successful.

Poll-Changes suffix means:

the build will poll SVN at every hour and 15 minutes.  i.e 12:15, 1:15, etc
 for changes.  build from scratch, run tests (and metrics when the tools for
those become successfully installed)

Nightly suffix means:

the build will poll nightly at 1 am jenkins standard time.  it will build
from scratch, run tests (and metrics, packages, and documentation when those
tools be come successfully installed)  and archive the results.

Make sure to thank Niklas Gustavsson for helping us to get this far.

That last thing for the group to discuss is how would you all like to
receive notifications.  You can currently subscribe to build rss feeds. We
could also setup notifications for e-mail, irc, or twitter.

- Michael.

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

'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..
> >
> >
> > > >
> >
> >
> > > >
> >
>

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

So I now have the scripts exporting the html site.  Does the current
cms/site some how link to ~/site/docs ?

Or if we publish the documents online they would need to into two
directories ~/site/docs/ for posterity & ~/site/trunk/content/
lucene.net/docs/  for everyone to view them online?

On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard  wrote:

> At one time I had a SVN server set up at work that had a post-commit
> hook set up that would generate a static HTML site from the XML doc
> files using Sandcastle. So.. It can be done. That was about 3-4 years
> ago and I don't work at that company any longer, so I don't have
> access to the details of how that was done.
>
> Regarding SVN locations...
>
> Autogenerated XML doc files should go in the ~/trunk/doc/
> folders. The Sandcastle generated static HTML should go under
> ~/site/docs/ folders.
>
> I'll see if I can't dig up some info on how to generate static HTML
> with Sandcastle.
>
> Thanks,
> Troy
>
>
> On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
>  wrote:
> >>We have a folder /trunk/docs, shouldn't this be the place for that?
> >
> > We should have a live site for the documentation that people can browse,
> > similar to the parent project's site.
> > http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
> > documentation more accessible.
> >
> > The rub is that Sandcastle & SHFB generates html files with guid names,
> xml
> > & bin files that map to the html files, and aspx pages which acts as the
> > glue. The aspx pages parses the xml/bin files which creates the document
> > site.  Thus we're now required to use a server that knows how to serve up
> > aspx pages.
> >
> > If any one knows a way to generate just vanilla html using Sandcastle &
> > SHFB, I could just create a folder per version and push the docs to
> > incubator site. But so far I haven't found an option for this.
> >
> > Keeping the generated help docs inside of source would still require for
> > users to setup a local website just to view the documentation and it adds
> > extra noise in the project.
> >
> > In the release we can provide a zipped file of the site and a generated
> .chm
> > or even help2/3 files.
> >
> > On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser  >wrote:
> >
> >>
> >> >
> >> > 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 <
> geobmx...@hotmail.com
> >> >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] coordinating keys, project passwords, and other artifacts

[Michael Herndon]

That would be perfect actually, especially if the builder server would be
able to check out from it.

We could store api keys (like for nuget) there, script to look for certain
files and push release builds to nuget.org if those files exist.


On Fri, Sep 23, 2011 at 7:43 AM, Stefan Bodewig  wrote:

> On 2011-09-23, Michael Herndon wrote:
>
> > Other than talking on the private list, is there any infrastructure to
> > sharing api keys, passwords for committers of a project?   I've tried
> > looking at docs on people.apache.org, infra, and other others place but
> no
> > dice so far. The issue with the private list is that if the whole team
> turns
> > over, only certain people can search over those lists for past e-mails.
>
> There is a private svn repository you could use with read access
> restricted to PPMC members.  I can help out setting up the area for
> lucene.net if it doesn't already exist.
>
> Stefan
>

Re: [Lucene.Net] svn commit: r1174633 - in /incubator/lucene.net/trunk/build/scripts: All/Lucene.Net.nuspec All/project.targets Contrib/Lucene.Net.Contrib.nuspec Contrib/project.targets

[Michael Herndon]

added. though I'll need to figure out if posh actually handles multiline
comments rather than pushing out the license as a string.

On Fri, Sep 23, 2011 at 7:40 AM, Stefan Bodewig  wrote:

> Michael,
>
> On 2011-09-23,  wrote:
>
> > Added: incubator/lucene.net/trunk/build/scripts/All/Lucene.Net.nuspec
>
> >> 
> >> http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd";>
> >>  
> >>Lucene.Net.Core
> >>$version$
>
> This - and other files you've recently added - lacks the license header,
> can you please add it before anybody builds a release candidate and gets
> shot down by RAT? 8-)
>
> Thanks
>
> Stefan
>

[Lucene.Net] coordinating keys, project passwords, and other artifacts

[Michael Herndon]

Other than talking on the private list, is there any infrastructure to
sharing api keys, passwords for committers of a project?   I've tried
looking at docs on people.apache.org, infra, and other others place but no
dice so far. The issue with the private list is that if the whole team turns
over, only certain people can search over those lists for past e-mails.

This is in regards to sharing a nuget api-key and then getting it on the
build server, a shared twitter account.

Obviously we don't want to post those kinds of things on a public list or
keeping them in svn.

- Michael

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

[Michael Herndon]

rsday, 22 September 2011 7:42 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
>
> Sorry, but I feel the same as Neal.
>
> DIGY
>
> -Original Message-----
> From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com]
> Sent: Wednesday, September 21, 2011 6:08 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
>
> No interest in Nuget whatsoever.
>
> - Neal
>
> -Original Message-
> From: Michael Herndon [mailto:mhern...@wickedsoftware.net]
> Sent: Tuesday, September 20, 2011 10:57 PM
> To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
> Subject: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
>
> We're taking a quick poll over the next few days to see how people would
> like use Lucene.Net through Nuget on the developers mailing list**
>
> Currently version 2.9.2 is hosted on nuget.org, but that package was not
> create by the project maintainers, thus nuget is not currently set up in
> source.  Going forward, we would like to continue what someone else started
> by creating nuget packages for Lucene.Net.
>
> 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.
>
> The granular approach will let you use only what you need. We can also
> create additional higher level packages which have dependencies on the
> other
> ones.   Possibly a Lucene.Net-Essentials and Lucene.Net-Full.
>
> Or we can keep it simple and continue with only two packages.
>
> My concerns are that the granular approach might overwhelm people with
> choice. The simple choice might be considered bloat for importing and then
> installing assemblies that you might never use.
>
>
> 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?
>
>
> ** when you post, please respond to lucene-net-dev@lucene.apache.org.
>  This
> was posted to both lists to make sure everyone subscribed to both lists has
> a chance to voice their use cases or concerns.
> -
>
> Checked by AVG - www.avg.com
> Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11
>
> -
>
> Checked by AVG - www.avg.com
> Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11
>
>
>
>

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

[Michael Herndon]

@Digy, that could be done post build with ILMerge or build an additional
uber assembly that stores other assemblies as a resource.
http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx

We can add the above to the build process if that would interest people.

To some nuget is just another disruption and  to others its a godsend.  Some
might say only hipsters would use nuget, others might say the cools kids
with iphones use nuget. (or android or wp7).

At the end of the day nuget or combining assemblies are just channels/ways
we can make it easier for various developers to consume & get their hands on
Lucene.Net. If anyone else has ideas along those lines and it can be
automated, post it in this thread.





On Wed, Sep 21, 2011 at 6:00 PM, Digy  wrote:

> Even all contribs could be a single project/assembly. That way, users could
> reference all contribs with a single assembly.
> I see no harm in putting a few KB pressure on RAM :)
>
> DIGY
>
>
> -Original Message-
> From: Troy Howard [mailto:thowar...@gmail.com]
> Sent: Wednesday, September 21, 2011 7:32 AM
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
>
> While it may be a bit redundant, why couldn't there be an individual
> package for each piece of contrib and a "Lucene.Net Contrib (All)"
> package that drags them all down.
>
> That way users can grab just the bit they need, or if they just want
> to get the whole thing, grab the "All" package.
>
> Thanks,
> Troy
>
>
> On Tue, Sep 20, 2011 at 9:11 PM, Aaron Powell  wrote:
> > I'm going to vote +1 for granular.
> >
> > With the RC you could look at myget and have a Lucene.Net repository on
> there so people can go for unstable on myget, stables on nuget.
> >
> > Also, I came across this article which explains how to setup a build
> server to automatically push to nuget/ myget which could be useful to the
> maintainers:
> http://brendanforster.com/doing-the-build-server-dance-with-nuget.html
> >
> > Aaron Powell
> > MVP - Internet Explorer (Development) | FunnelWeb Team Member
> >
> > http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell |
> Github | BitBucket
> >
> > -Original Message-
> > From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> > Sent: Wednesday, 21 September 2011 2:05 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
> >
> >
> >> 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
> >
> -
>
> Checked by AVG - www.avg.com
> Version: 2012.0.1808 / Virus Database: 2085/4508 - Release Date: 09/20/11
>
>

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

@all,

I updated the build scripts to increase it's granularity.
https://cwiki.apache.org/LUCENENET/build-system-scripts.html

Similarity was include, though are there any tests for this project ?

Some of the contrib tests are failing, I saw a few in Contrib.Highlighter
just glancing at the output .

I recieved some feedback Eric Woodruff. It looks like SHFB & Sandcastle
generate a plain file html, its been staring me in the face this whole time.
 I'll need to build in some targets that extract whats needed to push to
site branch. Then I'll start working on nuget.

@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

[Michael Herndon]

I'm with you on checking in the static files into ~/site/doc/version

that would be pretty easy to automate from jenkins & msbuild if we can get
the docs into static html.

 I currently just push all assemblies, help files, xml docs into ~/trunk/bin
on the user's local once the scripts finish building, running tests, and
reports. Nothing gets commited into svn from this at the moment.  The site
is generated, but not pushed anywhere.

I was waiting to see how aspx thing plays out & getting CI up with nuget
before setting up a build release build task that automates everything
including pushing the docs, finalized content, etc.

So my real question is, do we need to store static docs that are generate in
~/trunk/docs/?

If so, could we store those in a single file format and just provide a setup
script that takes care of extracting the latest for the user versus putting
all those files into trunk.

Technically someone could build an post process hook that builds up a static
html index  from xml & bin files, but I'm hoping it does not come to that.


 - Michael







On Wed, Sep 21, 2011 at 12:56 AM, Troy Howard  wrote:

> Why would we want to do that?
>
> Under the /site/docs directory, they need to be served up as loose HTML...
>
> IMO the XML files shouldn't be checked into SVN because they are
> auto-generated. The same goes for Sandcastle files.. However, in the
> release packages, I think we should include the XML files as well as a
> fully functional version of the Sandcastle docs that can be viewed
> locally. I personally thing CHMs are terrible user experience, and I'd
> much rather have a static HTML site I can browse locally, if we're
> going to bother including a copy of the documentation in the package,
> vs just hosting it online and calling that good (this is what most
> projects these days do). Good thing about hosting online -- searchable
> via google.
>
> Thanks,
> Troy
>
>
> On Tue, Sep 20, 2011 at 9:48 PM, Michael Herndon
>  wrote:
> > Could we store sandcastle docs as a single zip/chm?
> >
> >
> >
> > On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard 
> wrote:
> >
> >> At one time I had a SVN server set up at work that had a post-commit
> >> hook set up that would generate a static HTML site from the XML doc
> >> files using Sandcastle. So.. It can be done. That was about 3-4 years
> >> ago and I don't work at that company any longer, so I don't have
> >> access to the details of how that was done.
> >>
> >> Regarding SVN locations...
> >>
> >> Autogenerated XML doc files should go in the ~/trunk/doc/
> >> folders. The Sandcastle generated static HTML should go under
> >> ~/site/docs/ folders.
> >>
> >> I'll see if I can't dig up some info on how to generate static HTML
> >> with Sandcastle.
> >>
> >> Thanks,
> >> Troy
> >>
> >>
> >> On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
> >>  wrote:
> >> >>We have a folder /trunk/docs, shouldn't this be the place for that?
> >> >
> >> > We should have a live site for the documentation that people can
> browse,
> >> > similar to the parent project's site.
> >> > http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it
> the
> >> > documentation more accessible.
> >> >
> >> > The rub is that Sandcastle & SHFB generates html files with guid
> names,
> >> xml
> >> > & bin files that map to the html files, and aspx pages which acts as
> the
> >> > glue. The aspx pages parses the xml/bin files which creates the
> document
> >> > site.  Thus we're now required to use a server that knows how to serve
> up
> >> > aspx pages.
> >> >
> >> > If any one knows a way to generate just vanilla html using Sandcastle
> &
> >> > SHFB, I could just create a folder per version and push the docs to
> >> > incubator site. But so far I haven't found an option for this.
> >> >
> >> > Keeping the generated help docs inside of source would still require
> for
> >> > users to setup a local website just to view the documentation and it
> adds
> >> > extra noise in the project.
> >> >
> >> > In the release we can provide a zipped file of the site and a
> generated
> >> .chm
> >> > or even help2/3 files.
> >> >
> >> > On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser <
> geobmx...@hotmail.com
> >> 

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

Could we store sandcastle docs as a single zip/chm?



On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard  wrote:

> At one time I had a SVN server set up at work that had a post-commit
> hook set up that would generate a static HTML site from the XML doc
> files using Sandcastle. So.. It can be done. That was about 3-4 years
> ago and I don't work at that company any longer, so I don't have
> access to the details of how that was done.
>
> Regarding SVN locations...
>
> Autogenerated XML doc files should go in the ~/trunk/doc/
> folders. The Sandcastle generated static HTML should go under
> ~/site/docs/ folders.
>
> I'll see if I can't dig up some info on how to generate static HTML
> with Sandcastle.
>
> Thanks,
> Troy
>
>
> On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
>  wrote:
> >>We have a folder /trunk/docs, shouldn't this be the place for that?
> >
> > We should have a live site for the documentation that people can browse,
> > similar to the parent project's site.
> > http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
> > documentation more accessible.
> >
> > The rub is that Sandcastle & SHFB generates html files with guid names,
> xml
> > & bin files that map to the html files, and aspx pages which acts as the
> > glue. The aspx pages parses the xml/bin files which creates the document
> > site.  Thus we're now required to use a server that knows how to serve up
> > aspx pages.
> >
> > If any one knows a way to generate just vanilla html using Sandcastle &
> > SHFB, I could just create a folder per version and push the docs to
> > incubator site. But so far I haven't found an option for this.
> >
> > Keeping the generated help docs inside of source would still require for
> > users to setup a local website just to view the documentation and it adds
> > extra noise in the project.
> >
> > In the release we can provide a zipped file of the site and a generated
> .chm
> > or even help2/3 files.
> >
> > On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser  >wrote:
> >
> >>
> >> >
> >> > 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 <
> geobmx...@hotmail.com
> >> >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

[Michael Herndon]

On Wed, Sep 21, 2011 at 12:31 AM, Troy Howard  wrote:

> While it may be a bit redundant, why couldn't there be an individual
> package for each piece of contrib and a "Lucene.Net Contrib (All)"
> package that drags them all down.
>
> That way users can grab just the bit they need, or if they just want
> to get the whole thing, grab the "All" package.
>
> Thanks,
> Troy
>


That was the idea for the Lucene.Net-Essentials & Lucene.Net-Full packages.

"We can also create additional higher level packages which have dependencies
on the other ones.   Possibly a Lucene.Net-Essentials and Lucene.Net-Full."



>
>
> On Tue, Sep 20, 2011 at 9:11 PM, Aaron Powell  wrote:
> > I'm going to vote +1 for granular.
> >
> > With the RC you could look at myget and have a Lucene.Net repository on
> there so people can go for unstable on myget, stables on nuget.
> >
> > Also, I came across this article which explains how to setup a build
> server to automatically push to nuget/ myget which could be useful to the
> maintainers:
> http://brendanforster.com/doing-the-build-server-dance-with-nuget.html
> >
> > Aaron Powell
> > MVP - Internet Explorer (Development) | FunnelWeb Team Member
> >
> > http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell |
> Github | BitBucket
> >
> > -Original Message-
> > From: Prescott Nasser [mailto:geobmx...@hotmail.com]
> > Sent: Wednesday, 21 September 2011 2:05 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
> >
> >
> >> 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

[Michael Herndon]

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

We should have a live site for the documentation that people can browse,
similar to the parent project's site.
http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
documentation more accessible.

The rub is that Sandcastle & SHFB generates html files with guid names, xml
& bin files that map to the html files, and aspx pages which acts as the
glue. The aspx pages parses the xml/bin files which creates the document
site.  Thus we're now required to use a server that knows how to serve up
aspx pages.

If any one knows a way to generate just vanilla html using Sandcastle &
SHFB, I could just create a folder per version and push the docs to
incubator site. But so far I haven't found an option for this.

Keeping the generated help docs inside of source would still require for
users to setup a local website just to view the documentation and it adds
extra noise in the project.

In the release we can provide a zipped file of the site and a generated .chm
or even help2/3 files.

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

>
> >
> > 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  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
>

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

[Michael Herndon]

We're taking a quick poll over the next few days to see how people would
like use Lucene.Net through Nuget on the developers mailing list**

Currently version 2.9.2 is hosted on nuget.org, but that package was not
create by the project maintainers, thus nuget is not currently set up in
source.  Going forward, we would like to continue what someone else started
by creating nuget packages for Lucene.Net.

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.

The granular approach will let you use only what you need. We can also
create additional higher level packages which have dependencies on the other
ones.   Possibly a Lucene.Net-Essentials and Lucene.Net-Full.

Or we can keep it simple and continue with only two packages.

My concerns are that the granular approach might overwhelm people with
choice. The simple choice might be considered bloat for importing and then
installing assemblies that you might never use.


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?


** when you post, please respond to lucene-net-dev@lucene.apache.org.  This
was posted to both lists to make sure everyone subscribed to both lists has
a chance to voice their use cases or concerns.

[Lucene.Net] [jira] [Commented] (LUCENENET-443) SpellChecker finaliser calls close regardless of if closed already

[michael herndon (JIRA)]

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

michael herndon commented on LUCENENET-443:
---

Stuart, trunk was updated with typical MS style IDisposable pattern which 
replaced the this.Close() in the finalizer. Calling Dispose() will check to see 
if the SpellChecker is still open before calling Close() and suppress the 
finalizer.  

Leaving this open for a few days before resolving. 

- Michael 

> SpellChecker finaliser calls close regardless of if closed already
> --
>
> Key: LUCENENET-443
> URL: https://issues.apache.org/jira/browse/LUCENENET-443
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.2
>Reporter: Stuart Robinson
>Assignee: michael herndon
>  Labels: lucene, spellcheck, spellchecker
>
> The SpellChecker Class currently has no publicly visible way of accessing the 
> closed field. It also calls close in the finaliser killing the process it is 
> in upon GC as this can throw an exceptin. I propose two changes:
> Change the already existing method "IsClosed()" to public:
> public bool IsClosed()
> {
> return closed;
> }
> and add a check on this in the finaliser:
> ~SpellChecker()
> {
> if (!IsClosed())
> this.Close();
> }
> Ideally this class should implement IDisposable but I think this would be a 
> bigger job than this two line change.

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

[Lucene.Net] [jira] [Assigned] (LUCENENET-443) SpellChecker finaliser calls close regardless of if closed already

[michael herndon (JIRA)]

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

michael herndon reassigned LUCENENET-443:
-

Assignee: michael herndon

> SpellChecker finaliser calls close regardless of if closed already
> --
>
> Key: LUCENENET-443
> URL: https://issues.apache.org/jira/browse/LUCENENET-443
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.2
>Reporter: Stuart Robinson
>Assignee: michael herndon
>  Labels: lucene, spellcheck, spellchecker
>
> The SpellChecker Class currently has no publicly visible way of accessing the 
> closed field. It also calls close in the finaliser killing the process it is 
> in upon GC as this can throw an exceptin. I propose two changes:
> Change the already existing method "IsClosed()" to public:
> public bool IsClosed()
> {
> return closed;
> }
> and add a check on this in the finaliser:
> ~SpellChecker()
> {
> if (!IsClosed())
> this.Close();
> }
> Ideally this class should implement IDisposable but I think this would be a 
> bigger job than this two line change.

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

Re: [Lucene.Net] who is our current PMC

[Michael Herndon]

The rest needs to be done by jenkins admins and/or myself.  I just need to
confirm tool chains available on slaves and work the admins and then setup
the builds for trunk and the branches.

I've setup jenkins on my home server already and went through the steps.
There were some some issues with trunk that I'll fix sometime this week, the
other branches should be good to go.  There were also a few extra steps
since visual studio wasn't installed.

Hopefully we'll have builds rolling by the end of this month =)

Thanks Stefan.


On Sun, Sep 18, 2011 at 1:39 AM, Stefan Bodewig  wrote:

> On 2011-09-18, Michael Herndon wrote:
>
> > So would requesting getting an account  be requested on
> lucene-net-private@
> > incubator.apache.org ?
>
> Creating the account requires PMC chairman karma, which I happen to
> posess.  I've just added you to the hudson-jobadmin group.
>
> I don't see any place that mentions a private mailing list on the Wiki
> page at all, so I assume you were looking for the PMC chairman to help
> out.  Well, that would have been private at incubator.
>
> Do you need me to do anything more (I'm not familiar with our Jenkins
> setup at all)?
>
> Stefan
>

Re: [Lucene.Net] who is our current PMC

[Michael Herndon]

So would requesting getting an account  be requested on lucene-net-private@
incubator.apache.org ?

Just trying to follow along whats in the wiki here about getting a build
setup.
http://wiki.apache.org/general/Hudson

On Sun, Sep 18, 2011 at 12:39 AM, Stefan Bodewig  wrote:

> On 2011-09-17, Michael Herndon wrote:
>
> > Who is our current PMC?
>
> The Incubator PMC.
>
> Stefan
>

[Lucene.Net] who is our current PMC

[Michael Herndon]

Who is our current PMC?  I feel stupid for asking, but I can't find it on
the wiki, site, etc.  I need to get a build account and get all the fun CI
stuff setup.

- michael

[Lucene.Net] [jira] [Commented] (LUCENENET-443) SpellChecker finaliser calls close regardless of if closed already

[michael herndon (JIRA)]

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

michael herndon commented on LUCENENET-443:
---

I should have some over the weekend to fix it, though it would go into trunk 
and the next release.  

> SpellChecker finaliser calls close regardless of if closed already
> --
>
> Key: LUCENENET-443
> URL: https://issues.apache.org/jira/browse/LUCENENET-443
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 2.9.2
>Reporter: Stuart Robinson
>  Labels: lucene, spellcheck, spellchecker
>
> The SpellChecker Class currently has no publicly visible way of accessing the 
> closed field. It also calls close in the finaliser killing the process it is 
> in upon GC as this can throw an exceptin. I propose two changes:
> Change the already existing method "IsClosed()" to public:
> public bool IsClosed()
> {
> return closed;
> }
> and add a check on this in the finaliser:
> ~SpellChecker()
> {
> if (!IsClosed())
> this.Close();
> }
> Ideally this class should implement IDisposable but I think this would be a 
> bigger job than this two line change.

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

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

> 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
> > >> >
> > >> > Digy, can you make sure the github mirror contains an updated 2.9.4
> > tag
> > >> I
> > >> > can pull from, which includes the latest ThreadLocal fix + the
> > strongly
> > >> > signed patch applied to it?
> > >> >
> > >> > 2011/9/6 Digy 
> > >> >
> > >> > > 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
> > >> > >
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

Should we put together a quick release checklist ?

 * I know that jira 407 mentions putting out a 2.9.2 build that is signed
when releasing 2.9.4

 * We should be able to build a chm & doc website using sandcastle.The
downside is the website that gets built now requires asp.net instead of just
vanilla HTML and I have yet to find an option that allows just HTML.
Depending on what we do with this, we would need to remove the link to the
docs in the README file inside of trunk.

* Stefan Bodewig might still be away and I think we need his vote on the
release when the time comes. (correct me, because I could be uber wrong).

If there is anything that requires work and you think I can help with in
order to get this release out the door, just let me know.

- Michael



On Tue, Sep 6, 2011 at 9:11 PM, Prescott Nasser wrote:

>
> 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] 2.9.4

[Michael Herndon]

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
>
> Digy, can you make sure the github mirror contains an updated 2.9.4 tag I
> can pull from, which includes the latest ThreadLocal fix + the strongly
> signed patch applied to it?
>
> 2011/9/6 Digy 
>
> > 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
> >
>
>
>

[Lucene.Net] build scripts & snk in trunk, website, and lucene.net_4e branch.

[Michael Herndon]

All,

I hope everyone is doing well despite Earthquakes and Hurricanes. Here are
some updates.


[Build Script & CI Changes]

A strong named key and Build scripts were added to the trunk.  Doc comments
files only build in release mode since they increase the warnings in visual
studio by about 2000+ warnings.  pragma 618 was disabled since there are a
ton obsolete methods in side of Lucene.Net 2.9x series.

The binaries are now building to he /build/bin path. When you run the build
scripts and the build passes, the binaries will be moved into the /bin
folder along with xml docs and the chm files that gets generated if you have
sandcastle installed.

We should be able to get CI up and running by the end of September.  The
tests in trunk will need to be fixed up before then. There are path issues
that were fixed in the 2.9.4g branch tests but not ported to trunk. The
NUnit Runner seems to be having issues with the serializers now that
assemblies are strongly named. (Yet the same tests run fine in Resharper &
TestDriven.Net).   So the issue with the NUnit Runner and the serializers
will need to be fixed before then.

If you're looking for something to do, I've noticed there are some warnings
about CLSCompliance, those definitely need to be fixed at some point


[Website]

We should be updating the news on the website monthly to give people a
reason to keep coming back. Also adding a twitter widget that searches on
the #lucenenet hash tag and lucene.net search term would also help.  If
there are no objections to this in the next week or so, i'll update the site
(unless someone beats me to it).


[The experimental Lucene.Net_4e branch].

I've put some wiki docs together for this branch.
https://cwiki.apache.org/confluence/display/LUCENENET/Lucene.Net+4.x
https://cwiki.apache.org/confluence/display/LUCENENET/Lucene+4x+Port+Progress


Its experimental for a few reasons:
 * its using the .NET portable class library tools.  Its currently targeting
the Full Framework, Silverlight 4, and Silverlight for WP7.0
 * it lets you run tests under both MbUnit and NUnit.
 * it has stylecop installed with the defacto rules and [SupressMessage]
sprinkled throughout for FxCop. The rules can be changed later and we can
use something like ReSharper to format code according to whatever rules are
finally decided on.
 * experimenting with ways to tackle future changes using tags/diffs and
tools like beyond compare coupled with notating what works needs to be done
using the wiki.
 * this will definitely lean more towards a more .NET idiomatic API
 * there are ItemTemplates for class, enum, interface, and unit tests that
include the Apache License in the top of the file, feel free to modify these
and put these into trunk. You can find these files under /tools.
 * heavy attention doc comments.

Anyone is welcome to pull this branch and work on it. Just make sure you
note "In Progress" on the files  your working on.  This branch is probably
where I'll be spending most of my time when working on Lucene.Net for a
while. Though I'll continue to work on getting CI up and helping on other
branches when asked people specify needs, especially anything that would
help us get 2.9.4 release out.

There are some pretty big challenges with getting Lucene.Net to work in
Silverlight for WP7.0. Threading is bare bones. TheadLocal,
[ThreadStatic] and the api around LocalDataStoreSlot does not exist.  The
PCL is still in flux (an example is that System.String currently doesn't
appear to implement IEnumerable) so using that provides some
interesting challenges as well.  I'd recommend moving forward making
Lucene.Net useable for those platforms on this branch rather than trying to
force that into the line-by-line ports in trunk and 2.9.4.g.

I'll try to build up the wiki as a knowledge resource while porting code on
this branch, so you might want to check the wiki periodically.

- Michael.

[Lucene.Net] [jira] [Closed] (LUCENENET-400) Evaluate tooling for continuous integration server

[michael herndon (JIRA)]

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

michael herndon closed LUCENENET-400.
-


https://cwiki.apache.org/LUCENENET/build-system-scripts.html  

the evaluation of tools over. the next thing to do is to put the scripts into 
trunk, make sure at least all the tests pass and get this setup in hudkins 
(jenkins) 

> Evaluate tooling for continuous integration server
> --
>
> Key: LUCENENET-400
> URL: https://issues.apache.org/jira/browse/LUCENENET-400
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Project Infrastructure
>Reporter: Troy Howard
>    Assignee: michael herndon
> Fix For: Lucene.Net 2.9.4g
>
>
> We would like to have a CI server setup for Lucene.Net.
> It has been suggested to do this outside of the ASF infrastructure, but this 
> would not work for ASF. 
> Please review the available options at http://ci.apache.org/ and evaluate 
> which CI server system would be preferred for our setup. 

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

[Lucene.Net] [jira] [Resolved] (LUCENENET-400) Evaluate tooling for continuous integration server

[michael herndon (JIRA)]

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

michael herndon resolved LUCENENET-400.
---

   Resolution: Fixed
Fix Version/s: Lucene.Net 2.9.4g

> Evaluate tooling for continuous integration server
> --
>
> Key: LUCENENET-400
> URL: https://issues.apache.org/jira/browse/LUCENENET-400
> Project: Lucene.Net
>  Issue Type: Task
>  Components: Build Automation, Project Infrastructure
>Reporter: Troy Howard
>    Assignee: michael herndon
> Fix For: Lucene.Net 2.9.4g
>
>
> We would like to have a CI server setup for Lucene.Net.
> It has been suggested to do this outside of the ASF infrastructure, but this 
> would not work for ASF. 
> Please review the available options at http://ci.apache.org/ and evaluate 
> which CI server system would be preferred for our setup. 

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

[Lucene.Net] [jira] [Closed] (LUCENENET-440) Some of the links on the website don't work

[michael herndon (JIRA)]

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

michael herndon closed LUCENENET-440.
-


> Some of the links on the website don't work
> ---
>
> Key: LUCENENET-440
> URL: https://issues.apache.org/jira/browse/LUCENENET-440
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Project Infrastructure
>Reporter: David Betteridge
>    Assignee: michael herndon
>Priority: Minor
> Fix For: Lucene.Net 2.9.4
>
>
> The link to download the binarys from the home page doesn't work.  I'm using 
> I.E. 9 and it thinks the link is 
> http://http//www.apache.org/dist/incubator/lucene.net/binaries/
> Note the duplicate http at the front!

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

[Lucene.Net] [jira] [Resolved] (LUCENENET-440) Some of the links on the website don't work

[michael herndon (JIRA)]

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

michael herndon resolved LUCENENET-440.
---

   Resolution: Fixed
Fix Version/s: Lucene.Net 2.9.4

links were fixed and pushed, closing bug.


@Alex 

I've put the links under the wiki's idea page for now since this bug is really 
about broken links/functionality and not new content.

 * https://cwiki.apache.org/LUCENENET/ideas.html

Hopefully others will add some more links. I know there are plenty of articles 
and content spread out across the web. 

If you wish you can open another jira task for adding new content to the site.  
 


> Some of the links on the website don't work
> ---
>
> Key: LUCENENET-440
> URL: https://issues.apache.org/jira/browse/LUCENENET-440
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Project Infrastructure
>Reporter: David Betteridge
>Assignee: michael herndon
>Priority: Minor
> Fix For: Lucene.Net 2.9.4
>
>
> The link to download the binarys from the home page doesn't work.  I'm using 
> I.E. 9 and it thinks the link is 
> http://http//www.apache.org/dist/incubator/lucene.net/binaries/
> Note the duplicate http at the front!

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

[Lucene.Net] [jira] [Assigned] (LUCENENET-440) Some of the links on the website don't work

[michael herndon (JIRA)]

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

michael herndon reassigned LUCENENET-440:
-

Assignee: michael herndon

> Some of the links on the website don't work
> ---
>
> Key: LUCENENET-440
> URL: https://issues.apache.org/jira/browse/LUCENENET-440
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Project Infrastructure
>Reporter: David Betteridge
>    Assignee: michael herndon
>Priority: Minor
>
> The link to download the binarys from the home page doesn't work.  I'm using 
> I.E. 9 and it thinks the link is 
> http://http//www.apache.org/dist/incubator/lucene.net/binaries/
> Note the duplicate http at the front!

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

[Lucene.Net] [jira] [Commented] (LUCENENET-440) Some of the links on the website don't work

[michael herndon (JIRA)]

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

michael herndon commented on LUCENENET-440:
---

Changes were pushed to the live site last night. if there are no more 
corrections, I'll close this bug tomorrow. 

> Some of the links on the website don't work
> ---
>
> Key: LUCENENET-440
> URL: https://issues.apache.org/jira/browse/LUCENENET-440
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Project Infrastructure
>Reporter: David Betteridge
>Priority: Minor
>
> The link to download the binarys from the home page doesn't work.  I'm using 
> I.E. 9 and it thinks the link is 
> http://http//www.apache.org/dist/incubator/lucene.net/binaries/
> Note the duplicate http at the front!

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

[Lucene.Net] [jira] [Commented] (LUCENENET-440) Some of the links on the website don't work

[michael herndon (JIRA)]

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

michael herndon commented on LUCENENET-440:
---

Fixes have been posted to staging.
http://lucene.net.staging.apache.org/lucene.net/

I'm leaving this issue open in case there are other dead or malformed links.

The mailing archive looks like it was merged.  

> Some of the links on the website don't work
> ---
>
> Key: LUCENENET-440
> URL: https://issues.apache.org/jira/browse/LUCENENET-440
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Project Infrastructure
>Reporter: David Betteridge
>Priority: Minor
>
> The link to download the binarys from the home page doesn't work.  I'm using 
> I.E. 9 and it thinks the link is 
> http://http//www.apache.org/dist/incubator/lucene.net/binaries/
> Note the duplicate http at the front!

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

Re: [Lucene.Net] Board Report Nudge

[Michael Herndon]

* I understand that (will be away myself soon as well) but I'm sure not
* all of you will be on vacation at the same time 8-)

that would awesome if that randomly happened.

Updated: http://wiki.apache.org/incubator/August2011: anyone looking into
this thread feel free to tweak.
--

Lucene.Net was accepted into the Apache Incubator in February 2011.
Originally it was a sub project of the Lucene Project.

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:
* 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.
* High-performance C# search engine library.
* 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.

Recent Activity:

* Lucene.Net 2.9.4 & 2.9.4g are being worked on and tested
* Prototyped build scripts with ncover, fxcop, style cop, nunit/mbunit, and
sandcastle have been made.

Current Activities:

* New site design per new Lucene.Net logo.
* Working towards getting CI installed.
* The shingle filter was ported
* A simple faceted search contrib project was created.
* Develop a process to automatically (as much as possible) convert the Java
Lucene code to C# (to maintain our line by line port)

Goals for graduation:

* Have a nearly fully automated process to convert Java Lucene to C#.
* Release Lucene.Net 3.0.3 (port of Java Lucene 3.0.3)
* Have a new .NET version of Lucene utilizing .NET constructs and idioms
-

On Wed, Aug 10, 2011 at 1:15 AM, Stefan Bodewig  wrote:

> On 2011-08-09, Michael Herndon wrote:
>
> > Has this been taken care of?
>
> No, see <http://wiki.apache.org/incubator/August2011>
>
> > If not. Let me know what is needed and I'll make sure it gets done
> > tonight.
>
> Thank you.
>
> I'm not sure what exactly is needed.  Use a small blurb that describes
> what Lucene.NET is/does, report what you've done during the past
> quarter, what is standing in the way for graduation and what you are
> doing in order to get that out of the way.
>
> A good starting point will be the report submitted in May.  And take a
> look at the other reports (those of medium size length, we don't need
> novels either ;-).
>
> > Its summer and people could be on much deserved vacation.
>
> I understand that (will be away myself soon as well) but I'm sure not
> all of you will be on vacation at the same time 8-)
>
> Stefan
>

Re: [Lucene.Net] Board Report Nudge

[Michael Herndon]

Hey Stefan,

Has this been taken care of? If not. Let me know what is needed and I'll
make sure it gets done tonight. Its summer and people could be on much
deserved vacation.

- Michael

On Mon, Aug 8, 2011 at 12:08 AM, Stefan Bodewig  wrote:

> Hi,
>
> Lucene.NET's quarterly board report is due this month, please make sure
> there is some content at http://wiki.apache.org/incubator/August2011 by
> Wednesday.
>
> Thanks
>
>Stefan
>

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

[Michael Herndon]

I've put * my local git branch.

On Fri, Aug 5, 2011 at 3:45 PM, Michael Herndon  wrote:

> Hey all,
>
> I put an experimental branch up targeted towards lucene 4 called
> Lucene.Net_4e  (e for experimental)
>
> This was initially for me to provide an easier way to create the build
> scripts and experiment with nuget, nunit, ncover, gallio, sandcastle, fxcop,
> and the portable library project. I've my local git branch for that into the
> project for the short term.
>
> This should let everyone see how style cop wants you to code with the
> default rules enabled.  You will need vs sp1 installed and PLP tools (
> http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981/)
> installed to open the project inside of visual studio.  To run the other
> tools, look at the readme.txt.
>
> I didn't want to further disrupt the v2.9.4g branch. When I'm done with the
> build scripts I can backport those to trunk and v2.9.4g branch.
>
> - Michael
>
>
>
> On Mon, Aug 1, 2011 at 2:46 PM, Scott Lombard wrote:
>
>> The only problem with some modifying the code in this manor is it is going
>> to make it difficult to manually port from Java.  Digy has talked about
>> this
>> in the past and can provide more detail.  The summary is that as the code
>> and comments diverge from the Java code it gets harder port Java patches.
>>  I
>> am not sure where the balance is.
>>
>> Scott
>>
>> > -Original Message-
>> > From: Michael Herndon [mailto:mhern...@wickedsoftware.net]
>> > Sent: Monday, August 01, 2011 2:05 PM
>> > To: lucene-net-dev@lucene.apache.org
>> > Subject: Re: [Lucene.Net] style cop, fx cop rules
>> >
>> > StyleCop by default adheres strictly to ms coding guidelines and then
>> > some.
>> >  http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx (even
>> though
>> > a
>> > deal of the internals of the framework breaks these rules).
>> >
>> > You can turns rules off but if you want rules that differ from the
>> default
>> > ones, rules would need to be created. Though a few of the rules do
>> > look customizable.   I can install style cop into the project those into
>> > the
>> > project and turn off rules, anything further will be left up to
>> > the community. Though I'd suggest turning rules down a notch for the
>> > testing
>> > projects.
>> >
>> > I can make scripts to run fxcop, but it will be left up to each
>> individual
>> > to install it. FxCop 10.0 only now comes with the win 7.1 sdk for .net 4
>> > and
>> > it does not seem to be redistributable.  And judging by the size of it
>> > now Its probably best that isn't put into source anyways.
>> >
>> > On Mon, Aug 1, 2011 at 1:47 PM, Troy Howard 
>> wrote:
>> >
>> > > Agreed. StyleCop and FxCop are both quite handy and can only serve to
>> > > benefit the project.
>> > >
>> > > -T
>> > >
>> > > On Mon, Aug 1, 2011 at 10:39 AM, Prescott Nasser <
>> geobmx...@hotmail.com>
>> > > wrote:
>> > > >
>> > > >
>> > > >
>> > > >>
>> > > >> 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 para

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

[Michael Herndon]

Hey all,

I put an experimental branch up targeted towards lucene 4 called
Lucene.Net_4e  (e for experimental)

This was initially for me to provide an easier way to create the build
scripts and experiment with nuget, nunit, ncover, gallio, sandcastle, fxcop,
and the portable library project. I've my local git branch for that into the
project for the short term.

This should let everyone see how style cop wants you to code with the
default rules enabled.  You will need vs sp1 installed and PLP tools (
http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981/)
installed to open the project inside of visual studio.  To run the other
tools, look at the readme.txt.

I didn't want to further disrupt the v2.9.4g branch. When I'm done with the
build scripts I can backport those to trunk and v2.9.4g branch.

- Michael



On Mon, Aug 1, 2011 at 2:46 PM, Scott Lombard wrote:

> The only problem with some modifying the code in this manor is it is going
> to make it difficult to manually port from Java.  Digy has talked about
> this
> in the past and can provide more detail.  The summary is that as the code
> and comments diverge from the Java code it gets harder port Java patches.
>  I
> am not sure where the balance is.
>
> Scott
>
> > -Original Message-
> > From: Michael Herndon [mailto:mhern...@wickedsoftware.net]
> > Sent: Monday, August 01, 2011 2:05 PM
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: [Lucene.Net] style cop, fx cop rules
> >
> > StyleCop by default adheres strictly to ms coding guidelines and then
> > some.
> >  http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx (even
> though
> > a
> > deal of the internals of the framework breaks these rules).
> >
> > You can turns rules off but if you want rules that differ from the
> default
> > ones, rules would need to be created. Though a few of the rules do
> > look customizable.   I can install style cop into the project those into
> > the
> > project and turn off rules, anything further will be left up to
> > the community. Though I'd suggest turning rules down a notch for the
> > testing
> > projects.
> >
> > I can make scripts to run fxcop, but it will be left up to each
> individual
> > to install it. FxCop 10.0 only now comes with the win 7.1 sdk for .net 4
> > and
> > it does not seem to be redistributable.  And judging by the size of it
> > now Its probably best that isn't put into source anyways.
> >
> > On Mon, Aug 1, 2011 at 1:47 PM, Troy Howard  wrote:
> >
> > > Agreed. StyleCop and FxCop are both quite handy and can only serve to
> > > benefit the project.
> > >
> > > -T
> > >
> > > On Mon, Aug 1, 2011 at 10:39 AM, Prescott Nasser <
> geobmx...@hotmail.com>
> > > wrote:
> > > >
> > > >
> > > >
> > > >>
> > > >> 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
> > >
>
>

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

[Michael Herndon]

StyleCop by default adheres strictly to ms coding guidelines and then some.
 http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx (even though a
deal of the internals of the framework breaks these rules).

You can turns rules off but if you want rules that differ from the default
ones, rules would need to be created. Though a few of the rules do
look customizable.   I can install style cop into the project those into the
project and turn off rules, anything further will be left up to
the community. Though I'd suggest turning rules down a notch for the testing
projects.

I can make scripts to run fxcop, but it will be left up to each individual
to install it. FxCop 10.0 only now comes with the win 7.1 sdk for .net 4 and
it does not seem to be redistributable.  And judging by the size of it
now Its probably best that isn't put into source anyways.

On Mon, Aug 1, 2011 at 1:47 PM, Troy Howard  wrote:

> Agreed. StyleCop and FxCop are both quite handy and can only serve to
> benefit the project.
>
> -T
>
> On Mon, Aug 1, 2011 at 10:39 AM, Prescott Nasser 
> wrote:
> >
> >
> >
> >>
> >> 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] style cop, fx cop rules

[Michael Herndon]

Does anyone have any preferred rules that they want ignored or want required
for the project for either Fx Cop or Style Cop?

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.

[Lucene.Net] [jira] [Closed] (LUCENENET-418) LuceneTestCase should not have a static method could throw exceptions.

[michael herndon (JIRA)]

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

michael herndon closed LUCENENET-418.
-


this issue should now be closed

> LuceneTestCase should not have a static method could throw exceptions.  
> 
>
> Key: LUCENENET-418
> URL: https://issues.apache.org/jira/browse/LUCENENET-418
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Test
>Affects Versions: Lucene.Net 3.x
> Environment: Linux, OSX, etc 
>Reporter: michael herndon
>    Assignee: michael herndon
>  Labels: test
> Fix For: Lucene.Net 2.9.4g
>
>   Original Estimate: 2m
>  Remaining Estimate: 2m
>
> Throwing an exception in a base classes for 90% tests in a static method 
> makes it hard to debug the issue in nunit.
> The test results came back saying that TestFixtureSetup was causing an issue 
> even though it was the Static Constructor causing problems and this then 
> propagates to all the tests that stem from LuceneTestCase. 
> The TEMP_DIR needs to be moved to a static util class as a property or even a 
> mixin method.  This caused me hours to debug and figure out the real issue as 
> the underlying exception method never bubbled up.  

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

[Lucene.Net] [jira] [Resolved] (LUCENENET-418) LuceneTestCase should not have a static method could throw exceptions.

[michael herndon (JIRA)]

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

michael herndon resolved LUCENENET-418.
---

Resolution: Fixed

> LuceneTestCase should not have a static method could throw exceptions.  
> 
>
> Key: LUCENENET-418
> URL: https://issues.apache.org/jira/browse/LUCENENET-418
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Test
>Affects Versions: Lucene.Net 3.x
> Environment: Linux, OSX, etc 
>Reporter: michael herndon
>    Assignee: michael herndon
>  Labels: test
> Fix For: Lucene.Net 2.9.4g
>
>   Original Estimate: 2m
>  Remaining Estimate: 2m
>
> Throwing an exception in a base classes for 90% tests in a static method 
> makes it hard to debug the issue in nunit.
> The test results came back saying that TestFixtureSetup was causing an issue 
> even though it was the Static Constructor causing problems and this then 
> propagates to all the tests that stem from LuceneTestCase. 
> The TEMP_DIR needs to be moved to a static util class as a property or even a 
> mixin method.  This caused me hours to debug and figure out the real issue as 
> the underlying exception method never bubbled up.  

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

[Lucene.Net] Code Documentation Help Guide.

[Michael Herndon]

Code Documentation Guide
https://cwiki.apache.org/confluence/display/LUCENENET/Documenting+Lucene.Net


I could not find a decent link or guide on translating JavaDoc notation to
their XML Doc Comment counter parts.  Which is why I threw the guide
together with a table that shows JavaDoc and XML Doc Comment equivalents.

Inside the Lucene.Net code base, there are still a number of JavaDoc
notations being used.  There are also XML Doc Comment tags being used
incorrectly or do not exist altogether.  This will cause issues when we
start to generate documentation for the code base using Sandcastle in the
future.

Please edit, comment, correct, extend and use the guide in the wiki.

https://issues.apache.org/jira/browse/LUCENENET-438

- Michael

[Lucene.Net] [jira] [Updated] (LUCENENET-438) replace java doc notation with ms style xml comments notation.

[michael herndon (JIRA)]

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

michael herndon updated LUCENENET-438:
--

Description: 
The are a ton of java doc style notations inside the xml code comments, i.e. 
{@link #IncrementToken} 

These need to use the ms xml code comment style if there is an existing 
equivalent.  I'm not assigning this one. If you come across this on code you 
are working on, please take an extra few minutes to fix up the comments. 

If you need help, grab me on #lucene.net on irc or michaelherndon on skype. 
Just let me know who you are and what help you need. 

A guide for code documentation, it includes a table that shows JavaDoc and XML 
doc comment equivalents:
https://cwiki.apache.org/confluence/display/LUCENENET/Documenting+Lucene.Net  

  was:
The are a ton of java doc style notations inside the xml code comments, i.e. 
{@link #IncrementToken} 

These need to use the ms xml code comment style if there is an existing 
equivalent.  I'm not assigning this one. If you come across this on code you 
are working on, please take an extra few minutes to fix up the comments. 

If you need help, grab me on #lucene.net on irc or michaelherndon on skype. 
Just let me know who you are and what help you need.  


> replace java doc notation with ms style xml comments notation.  
> 
>
> Key: LUCENENET-438
> URL: https://issues.apache.org/jira/browse/LUCENENET-438
> Project: Lucene.Net
>  Issue Type: Improvement
>  Components: Lucene.Net Contrib, Lucene.Net Core
>Affects Versions: Lucene.Net 2.9.4g
> Environment: all
>Reporter: michael herndon
>  Labels: documentation,
>
> The are a ton of java doc style notations inside the xml code comments, i.e. 
> {@link #IncrementToken} 
> These need to use the ms xml code comment style if there is an existing 
> equivalent.  I'm not assigning this one. If you come across this on code you 
> are working on, please take an extra few minutes to fix up the comments. 
> If you need help, grab me on #lucene.net on irc or michaelherndon on skype. 
> Just let me know who you are and what help you need. 
> A guide for code documentation, it includes a table that shows JavaDoc and 
> XML doc comment equivalents:
> https://cwiki.apache.org/confluence/display/LUCENENET/Documenting+Lucene.Net  

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

[Lucene.Net] [jira] [Created] (LUCENENET-439) Correctly Rethrow exceptions in C#

[michael herndon (JIRA)]

Correctly Rethrow exceptions in C#
--

 Key: LUCENENET-439
 URL: https://issues.apache.org/jira/browse/LUCENENET-439
 Project: Lucene.Net
  Issue Type: Sub-task
  Components: Lucene.Net Core, Lucene.Net Test
Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g
 Environment: all
Reporter: michael herndon


There are a few places in the tests and possibly in the code where exceptions 
are being rethrown incorrectly and erasing stacktrace.  

Please fix these as you come across them and add the ticket number in the 
commit message. 

BaseTokenStreamTestCase.cs has a good example of this. Inside the RunBare 
method:

// Do the test again with onlyUseNewAPI=true
try
{
onlyUseNewAPI = true;
base.RunBare();
}
catch(Exception ex) 
{
System.Console.Out.WriteLine("Test failure of '" + GetType() + "' 
occurred with onlyUseNewAPI=true");
throw ex;
}

in this case you don't need to specify the exception, and we're trapping to 
write out the context of the exception problem. 

try
{
onlyUseNewAPI = true;
base.RunBare();
}
catch 
{
Type type = this.GetType();
Console.WriteLine("Test failure of '" + type.Name + "' occurred with 
onlyUseNewAPI=true");
throw;
}

http://msdn.microsoft.com/en-us/library/ms182363(v=vs.80).aspx
http://winterdom.com/2002/09/rethrowingexceptionsinc 

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

[Lucene.Net] [jira] [Updated] (LUCENENET-435) Fix the test suite for Lucene.Net Core

[michael herndon (JIRA)]

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

michael herndon updated LUCENENET-435:
--

Description: 
If wish to work on one of these, create a new sub-task from this one, assign it 
to yourself and submit the patch or commit it. make sure that if you create any 
new files to include the apache 2.0 license.   

 * There needs to be a running list of things to do/not to do with testing. I 
don't know if this goes in a jira or do we keep a running list on the wiki or 
site for people to pick up and  help with.  
 * Tests need to run on mono and not Fail (there is a good deal of failing 
tests on mono, mostly due to the temp directory have the C:\ in the path).  
 * Assert.Throw() needs to be used instead of Try/Catch 
Assert.Fail.  **
 * File & Path combines to the temp directory need helper methods, 
 * e,g, having this in a hundred places is bad   new 
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir", 
""), "testIndex"));
 * We should still be testing deprecated methods, but we need to use #pragma 
warning disable/enable 0618  for testing those. otherwise compiler warnings are 
too numerous to be anywhere near helpful.
 * We should only be using deprecated methods in places where they are being 
explicitly tested, other tests that need that functionality in order to 
validate those tests should be re factored to use methods that are not 
deprecated.
 * Identify code that could be abstracted into test utility classes.   
 * Infrastructure Validation tests need to be made, anything that seems like 
infrastructure.  e.g. does the temp directory exist, does the folders that the 
tests use inside the temp directory exist, can we read/write to those folders. 
(if a ton of tests fail due to the file system, we should be able to point out 
that it was due to permissions or missing folders, files, etc). 
 * Identify what classes need an interface, abstract class or inherited in 
order to create testing mocks. (once those classes are created, they should be 
documented in the wiki). 
 * fix rethrows inside try/catches that log information then rethrows the 
exception.  i.e. use throw; instead of throw ex; 


Note Asset.Throws needs to replace stuff like the following. We should also be 
checking the messages for exceptions and make sure they make sense and can help 
users fix isses if the exceptions are aimed at the library users.
try
{
d = DateTools.StringToDate("97"); // no date
Assert.Fail();
}
catch (System.FormatException e)
{
/* expected exception */

  was:
If wish to work on one of these, create a new sub-task from this one, assign it 
to yourself and submit the patch or commit it. make sure that if you create any 
new files to include the apache 2.0 license.   

 * There needs to be a running list of things to do/not to do with testing. I 
don't know if this goes in a jira or do we keep a running list on the wiki or 
site for people to pick up and  help with.  
 * Tests need to run on mono and not Fail (there is a good deal of failing 
tests on mono, mostly due to the temp directory have the C:\ in the path).  
 * Assert.Throw() needs to be used instead of Try/Catch 
Assert.Fail.  **
 * File & Path combines to the temp directory need helper methods, 
 * e,g, having this in a hundred places is bad   new 
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir", 
""), "testIndex"));
 * We should still be testing deprecated methods, but we need to use #pragma 
warning disable/enable 0618  for testing those. otherwise compiler warnings are 
too numerous to be anywhere near helpful.
 * We should only be using deprecated methods in places where they are being 
explicitly tested, other tests that need that functionality in order to 
validate those tests should be re factored to use methods that are not 
deprecated.
 * Identify code that could be abstracted into test utility classes.   
 * Infrastructure Validation tests need to be made, anything that seems like 
infrastructure.  e.g. does the temp directory exist, does the folders that the 
tests use inside the temp directory exist, can we read/write to those folders. 
(if a ton of tests fail due to the file system, we should be able to point out 
that it was due to permissions or missing folders, files, etc). 
 * Identify what classes need an interface, abstract class or inherited in 
order to create testing mocks. (once those classes are created, they should be 
documented in the wiki). 
 


Note Asset.Throws needs to replace stuff like the following. We should also be 
checking the messages for exceptions an

[Lucene.Net] [jira] [Created] (LUCENENET-436) Refactor Deprecated Code inside of tests

[michael herndon (JIRA)]

Refactor Deprecated Code inside of tests 
-

 Key: LUCENENET-436
 URL: https://issues.apache.org/jira/browse/LUCENENET-436
 Project: Lucene.Net
  Issue Type: Sub-task
  Components: Lucene.Net Test
Affects Versions: Lucene.Net 2.9.4g
Reporter: michael herndon


* We should still be testing deprecated methods, but we need to use #pragma 
warning disable/enable 0618 for testing those. otherwise compiler warnings are 
too numerous to be anywhere near helpful.
* We should only be using deprecated methods in places where they are being 
explicitly tested, other tests that need that functionality in 
order to validate those tests should be re factored to use methods that are not 
deprecated.

This is one place we should probably deviate from the parent project and make 
sure that any deprecated code gets isolated to the tests designed only for the 
deprecated methods and then use the newer API through out the testsuite.

This should help move the project forward and remove deprecated API's when the 
time comes.   

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

[Lucene.Net] [jira] [Updated] (LUCENENET-435) Fix the test suite for Lucene.Net Core

[michael herndon (JIRA)]

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

michael herndon updated LUCENENET-435:
--

Description: 
If wish to work on one of these, create a new sub-task from this one, assign it 
to yourself and submit the patch or commit it. make sure that if you create any 
new files to include the apache 2.0 license.   

 * There needs to be a running list of things to do/not to do with testing. I 
don't know if this goes in a jira or do we keep a running list on the wiki or 
site for people to pick up and  help with.  
 * Tests need to run on mono and not Fail (there is a good deal of failing 
tests on mono, mostly due to the temp directory have the C:\ in the path).  
 * Assert.Throw() needs to be used instead of Try/Catch 
Assert.Fail.  **
 * File & Path combines to the temp directory need helper methods, 
 * e,g, having this in a hundred places is bad   new 
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir", 
""), "testIndex"));
 * We should still be testing deprecated methods, but we need to use #pragma 
warning disable/enable 0618  for testing those. otherwise compiler warnings are 
too numerous to be anywhere near helpful.
 * We should only be using deprecated methods in places where they are being 
explicitly tested, other tests that need that functionality in order to 
validate those tests should be re factored to use methods that are not 
deprecated.
 * Identify code that could be abstracted into test utility classes.   
 * Infrastructure Validation tests need to be made, anything that seems like 
infrastructure.  e.g. does the temp directory exist, does the folders that the 
tests use inside the temp directory exist, can we read/write to those folders. 
(if a ton of tests fail due to the file system, we should be able to point out 
that it was due to permissions or missing folders, files, etc). 
 * Identify what classes need an interface, abstract class or inherited in 
order to create testing mocks. (once those classes are created, they should be 
documented in the wiki). 
 


Note Asset.Throws needs to replace stuff like the following. We should also be 
checking the messages for exceptions and make sure they make sense and can help 
users fix isses if the exceptions are aimed at the library users.
try
{
d = DateTools.StringToDate("97"); // no date
Assert.Fail();
}
catch (System.FormatException e)
{
/* expected exception */

  was:
 * There needs to be a running list of things to do/not to do with testing. I 
don't know if this goes in a jira or do we keep a running list on the wiki or 
site for people to pick up and  help with.  
 * Tests need to run on mono and not Fail (there is a good deal of failing 
tests on mono, mostly due to the temp directory have the C:\ in the path).  
 * Assert.Throw() needs to be used instead of Try/Catch 
Assert.Fail.  **
 * File & Path combines to the temp directory need helper methods, 
 * e,g, having this in a hundred places is bad   new 
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir", 
""), "testIndex"));
 * We should still be testing deprecated methods, but we need to use #pragma 
warning disable/enable 0618  for testing those. otherwise compiler warnings are 
too numerous to be anywhere near helpful.
 * We should only be using deprecated methods in places where they are being 
explicitly tested, other tests that need that functionality in order to 
validate those tests should be re factored to use methods that are not 
deprecated.
 * Identify code that could be abstracted into test utility classes.   
 * Infrastructure Validation tests need to be made, anything that seems like 
infrastructure.  e.g. does the temp directory exist, does the folders that the 
tests use inside the temp directory exist, can we read/write to those folders. 
(if a ton of tests fail due to the file system, we should be able to point out 
that it was due to permissions or missing folders, files, etc). 
 * Identify what classes need an interface, abstract class or inherited in 
order to create testing mocks. (once those classes are created, they should be 
documented in the wiki). 
 


** Asset.Throws needs to replace stuff like the following. We should also be 
checking the messages for exceptions and make sure they make sense and can help 
users fix isses if the exceptions are aimed at the library users.
try
{
d = DateTools.StringToDate("97"); // no date
Assert.Fail();
}
catch (System.

[Lucene.Net] [jira] [Created] (LUCENENET-435) Fix the test suite for Lucene.Net Core

[michael herndon (JIRA)]

Fix the test suite for Lucene.Net Core
--

 Key: LUCENENET-435
 URL: https://issues.apache.org/jira/browse/LUCENENET-435
 Project: Lucene.Net
  Issue Type: Task
  Components: Lucene.Net Test
Affects Versions: Lucene.Net 2.9.4g
 Environment: all
Reporter: michael herndon
Assignee: michael herndon


 * There needs to be a running list of things to do/not to do with testing. I 
don't know if this goes in a jira or do we keep a running list on the wiki or 
site for people to pick up and  help with.  
 * Tests need to run on mono and not Fail (there is a good deal of failing 
tests on mono, mostly due to the temp directory have the C:\ in the path).  
 * Assert.Throw() needs to be used instead of Try/Catch 
Assert.Fail.  **
 * File & Path combines to the temp directory need helper methods, 
 * e,g, having this in a hundred places is bad   new 
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir", 
""), "testIndex"));
 * We should still be testing deprecated methods, but we need to use #pragma 
warning disable/enable 0618  for testing those. otherwise compiler warnings are 
too numerous to be anywhere near helpful.
 * We should only be using deprecated methods in places where they are being 
explicitly tested, other tests that need that functionality in order to 
validate those tests should be re factored to use methods that are not 
deprecated.
 * Identify code that could be abstracted into test utility classes.   
 * Infrastructure Validation tests need to be made, anything that seems like 
infrastructure.  e.g. does the temp directory exist, does the folders that the 
tests use inside the temp directory exist, can we read/write to those folders. 
(if a ton of tests fail due to the file system, we should be able to point out 
that it was due to permissions or missing folders, files, etc). 
 * Identify what classes need an interface, abstract class or inherited in 
order to create testing mocks. (once those classes are created, they should be 
documented in the wiki). 
 


** Asset.Throws needs to replace stuff like the following. We should also be 
checking the messages for exceptions and make sure they make sense and can help 
users fix isses if the exceptions are aimed at the library users.
try
{
d = DateTools.StringToDate("97"); // no date
Assert.Fail();
}
catch (System.FormatException e)
{
/* expected exception */

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

[Lucene.Net] [jira] [Commented] (LUCENENET-418) LuceneTestCase should not have a static method could throw exceptions.

[michael herndon (JIRA)]

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

michael herndon commented on LUCENENET-418:
---

I'll take a look.  Which build are you using, release or debug?  

> LuceneTestCase should not have a static method could throw exceptions.  
> 
>
> Key: LUCENENET-418
> URL: https://issues.apache.org/jira/browse/LUCENENET-418
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Test
>Affects Versions: Lucene.Net 3.x
> Environment: Linux, OSX, etc 
>Reporter: michael herndon
>Assignee: michael herndon
>  Labels: test
> Fix For: Lucene.Net 2.9.4g
>
>   Original Estimate: 2m
>  Remaining Estimate: 2m
>
> Throwing an exception in a base classes for 90% tests in a static method 
> makes it hard to debug the issue in nunit.
> The test results came back saying that TestFixtureSetup was causing an issue 
> even though it was the Static Constructor causing problems and this then 
> propagates to all the tests that stem from LuceneTestCase. 
> The TEMP_DIR needs to be moved to a static util class as a property or even a 
> mixin method.  This caused me hours to debug and figure out the real issue as 
> the underlying exception method never bubbled up.  

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

Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

[Michael Herndon]

@Rory,

Jira in the past had the ability to create sub tasks or convert a current
task to a sub task. I'm guessing that apache's jira should be able to do
that.

@All,

I've add a Paths Class under the Lucene.Net.Tests Util folder (feel free to
rename, refactor as long as the tests still work) to help with working with
paths in general.  This should help with forming paths relative to the temp
directory or the project root.

NUnit's Shadow Copy tends to throw people off when trying to get the path of
the current assembly being tested to build up a relative path, the Path
class should help with that.

- Michael

On Fri, Jul 1, 2011 at 4:09 PM, Rory Plaire  wrote:

> My thinking is just a separate ticket for each one. This makes the work
> easier to manage and gives a better sense about how much work is left as
> well as makes it easier to prioritize independent issues. We could link all
> the sub-issues to a single task / feature / whatever (that is, if JIRA has
> that capability).
>
> -r
> On Fri, Jul 1, 2011 at 12:48 PM, Michael Herndon <
> mhern...@wickedsoftware.net> wrote:
>
> > I think whatever makes sense to do.
> >
> > possibly create one jira for now with a running list that can be modified
> > and possibly as people pull from that list, cross things off or create a
> > separate ticket that links back to to the main one.
> >
> >
> >
> >
> > On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire 
> wrote:
> >
> > > @Michael -
> > >
> > > Should that list be in JIRA? It would be easier to manage, I think...
> > >
> > > If yes, I'll happily do it.
> > >
> > > -r
> > >
> > > On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon <
> > > mhern...@wickedsoftware.net
> > > > wrote:
> > >
> > > > * need to document what the build script does.  whut grammerz?
> > > >
> > > > On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon <
> > > > mhern...@wickedsoftware.net> wrote:
> > > >
> > > > > @Rory, @All,
> > > > >
> > > > > The only tickets I currently have for those is LUCENE-419,
> LUCENE-418
> > > > >
> > > > > 418, I should be able to push into the 2.9.4g branch tonight.
>  419
> > is
> > > a
> > > > > long term goal and not as important as getting the tests fixed, of
> > have
> > > > the
> > > > > tests broken down into what is actually a unit test, functional
> test,
> > > > perf
> > > > > or long running test. I can get into more why it needs to be done.
> > > > >
> > > > > I'll also need to make document the what build script currently
> does
> > on
> > > > the
> > > > > wiki & and make a few notes about testing, like using the
> > RAMDirectory,
> > > > > etc.
> > > > >
> > > > > Things that need to get done or even be discussed.
> > > > >  * There needs to be a running list of things to do/not to do with
> > > > testing.
> > > > > I don't know if this goes in a jira or do we keep a running list on
> > the
> > > > wiki
> > > > > or site for people to pick up and  help with.
> > > > >  * Tests need to run on mono and not Fail (there is a good deal of
> > > > failing
> > > > > tests on mono, mostly due to the temp directory have the C:\ in the
> > > > path).
> > > > >  * Assert.Throw() needs to be used instead of
> > Try/Catch
> > > > > Assert.Fail.  **
> > > > >  * File & Path combines to the temp directory need helper methods,
> > > > >  * e,g, having this in a hundred places is bad   new
> > > > >
> > > >
> > >
> >
> System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
> > > > > ""), "testIndex"));
> > > > >  * We should still be testing deprecated methods, but we need to
> use
> > > > #pragma
> > > > > warning disable/enable 0618  for testing those. otherwise compiler
> > > > warnings
> > > > > are too numerous to be anywhere near helpful.
> > > > >  * We should only be using deprecated methods in places where they
> > are
> > > > > being explicitly tested, other tests that need that functionality
> in
> > > > order
> > > > > to validate those tests should be re fact

[Lucene.Net] [jira] [Resolved] (LUCENENET-418) LuceneTestCase should not have a static method could throw exceptions.

[michael herndon (JIRA)]

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

michael herndon resolved LUCENENET-418.
---

   Resolution: Fixed
Fix Version/s: Lucene.Net 2.9.4g

this issue should now be resolved. 

> LuceneTestCase should not have a static method could throw exceptions.  
> 
>
> Key: LUCENENET-418
> URL: https://issues.apache.org/jira/browse/LUCENENET-418
> Project: Lucene.Net
>  Issue Type: Bug
>  Components: Lucene.Net Test
>Affects Versions: Lucene.Net 3.x
> Environment: Linux, OSX, etc 
>Reporter: michael herndon
>    Assignee: michael herndon
>  Labels: test
> Fix For: Lucene.Net 2.9.4g
>
>   Original Estimate: 2m
>  Remaining Estimate: 2m
>
> Throwing an exception in a base classes for 90% tests in a static method 
> makes it hard to debug the issue in nunit.
> The test results came back saying that TestFixtureSetup was causing an issue 
> even though it was the Static Constructor causing problems and this then 
> propagates to all the tests that stem from LuceneTestCase. 
> The TEMP_DIR needs to be moved to a static util class as a property or even a 
> mixin method.  This caused me hours to debug and figure out the real issue as 
> the underlying exception method never bubbled up.  

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