You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Prescott Nasser <ge...@hotmail.com> on 2011/10/31 06:08:32 UTC

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

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


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

 

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

[ ] +1
[ ]  0
[ ] -1

 

 

~Prescott 		 	   		  

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

Posted by Prescott Nasser <ge...@hotmail.com>.
bleh - forgot to update the branch.

 

And yay for windows hiding those svn files.. 

 

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

 

Thanks for taking the time to review

 

~P

----------------------------------------
> From: bodewig@apache.org
> To: lucene-net-dev@incubator.apache.org
> Date: Mon, 31 Oct 2011 07:00:08 +0100
> Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
>
> On 2011-10-31, Prescott Nasser wrote:
>
> > Artifacts are located here:
> > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
>
> Is there a tag in svn that is supposed to correspond to them? My guess
> is <http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/>.
> But then I find
>
> diff -ur svn/src/contrib/Similarity/Similar/MoreLikeThis.cs Apache-Lucene.Net-2.
> 9.4-incubating-RC1.src/src/contrib/Similarity/Similar/MoreLikeThis.cs
> --- svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 2011-04-23 01:53:05.3476
> 64000 +0200
> +++ Apache-Lucene.Net-2.9.4-incubating-RC1.src/src/contrib/Similarity/Similar/Mo
> reLikeThis.cs 2011-10-30 19:35:42.000000000 +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 @@
> /// </param>
> /// <param name="fieldName">Used by analyzer for any special per-field
> analysis
> /// </param>
> - 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 		 	   		  

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

Posted by Michael Herndon <mh...@wickedsoftware.net>.
If no one else beats me to it, I can probably have it in trunk by wednesday.

- Michael

On Mon, Oct 31, 2011 at 5:34 AM, Stefan Bodewig <bo...@apache.org> wrote:

> On 2011-10-31, Prescott Nasser wrote:
>
> > I have to re tag the trunk because of the additional bug fix I put in
> > this evening. So feel free to update the trunk
>
> LUCENENET-451
>
> Technically I could commit it myself but it may be better if anybody
> from "the real team" did.
>
> Stefan
>

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

Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-10-31, Prescott Nasser wrote:

> I have to re tag the trunk because of the additional bug fix I put in
> this evening. So feel free to update the trunk

LUCENENET-451

Technically I could commit it myself but it may be better if anybody
from "the real team" did.

Stefan

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

Posted by Prescott Nasser <ge...@hotmail.com>.
I have to re tag the trunk because of the additional bug fix I put in this evening. So feel free to update the trunk, I'll re tag it 2.9.4 RC2 once that's ready

 

~Prescott

----------------------------------------
> From: bodewig@apache.org
> To: lucene-net-dev@incubator.apache.org
> Date: Mon, 31 Oct 2011 07:10:46 +0100
> Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
>
> On 2011-10-31, Stefan Bodewig wrote:
>
> > The only other test I'd perform was running RAT which I'll do shortly
> > and post the results here.
>
> The binary look good, but
>
> <http://people.apache.org/~bodewig/lucene.net/src.rat.txt>
>
> Way too many files without license headers. I can and will provide a
> patch to trunk fixing issues there (my svn trunk version of RAT is
> better suited to do that than the latest release) but I recall this RC
> was created from a branch so it may be of more help if I created the
> patch for that one.
>
> Stefan 		 	   		  

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

Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-10-31, Stefan Bodewig wrote:

> The only other test I'd perform was running RAT which I'll do shortly
> and post the results here.

The binary look good, but

<http://people.apache.org/~bodewig/lucene.net/src.rat.txt>

Way too many files without license headers.  I can and will provide a
patch to trunk fixing issues there (my svn trunk version of RAT is
better suited to do that than the latest release) but I recall this RC
was created from a branch so it may be of more help if I created the
patch for that one.

Stefan

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

Posted by Michael Herndon <mh...@wickedsoftware.net>.
@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 <ge...@hotmail.com>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: bodewig@apache.org
> > To: lucene-net-dev@incubator.apache.org
> > Date: Mon, 31 Oct 2011 07:00:08 +0100
> > Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
> >
> > On 2011-10-31, Prescott Nasser wrote:
> >
> > > Artifacts are located here:
> > > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
> >
> > Is there a tag in svn that is supposed to correspond to them? My guess
> > is <http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/>.
> > But then I find
> >
> > diff -ur svn/src/contrib/Similarity/Similar/MoreLikeThis.cs
> Apache-Lucene.Net-2.
> > 9.4-incubating-RC1.src/src/contrib/Similarity/Similar/MoreLikeThis.cs
> > --- svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 2011-04-23
> 01:53:05.3476
> > 64000 +0200
> > +++
> Apache-Lucene.Net-2.9.4-incubating-RC1.src/src/contrib/Similarity/Similar/Mo
> > reLikeThis.cs 2011-10-30 19:35:42.000000000 +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 @@
> > /// </param>
> > /// <param name="fieldName">Used by analyzer for any special per-field
> > analysis
> > /// </param>
> > - 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
>

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

Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-10-31, Prescott Nasser wrote:

> Stefan - doc folder was left out intentionally for this reason.

OK.  I wonder whether it should be moved out of trunk.

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

Please don't.  We'd need to review whether we can re-distribute all
those DLLs complying with ASF policies anyway.

Stefan

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

Posted by Prescott Nasser <ge...@hotmail.com>.




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: bodewig@apache.org
> To: lucene-net-dev@incubator.apache.org
> Date: Mon, 31 Oct 2011 07:00:08 +0100
> Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
>
> On 2011-10-31, Prescott Nasser wrote:
>
> > Artifacts are located here:
> > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
>
> Is there a tag in svn that is supposed to correspond to them? My guess
> is <http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/>.
> But then I find
>
> diff -ur svn/src/contrib/Similarity/Similar/MoreLikeThis.cs Apache-Lucene.Net-2.
> 9.4-incubating-RC1.src/src/contrib/Similarity/Similar/MoreLikeThis.cs
> --- svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 2011-04-23 01:53:05.3476
> 64000 +0200
> +++ Apache-Lucene.Net-2.9.4-incubating-RC1.src/src/contrib/Similarity/Similar/Mo
> reLikeThis.cs 2011-10-30 19:35:42.000000000 +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 @@
> /// </param>
> /// <param name="fieldName">Used by analyzer for any special per-field
> analysis
> /// </param>
> - 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 		 	   		  

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

Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-10-31, Prescott Nasser wrote:

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

Is there a tag in svn that is supposed to correspond to them?  My guess
is <http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/>.
But then I find

diff -ur svn/src/contrib/Similarity/Similar/MoreLikeThis.cs Apache-Lucene.Net-2.
9.4-incubating-RC1.src/src/contrib/Similarity/Similar/MoreLikeThis.cs
--- svn/src/contrib/Similarity/Similar/MoreLikeThis.cs  2011-04-23 01:53:05.3476
64000 +0200
+++ Apache-Lucene.Net-2.9.4-incubating-RC1.src/src/contrib/Similarity/Similar/Mo
reLikeThis.cs   2011-10-30 19:35:42.000000000 +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 @@
         /// </param>
         /// <param name="fieldName">Used by analyzer for any special per-field 
analysis
         /// </param>
-        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

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

Posted by Prescott Nasser <ge...@hotmail.com>.
+1


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

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

Posted by Prescott Nasser <ge...@hotmail.com>.
I got lastest - so hopefully not :)

 

I think I'd cry a little bit if it got wiped.

----------------------------------------
> Date: Sat, 19 Nov 2011 17:55:05 -0800
> From: currens.chris@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
>
> I build it using trunk/build/scripts/build.cmd all all - in the scripts
> folder. Make sure you've updated the folder. That message is suspiciously
> close to the message that would appear when it had the bug that would wipe
> entire drives.
> On Nov 19, 2011 4:25 PM, "Prescott Nasser" <ge...@hotmail.com> wrote:
>
> >
> > Hey Michael, I'm running build and getting the following error:
> >
> >
> >
> >
> > build\scripts> ./build
> >
> > ...
> > The target 'all' does not exist in the project
> >
> > ...
> >
> >
> >
> >
> >
> > Should I be passing a command line argument to build all?
> >
> >
> >
> >
> >
> >
> > ----------------------------------------
> > > Date: Mon, 31 Oct 2011 16:39:30 -0400
> > > From: mherndon@wickedsoftware.net
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
> > >
> > > @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 <th...@gmail.com>
> > 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 10:08 PM, Prescott Nasser <
> > geobmx540@hotmail.com>
> > > > wrote:
> > > > >
> > > > > Artifacts are located here:
> > > > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
> > > > >
> > > > >
> > > > > If the vote passes here, I will move the artifacts to staging and
> > call a
> > > > vote on the general incubator mailing list
> > > > >
> > > > >
> > > > >
> > > > > Please verify the release and cast your vote. The vote will be open
> > for
> > > > 72 hours.
> > > > >
> > > > > [ ] +1
> > > > > [ ] 0
> > > > > [ ] -1
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ~Prescott
> > > > 		 	   		  

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

Posted by Christopher Currens <cu...@gmail.com>.
I build it using trunk/build/scripts/build.cmd all all - in the scripts
folder.  Make sure you've updated the folder.  That message is suspiciously
close to the message that would appear when it had the bug that would wipe
entire drives.
On Nov 19, 2011 4:25 PM, "Prescott Nasser" <ge...@hotmail.com> wrote:

>
> Hey Michael, I'm running build and getting the following error:
>
>
>
>
> build\scripts> ./build
>
> ...
> The target 'all' does not exist in the project
>
> ...
>
>
>
>
>
> Should I be passing a command line argument to build all?
>
>
>
>
>
>
> ----------------------------------------
> > Date: Mon, 31 Oct 2011 16:39:30 -0400
> > From: mherndon@wickedsoftware.net
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
> >
> > @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 <th...@gmail.com>
> 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 10:08 PM, Prescott Nasser <
> geobmx540@hotmail.com>
> > > wrote:
> > > >
> > > > Artifacts are located here:
> > > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
> > > >
> > > >
> > > > If the vote passes here, I will move the artifacts to staging and
> call a
> > > vote on the general incubator mailing list
> > > >
> > > >
> > > >
> > > > Please verify the release and cast your vote. The vote will be open
> for
> > > 72 hours.
> > > >
> > > > [ ] +1
> > > > [ ] 0
> > > > [ ] -1
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ~Prescott
> > >

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

Posted by Prescott Nasser <ge...@hotmail.com>.
Hey Michael, I'm running build and getting the following error:

 


build\scripts> ./build

... 
The target 'all' does not exist in the project

...

 

 

Should I be passing a command line argument to build all?

 




----------------------------------------
> Date: Mon, 31 Oct 2011 16:39:30 -0400
> From: mherndon@wickedsoftware.net
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
>
> @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 <th...@gmail.com> 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 10:08 PM, Prescott Nasser <ge...@hotmail.com>
> > wrote:
> > >
> > > Artifacts are located here:
> > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
> > >
> > >
> > > If the vote passes here, I will move the artifacts to staging and call a
> > vote on the general incubator mailing list
> > >
> > >
> > >
> > > Please verify the release and cast your vote. The vote will be open for
> > 72 hours.
> > >
> > > [ ] +1
> > > [ ] 0
> > > [ ] -1
> > >
> > >
> > >
> > >
> > >
> > > ~Prescott
> > 		 	   		  

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

Posted by Michael Herndon <mh...@wickedsoftware.net>.
@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 <th...@gmail.com> 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 10:08 PM, Prescott Nasser <ge...@hotmail.com>
> wrote:
> >
> > Artifacts are located here:
> http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
> >
> >
> > If the vote passes here, I will move the artifacts to staging and call a
> vote on the general incubator mailing list
> >
> >
> >
> > Please verify the release and cast your vote.  The vote will be open for
> 72 hours.
> >
> > [ ] +1
> > [ ]  0
> > [ ] -1
> >
> >
> >
> >
> >
> > ~Prescott
>

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

Posted by Troy Howard <th...@gmail.com>.
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 10:08 PM, Prescott Nasser <ge...@hotmail.com> wrote:
>
> Artifacts are located here: http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
>
>
> If the vote passes here, I will move the artifacts to staging and call a vote on the general incubator mailing list
>
>
>
> Please verify the release and cast your vote.  The vote will be open for 72 hours.
>
> [ ] +1
> [ ]  0
> [ ] -1
>
>
>
>
>
> ~Prescott