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