[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_54913 ] Jesse Kuhnert commented on MSUREFIRE-23: Yay! This is turning out to be a lot easier than I thought. Question: Does anything in the maven dependency runtime have the ability for me to optionally include one or another artifact depending on the jvm version running? I've basically got an issue where I have to either include the jdk14 or jdk15 version of testng depending on the runtime. One solution that I came up with is bundling the core set of classes/interfaces for testng into a sort of testng-core artifact, and then force the user to specify which testng implementation they want to use. The surefire runtime would also report errors if more than one testng artifact impl was specified. I'm going to pass this along to cedric as well. Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: mike perham Add support for running unit tests with TestNG. http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
testng test integration
If no one is currently working on this I plan on making a stab at it, with the hopes that someone will pipe in and change my plan of direction if I'm going the wrong way. P.S. If you are working on testng integration I won't be sad at all, in fact I'd be very very happy not to have to do it ;) From what I read in nabble archives I saw that someone mentioned integrating it into surefire directly, which sounds like a win-win situation to me judging from the surefire code I looked at for duping into a testng plugin. I do have some questions though: -) I'm guessing that the test runtime should dynamically figure out what sort of classes/jvm version it is working with to execute the correct testing framework? I can't imagine any form of property setting logic being fun for anyone. Hopefully this won't be as painful to do as it sounds :) -) I noticed that the surefire reports plugin is still going through codehaus, is this just a temporary infrastructure management sort of thing, or should I plan on having the testng reporting aspect of things hosted as a seperate plugin download? I'm sure the reporting aspect part will be the least of my problems, but I wanted to address it ahead of time so an answer was available when I was ready for it. Please feel free to jump in and stop/correct any assumptions written here. I also wanted to re-iterate that I won't be sad at all if someone else already owns this ;) jesse
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_54755 ] Jesse Kuhnert commented on MSUREFIRE-23: I posted this to maven dev mailing list but I think it's way too busy to picked up by anyone.. If no one is currently working on this I plan on making a stab at it, with the hopes that someone will pipe in and change my plan of direction if I'm going the wrong way. P.S. If you are working on testng integration I won't be sad at all, in fact I'd be very very happy not to have to do it ;) From what I read in nabble archives I saw that someone mentioned integrating it into surefire directly, which sounds like a win-win situation to me judging from the surefire code I looked at for duping into a testng plugin. I do have some questions though: -) I'm guessing that the test runtime should dynamically figure out what sort of classes/jvm version it is working with to execute the correct testing framework? I can't imagine any form of property setting logic being fun for anyone. Hopefully this won't be as painful to do as it sounds :) -) I noticed that the surefire reports plugin is still going through codehaus, is this just a temporary infrastructure management sort of thing, or should I plan on having the testng reporting aspect of things hosted as a seperate plugin download? I'm sure the reporting aspect part will be the least of my problems, but I wanted to address it ahead of time so an answer was available when I was ready for it. Please feel free to jump in and stop/correct any assumptions written here. I also wanted to re-iterate that I won't be sad at all if someone else already owns this ;) Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: mike perham Add support for running unit tests with TestNG. http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_54816 ] Jesse Kuhnert commented on MSUREFIRE-23: Arggh! Fine... ;) 1) Your method sounds good. Attempt a best-guess at runtime, and if the engine chooses the wrong type the user can force it with a property. 2) Awesome. I like not writing code whenever possible :) I didn't even invest any real thought into it, but there's probably nothing there that a little xslt love can't fix. Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: mike perham Add support for running unit tests with TestNG. http://www.testng.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-140) Tapestry POM missing dependencies for javassist (2.6), ognl (2.6.3), commons-fileupload (1.0)
[ http://jira.codehaus.org/browse/MEV-140?page=comments#action_53782 ] Jesse Kuhnert commented on MEV-140: --- Ok, I'm ready to fix it, how do I do it? ;) I created a jira issue based on what matt posted into tapestry-dev, http://issues.apache.org/jira/browse/TAPESTRY-814. Does this really only affect version 3.0.3? I'm assuming this will require my becoming familiar with ibiblio release processes? Sorry for the noobage, I don't use maven actively anymore (though I've been using it on other projects), and have never deployed anything to ibiblio. All I have to do is update the POM and release a new version? Or is it only the pom file on ibiblio? jesse Tapestry POM missing dependencies for javassist (2.6), ognl (2.6.3), commons-fileupload (1.0) - Key: MEV-140 URL: http://jira.codehaus.org/browse/MEV-140 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Matt Raible Assignee: Edwin Punzalan You might include tapestry-contrib since most everyone uses it when using Tapestry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
