IMO to get the most value out of the plugin we should be able to run any TestNG version. And I guess the code I have written will scale enough well to acomodate this. There are small details that are still needed, but basically I think that approach will work. Moreover, I do think that now the TestNG public API is stable enough to guarantee no future changes (and in case I will be kept involved this time, I will definitely make sure that nothing is released prior to validate that the good API is used -- something that has happened in the past and that finally lead to this failure of providing a good integration with Maven).
bests, ./alex -- .w( the_mindstorm )p. On Nov 17, 2007 4:46 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 16/11/2007, at 7:29 PM, Dan Fabulich wrote: > > > > > After some conversations with Brett, I'm getting started on trying > > to help us get a high quality Surefire 2.4 out the door. I think > > my first goal is to make some more integration tests for Surefire 2.4. > > > > One question I had as I began investigating: what versions of > > TestNG and JUnit is Surefire supposed to support? Is Surefire > > supposed to be compatible with just any version of TestNG? Any 5.x > > version? Just the latest 5.7? > > 4.7, 5.1 and 5.5 tend to be used now. It would be good to retain > compat with them if possible. BTW, 5.6 and 5.7 are now in the repo. > > > > > JUnit 4.4 has a bunch of new features, especially for test > > launchers (that's us). Should those features get rolled into the > > junit4 provider? Into a new junit44 provider? > > Can they be optionally rolled into the junit4 provider? > > > > > Right now the surefire TestNG provider depends directly on TestNG > > 5.5. Is that OK? > > Yes, because it's provided the one the user gives in the classloader > - this is just used for compilation. > > > > > Are we supposed to release new providers every time JUnit/TestNG > > release new versions? > > Not unless they add new features that we need to expose. Hopefully, > the generic mechanisms will already expose them anyway. > > - Brett > > -- > Brett Porter - [EMAIL PROTECTED] > Blog: http://www.devzuz.org/blogs/bporter/ > >
