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 00:24:40 GMT

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