Re: Gump and Unicode
I once had the same problem with the JMeter sources, tried to add that encoding attribute to the java task, and it didn't help. It was helping on my platform, but not on Gump. I never learned why. If you attempt it here, I'll be interested to know if it works. Salut, Jordi. En/na Conor MacNeill ha escrit: On Thu, 12 Jun 2003 01:05 am, Brian Ewins wrote: Use the unicode escapes rather than the character literals in the code? You won't get DoubleMetaphone.java to compile unless you pass the encoding flag to javac. The two letters appear to be \u00C7, \u00D1 - capital C with a cedilla and capital N with a tilde? Putting case '\u00C7': case '\u00D1': in the appropriate places should fix things. Or add the encoding attribute to the javac task. The file may remain more readable that way, at least on some platforms. I'm not sure if that is possible from a Maven generated build file. Just to be clear this is not a Gump issue - I think the problem would appear whenever you try to compile on any platform with a different default encoding. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help needed on JMeter nightly builds
Hi Sam. You'll be happy to know that your effort responding your questions was not in vain. Gump runs are now building JMeter and producing meaningful results. Gump is now building the JMeter's distribution files into jakarta-jmeter/dist. Would it be possible to copy all files found in there to http://cvs.apache.org/builds/jakarta-jmeter/nightly/date after each build? In this way we'll be able to decide how exactly we want to pack up our distribution without having to bug you again. Just two more questions (hopefully last ones for a while): 1/ Would it be a good idea to run our unit tests during the nightly build? On one side, doing so would fit better into the continuous integration Gump concept. On the other side, looks like the build machines (or at least Nagoya) have a really tough time keeping up with the work, and our tests take a while... what's your opinion? 2/ JMeter binary distribution contains all the jars for all the projects it depends on. I think it needs to be that way: JMeter is an app for plain users, not a library for developers, and we want it to be installable and runnable with minimum hassle for the user. The way it currently works this would cause those binaries to run against library versions different from the ones used at compilation -- which doesn't look very nice. The question is: does Gump provide a way to copy some of those jars into the jakarta-jmeter/lib directory before the build? Pls. note that I said some, because there's a few we just can't distribute (licensing issues). Thanks, Jordi. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Help needed on JMeter nightly builds
Hi all. Hi Sam. So it was YOU who repaired the JMeter build on the 2nd Jan! I was about to go mad. Anyway, thanks. I think I get the picture now. Would you (or someone else) be so kind as reviewing this for severe misunderstandings? * Gump reads the project descriptors to establish a dependency tree, then builds each project in order. * Gump uses a modified ant which totally ignores all classpath settings -- instead it places all JARs exported by projects depended upon into the classpath. Q1: is it then best practice to remove all those jars from our lib/*.jar in CVS? * Thus the Gump nightly builds always happen against the CVS versions of all projects -- which means that if I build JMeter from the sources on my workstation I won't get the exact same results (since I will be building against released versions of those projects). * The copying of build results to http://cvs.apache.org/builds/jakarta-jmeter/nightly/ is not done by Gump. (Even though it must be run just after (some?) builds). Q: how can I have the JMeter distribution files published there? * The publishing of the src snapshot in that same directory has nothing to do with Gump. Salut, Jordi. Sam Ruby wrote: Jordi Salvat i Alabart wrote: Hi Sam. I'm taking this out of general to avoid bugging everyone around with my stupidness. Don't be afraid to post e-mails like these on jakarta-general. That way everybody can help, and everyone can learn from the answers. First of all, thanks again for your help, and my apologies if you just don't have time to help newcomers. I do get a lot of e-mails, so I may occasionally miss one. If that happens, try again. Or, ask on general. I have many questions about the nightly build snapshot process, how it names the results and where it places them. Every project in Jakarta seems to work in a slightly different way -- and JMeter most different of all. I also have questions on how the web site is generated and published (I'd like JMeter's to be generated from the xdocs instead of just pulled out from cvs/jakarta-jmeter/docs). There are some general policies, and then each subproject in Jakarta is free to tailor them to their own needs. The nightly build simply checks out jakarta-jmeter and builds the default target. It is driven from the following project definition: http://cvs.apache.org/viewcvs/jakarta-gump/project/jakarta-jmeter.xml I am willing to upload to the jakarta web site anything that build produces, simply ask. The way most jakarta projects work, as does jmeter, is that there is a docs target in the build that generates the docs directory from the xdocs sources. Simply build this and then commit the generated docs. Then somebody needs to go onto the daedalus.apache.org and execute a cvs update to get resynch the website with the cvs tree. For a number of projects, I have a script that automatically does this four times a day, so this eliminates a step... all you need to do is build and commit. Jmeter is not currently in this script... but can be added upon request. I've been checking the FAQ at http://www.apache.org/dev/committers.html#web, but it didn't help much. Either it's obsolete, or it doesn't apply to all jakarta projects. Is there any documentation I could read to get better informed? Most of the jakarta documentation is on jakarta.apache.org. Try clicking on gump or Website Maintenance. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Help needed on JMeter nightly builds
Hi. JMeter nightly builds have been failing for a long while (long before I joined the project, actually). Noone in the project seems to know why: it builds OK everywhere else. I've tried e-mailing [EMAIL PROTECTED] to get access to Nagoya (where I believe the builds happen), but got no reply. I've e-mailed [EMAIL PROTECTED] for help (looked like the first logical step), but got no reply. I'm totally stuck on this matter. I need help. Any pointers welcome. Thanks a lot, Jordi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Help needed on JMeter nightly builds
Wow! I'm most amazed. It had never worked till the 2nd Jan. And then, suddently, it works from the 3rd onwards! Yes, *I* did a change to build.xml on the 2nd, but it was totally unrelated (different target). Well, who knows. Anyway -- if it ain't broken, don't fix it :-) Thanks a lot for your help! Jordi. Sam Ruby wrote: Jordi Salvat i Alabart wrote: JMeter nightly builds have been failing for a long while (long before I joined the project, actually). Noone in the project seems to know why: it builds OK everywhere else. I've tried e-mailing [EMAIL PROTECTED] to get access to Nagoya (where I believe the builds happen), but got no reply. I've e-mailed [EMAIL PROTECTED] for help (looked like the first logical step), but got no reply. I'm not sure what you are seeing, but jmeter builds for me: http://cvs.apache.org/builds/gump/2003-01-06/jakarta-jmeter.html http://cvs.apache.org/builds/jakarta-jmeter/nightly/ http://gump.covalent.net/jars/2003-01-06/jakarta-jmeter/ Can you describe the problem you are seeing? - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
