[Lucene.Net] [jira] [Commented] (LUCENENET-455) Build Targets
[ https://issues.apache.org/jira/browse/LUCENENET-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13153627#comment-13153627 ] Prescott Nasser commented on LUCENENET-455: --- Oh, I see, I have to run the build scripts - I was just building with the release profile, and it wasn't making it to /bin. That would probably make cutting a release much easier.. Thanks for the update Build Targets - Key: LUCENENET-455 URL: https://issues.apache.org/jira/browse/LUCENENET-455 Project: Lucene.Net Issue Type: Improvement Reporter: Prescott Nasser Priority: Trivial -Modify build directories of lucene and lucene.contrib to point to root/bin, now it points to root/build/bin -Modify the release build of Demo to create a Release folder in bin - right now it doesn't create a subfolder -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[Lucene.Net] [jira] [Resolved] (LUCENENET-455) Build Targets
[ https://issues.apache.org/jira/browse/LUCENENET-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prescott Nasser resolved LUCENENET-455. --- Resolution: Fixed Fix Version/s: Lucene.Net 2.9.4 Assignee: Prescott Nasser Build Targets - Key: LUCENENET-455 URL: https://issues.apache.org/jira/browse/LUCENENET-455 Project: Lucene.Net Issue Type: Improvement Reporter: Prescott Nasser Assignee: Prescott Nasser Priority: Trivial Fix For: Lucene.Net 2.9.4 -Modify build directories of lucene and lucene.contrib to point to root/bin, now it points to root/build/bin -Modify the release build of Demo to create a Release folder in bin - right now it doesn't create a subfolder -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3
Some of the contrib stuff will be easier to port than others. Some of it relies on features the java character class has that .Net does not have. If my memory serves me correctly, it has to do with the character map, essentially java can tell you whig category it lives in, or Arabic, Chinese, etc. .Net only gives you is letter, is digit, etc. There are a few other difficulties in the hyphenation package, as well. It won't be totally painless. I'm okay with not including it in the release and porting them later, either for the next release, or if people request it. I don't see any reason we couldnt do it as a separate release, if community demand was high enough. So, I'm a +1. For a release as is. +1 Sent from my phonograph, so there are likely some mistaken. ;) On Nov 19, 2011 3:55 PM, Prescott Nasser geobmx...@hotmail.com wrote: I'm alright with them being out of partity if only because it seems like a lot of effort is moving away from 2.9.4. The core is all there If everyone else thinks otherwise, I'll start to update those, but otherwise, I'd like to close the chapter on 2.9.4 and put some effort into one of the other items people are working on. My hope is that 2.9.4 is quickly replaced with the next version - we have spent a lot of time sitting on this at this point ~P From: thowar...@gmail.com Date: Fri, 18 Nov 2011 18:17:20 -0800 To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3 So, I haven't looked at the artifacts, but I was just looking over the source code, and noticed something that we should probably discuss before voting on the artifacts. The files in Contrib\Analyzers are nowhere near in sync with 2.9.4... Not sure how old they are exactly, but they are very different from Java's 2.9.4 Contrib\Analyzers. This looks like a relatively small amount of work to update. Do we want to make a release without updating those to be 2.9.4 compatible? Are there any other things like this lurking in Contrib that haven't been updated? Thanks, Troy On Fri, Nov 18, 2011 at 1:33 AM, Prescott Nasser geobmx...@hotmail.com wrote: Third time is the charm: http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/ I'll keep it open for 72 hours or so, then if all goes well, I'll make a vote to the general@incubator Thanks everyone for their help getting to this point. ~Prescott +1
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 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
RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
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.ch...@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 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
Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3
On 2011-11-18, Prescott Nasser wrote: Third time is the charm: I'm afraid it is not. http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/ Sigs and hashes are good. Source zip and tag match except for the build/lib/doc dirs that are only inside the tag and which I agree is a good thing for now. LICENSE, NOTICE, DISCLAIMER look good in src. There is no NOTICE and no DISCLAIMER in the binary zip. Has it been this way before? If so I'm sorry I didn't catch it. This is a blocker for me and probably would be for the other IPMC members as well. RAT is reasonably happy with the source tree. I can't give a +1 because of the missing files in the binary zip. If you just recreated the binary with the two files added (and obviously resigned it and recalculated the hashes) I'd be happy to change that. Cheers Stefan
Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3
+1 for wiki checklist ticket for for build scripts to bundle all this stuff for you. On Sun, Nov 20, 2011 at 1:51 AM, Prescott Nasser geobmx...@hotmail.comwrote: Damn It - knew i was missing something Sent from my Windows Phone From: Stefan Bodewig Sent: 11/19/2011 10:34 PM To: lucene-net-...@incubator.apache.org Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3 On 2011-11-18, Prescott Nasser wrote: Third time is the charm: I'm afraid it is not. http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/ Sigs and hashes are good. Source zip and tag match except for the build/lib/doc dirs that are only inside the tag and which I agree is a good thing for now. LICENSE, NOTICE, DISCLAIMER look good in src. There is no NOTICE and no DISCLAIMER in the binary zip. Has it been this way before? If so I'm sorry I didn't catch it. This is a blocker for me and probably would be for the other IPMC members as well. RAT is reasonably happy with the source tree. I can't give a +1 because of the missing files in the binary zip. If you just recreated the binary with the two files added (and obviously resigned it and recalculated the hashes) I'd be happy to change that. Cheers Stefan
