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: mhern...@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 <thowar...@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 <geobmx...@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 > >
