lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prescott Nasser <geobmx...@hotmail.com>
Subject RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
Date Sun, 20 Nov 2011 02:11:57 GMT

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" <geobmx540@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 <thoward37@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
> > > > 		 	   		  
Mime
View raw message