I have run into this problem already a number of times. Each time I update the version of testNG, the testRunner can't find either the test methods (I'm using a factory to create to tests), or it can't find the classes on the classpath. I usually spend a day to try to clean the projects, target directories, build paths, re-assign them, etc.. but usually the issue just simply goes away without any real reason. maybe someone has experienced the same and has an idea what could be going wrong? Some more info: I have one project A, which contains a classloader. I have one project B which is loaded by A and executed. I have one project CTest, which is the testNG project that fires up A and communicates with it such that B is eventually executing (and being tested). It is generally tricky to set up the classpath list for the TestNG project, since the TestNG project should be able to refer to (in the example above) CTest and A, but not B, because this is to be left to the classloader in A. Also order seems to play a huge difference. Any ideas or help is welcome! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "testng-users" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/testng-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
Hi Ignace, There is absolutely no reason why you should be seeing this at each upgrade (or at least, no reason that TestNG itself should be the culprit...). Considering the configuration that you describe, I wonder if there is not something inherently fragile between the classloading code that you are using and these three projects that interact with each other. Can you expand on what errors you see when you upgrade? -- Cedric On 2/19/07, [hidden email] <[hidden email]> wrote: > > > I have run into this problem already a number of times. Each time I > update the version of testNG, the testRunner can't find either the > test methods (I'm using a factory to create to tests), or it can't > find the classes on the classpath. I usually spend a day to try to > clean the projects, target directories, build paths, re-assign them, > etc.. but usually the issue just simply goes away without any real > reason. maybe someone has experienced the same and has an idea what > could be going wrong? > > Some more info: I have one project A, which contains a classloader. I > have one project B which is loaded by A and executed. I have one > project CTest, which is the testNG project that fires up A and > communicates with it such that B is eventually executing (and being > tested). > > It is generally tricky to set up the classpath list for the TestNG > project, since the TestNG project should be able to refer to (in the > example above) CTest and A, but not B, because this is to be left to > the classloader in A. Also order seems to play a huge difference. > > Any ideas or help is welcome! > > > > > -- Cédric --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "testng-users" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/testng-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
Hello Cedric, Well it's certainly true that our code is at best dodgy, and usually described as "legacy". The classloader is certainly adding to the complexity. The other issues I have are the NoClassDefFound's (package and project dependencies, and there seems to be some caching in my legacy code as well that is playing hide and seek with the classloader.), and testRunners that fail to run any group. I have tracked down some other sources of the problem (like network drives not being ready), but I'm not sure why everytime I upgrade the TestNG lib, I get these testRunner problems.. Could it be because I build with ant within eclipse against a testNG.jar, that the eclipse testNG configuration runner mismatches? For safety I have removed all other instances and references to previous testNG versions. After repeatedly cleaning projects in Eclipse and rebuilding them (this is something I seem to have to do a few times), and fixing some other things, I have the tests running again, but not before I removed a <group> <run> block and then putting it back again. Thanks for replying, I think I'll have to do some more digging.. On 19 feb, 17:27, "Cédric Beust ♔ " <[hidden email]> wrote: > Hi Ignace, > > There is absolutely no reason why you should be seeing this at each > upgrade (or at least, no reason that TestNG itself should be the > culprit...). > > Considering the configuration that you describe, I wonder if there is > not something inherently fragile between the classloading code that > you are using and these three projects that interact with each other. > > Can you expand on what errors you see when you upgrade? > > -- > Cedric > > On 2/19/07, [hidden email] <[hidden email]> wrote: > > > > > > > I have run into this problem already a number of times. Each time I > > update the version of testNG, the testRunner can't find either the > > test methods (I'm using a factory to create to tests), or it can't > > find the classes on the classpath. I usually spend a day to try to > > clean the projects, target directories, build paths, re-assign them, > > etc.. but usually the issue just simply goes away without any real > > reason. maybe someone has experienced the same and has an idea what > > could be going wrong? > > > Some more info: I have one project A, which contains a classloader. I > > have one project B which is loaded by A and executed. I have one > > project CTest, which is the testNG project that fires up A and > > communicates with it such that B is eventually executing (and being > > tested). > > > It is generally tricky to set up the classpath list for the TestNG > > project, since the TestNG project should be able to refer to (in the > > example above) CTest and A, but not B, because this is to be left to > > the classloader in A. Also order seems to play a huge difference. > > > Any ideas or help is welcome! > > -- > Cédric --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "testng-users" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/testng-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
On 2/19/07, [hidden email] <[hidden email]> wrote:
> > Hello Cedric, > > Well it's certainly true that our code is at best dodgy, and usually > described as "legacy". > > [...] (package and project > dependencies, and there seems to be some caching in my legacy code as > well that is playing hide and seek with the classloader.), and > testRunners that fail to run any group. [...] > Aren't these somehow related? If the code is not compiled or not loaded, most probably TestNG will not see it. However, your environment looks pretty complex and I can only guess here. ./alex -- .w( the_mindstorm )p. TestNG co-founder EclipseTestNG Creator > > Could it be because I build with ant within eclipse against a > testNG.jar, that the eclipse testNG configuration runner mismatches? > For safety I have removed all other instances and references to > previous testNG versions. After repeatedly cleaning projects in > Eclipse and rebuilding them (this is something I seem to have to do a > few times), and fixing some other things, I have the tests running > again, but not before I removed a <group> <run> block and then putting > it back again. > > Thanks for replying, I think I'll have to do some more digging.. > > > On 19 feb, 17:27, "Cédric Beust ♔ " <[hidden email]> wrote: > > Hi Ignace, > > > > There is absolutely no reason why you should be seeing this at each > > upgrade (or at least, no reason that TestNG itself should be the > > culprit...). > > > > Considering the configuration that you describe, I wonder if there is > > not something inherently fragile between the classloading code that > > you are using and these three projects that interact with each other. > > > > Can you expand on what errors you see when you upgrade? > > > > -- > > Cedric > > > > On 2/19/07, [hidden email] <[hidden email]> wrote: > > > > > > > > > > > > > I have run into this problem already a number of times. Each time I > > > update the version of testNG, the testRunner can't find either the > > > test methods (I'm using a factory to create to tests), or it can't > > > find the classes on the classpath. I usually spend a day to try to > > > clean the projects, target directories, build paths, re-assign them, > > > etc.. but usually the issue just simply goes away without any real > > > reason. maybe someone has experienced the same and has an idea what > > > could be going wrong? > > > > > Some more info: I have one project A, which contains a classloader. I > > > have one project B which is loaded by A and executed. I have one > > > project CTest, which is the testNG project that fires up A and > > > communicates with it such that B is eventually executing (and being > > > tested). > > > > > It is generally tricky to set up the classpath list for the TestNG > > > project, since the TestNG project should be able to refer to (in the > > > example above) CTest and A, but not B, because this is to be left to > > > the classloader in A. Also order seems to play a huge difference. > > > > > Any ideas or help is welcome! > > > > -- > > Cédric > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "testng-users" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/testng-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
In reply to this post by ignace.saenen@gmail.com
Ignace,
A possible avenue to explore would be how Eclipse caches its version of the TestNG jar file. At the very least, I expect that once you have updated the plug-in in Eclipse via the remote update interface (that's how you upgrade, right?), then a restart of the IDE should solve any classloading problem you might have seen. -- Cedric On 2/19/07, [hidden email] <[hidden email]> wrote: > > Hello Cedric, > > Well it's certainly true that our code is at best dodgy, and usually > described as "legacy". > > The classloader is certainly adding to the complexity. The other > issues I have are the NoClassDefFound's (package and project > dependencies, and there seems to be some caching in my legacy code as > well that is playing hide and seek with the classloader.), and > testRunners that fail to run any group. I have tracked down some > other sources of the problem (like network drives not being ready), > but I'm not sure why everytime I upgrade the TestNG lib, I get these > testRunner problems.. > > > Could it be because I build with ant within eclipse against a > testNG.jar, that the eclipse testNG configuration runner mismatches? > For safety I have removed all other instances and references to > previous testNG versions. After repeatedly cleaning projects in > Eclipse and rebuilding them (this is something I seem to have to do a > few times), and fixing some other things, I have the tests running > again, but not before I removed a <group> <run> block and then putting > it back again. > > Thanks for replying, I think I'll have to do some more digging.. > > > On 19 feb, 17:27, "Cédric Beust ♔ " <[hidden email]> wrote: > > Hi Ignace, > > > > There is absolutely no reason why you should be seeing this at each > > upgrade (or at least, no reason that TestNG itself should be the > > culprit...). > > > > Considering the configuration that you describe, I wonder if there is > > not something inherently fragile between the classloading code that > > you are using and these three projects that interact with each other. > > > > Can you expand on what errors you see when you upgrade? > > > > -- > > Cedric > > > > On 2/19/07, [hidden email] <[hidden email]> wrote: > > > > > > > > > > > > > I have run into this problem already a number of times. Each time I > > > update the version of testNG, the testRunner can't find either the > > > test methods (I'm using a factory to create to tests), or it can't > > > find the classes on the classpath. I usually spend a day to try to > > > clean the projects, target directories, build paths, re-assign them, > > > etc.. but usually the issue just simply goes away without any real > > > reason. maybe someone has experienced the same and has an idea what > > > could be going wrong? > > > > > Some more info: I have one project A, which contains a classloader. I > > > have one project B which is loaded by A and executed. I have one > > > project CTest, which is the testNG project that fires up A and > > > communicates with it such that B is eventually executing (and being > > > tested). > > > > > It is generally tricky to set up the classpath list for the TestNG > > > project, since the TestNG project should be able to refer to (in the > > > example above) CTest and A, but not B, because this is to be left to > > > the classloader in A. Also order seems to play a huge difference. > > > > > Any ideas or help is welcome! > > > > -- > > Cédric > > > > > -- Cédric --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "testng-users" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/testng-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
Yes that is also what is happening. Eclipse restarts and the new plugin is loaded. So, when the plugin in eclipse is refreshed with the new version, could it be that ant-built projects (using "external tools") that were previously built against a previous version of testNG can suffer from these loading issues? On 19 feb, 19:30, "Cédric Beust ♔ " <[hidden email]> wrote: > Ignace, > > A possible avenue to explore would be how Eclipse caches its version > of the TestNG jar file. > > At the very least, I expect that once you have updated the plug-in in > Eclipse via the remote update interface (that's how you upgrade, > right?), then a restart of the IDE should solve any classloading > problem you might have seen. > > -- > Cedric > > On 2/19/07, [hidden email] <[hidden email]> wrote: > > > > > > > Hello Cedric, > > > Well it's certainly true that our code is at best dodgy, and usually > > described as "legacy". > > > The classloader is certainly adding to the complexity. The other > > issues I have are the NoClassDefFound's (package and project > > dependencies, and there seems to be some caching in my legacy code as > > well that is playing hide and seek with the classloader.), and > > testRunners that fail to run any group. I have tracked down some > > other sources of the problem (like network drives not being ready), > > but I'm not sure why everytime I upgrade the TestNG lib, I get these > > testRunner problems.. > > > Could it be because I build with ant within eclipse against a > > testNG.jar, that the eclipse testNG configuration runner mismatches? > > For safety I have removed all other instances and references to > > previous testNG versions. After repeatedly cleaning projects in > > Eclipse and rebuilding them (this is something I seem to have to do a > > few times), and fixing some other things, I have the tests running > > again, but not before I removed a <group> <run> block and then putting > > it back again. > > > Thanks for replying, I think I'll have to do some more digging.. > > > On 19 feb, 17:27, "Cédric Beust ♔ " <[hidden email]> wrote: > > > Hi Ignace, > > > > There is absolutely no reason why you should be seeing this at each > > > upgrade (or at least, no reason that TestNG itself should be the > > > culprit...). > > > > Considering the configuration that you describe, I wonder if there is > > > not something inherently fragile between the classloading code that > > > you are using and these three projects that interact with each other. > > > > Can you expand on what errors you see when you upgrade? > > > > -- > > > Cedric > > > > On 2/19/07, [hidden email] <[hidden email]> wrote: > > > > > I have run into this problem already a number of times. Each time I > > > > update the version of testNG, the testRunner can't find either the > > > > test methods (I'm using a factory to create to tests), or it can't > > > > find the classes on the classpath. I usually spend a day to try to > > > > clean the projects, target directories, build paths, re-assign them, > > > > etc.. but usually the issue just simply goes away without any real > > > > reason. maybe someone has experienced the same and has an idea what > > > > could be going wrong? > > > > > Some more info: I have one project A, which contains a classloader. I > > > > have one project B which is loaded by A and executed. I have one > > > > project CTest, which is the testNG project that fires up A and > > > > communicates with it such that B is eventually executing (and being > > > > tested). > > > > > It is generally tricky to set up the classpath list for the TestNG > > > > project, since the TestNG project should be able to refer to (in the > > > > example above) CTest and A, but not B, because this is to be left to > > > > the classloader in A. Also order seems to play a huge difference. > > > > > Any ideas or help is welcome! > > > > -- > > > Cédric > > -- > Cédric --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "testng-users" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/testng-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
On 20/02/07, [hidden email] <[hidden email]> wrote:
> > > Yes that is also what is happening. Eclipse restarts and the new > plugin is loaded. > > So, when the plugin in eclipse is refreshed with the new version, > could it be that ant-built projects (using "external tools") that were > previously built against a previous version of testNG can suffer from > these loading issues? > Depends on the mysteries of OSGi there I'm afraid. Just because one eclipse plugin has the new stuff, doesnt mean the ant runner picks it up. In particular, if your code is compiled using the later version with eclipse taking over the javac phase, you may have some versioning grief. Clearly, I'm not a fan of eclipse http://www.1060.org/blogxter/entry?publicid=A5F8A45FC26DEF47F42A277005C164AE -steve > > > On 19 feb, 19:30, "Cédric Beust ♔ " <[hidden email]> wrote: > > Ignace, > > > > A possible avenue to explore would be how Eclipse caches its version > > of the TestNG jar file. > > > > At the very least, I expect that once you have updated the plug-in in > > Eclipse via the remote update interface (that's how you upgrade, > > right?), then a restart of the IDE should solve any classloading > > problem you might have seen. > > > > -- > > Cedric > > > > On 2/19/07, [hidden email] <[hidden email]> wrote: > > > > > > > > > > > > > Hello Cedric, > > > > > Well it's certainly true that our code is at best dodgy, and usually > > > described as "legacy". > > > > > The classloader is certainly adding to the complexity. The other > > > issues I have are the NoClassDefFound's (package and project > > > dependencies, and there seems to be some caching in my legacy code as > > > well that is playing hide and seek with the classloader.), and > > > testRunners that fail to run any group. I have tracked down some > > > other sources of the problem (like network drives not being ready), > > > but I'm not sure why everytime I upgrade the TestNG lib, I get these > > > testRunner problems.. > > > > > Could it be because I build with ant within eclipse against a > > > testNG.jar, that the eclipse testNG configuration runner mismatches? > > > For safety I have removed all other instances and references to > > > previous testNG versions. After repeatedly cleaning projects in > > > Eclipse and rebuilding them (this is something I seem to have to do a > > > few times), and fixing some other things, I have the tests running > > > again, but not before I removed a <group> <run> block and then putting > > > it back again. > > > > > Thanks for replying, I think I'll have to do some more digging.. > > > > > On 19 feb, 17:27, "Cédric Beust ♔ " <[hidden email]> wrote: > > > > Hi Ignace, > > > > > > There is absolutely no reason why you should be seeing this at each > > > > upgrade (or at least, no reason that TestNG itself should be the > > > > culprit...). > > > > > > Considering the configuration that you describe, I wonder if there is > > > > not something inherently fragile between the classloading code that > > > > you are using and these three projects that interact with each other. > > > > > > Can you expand on what errors you see when you upgrade? > > > > > > -- > > > > Cedric > > > > > > On 2/19/07, [hidden email] <[hidden email]> wrote: > > > > > > > I have run into this problem already a number of times. Each time I > > > > > update the version of testNG, the testRunner can't find either the > > > > > test methods (I'm using a factory to create to tests), or it can't > > > > > find the classes on the classpath. I usually spend a day to try to > > > > > clean the projects, target directories, build paths, re-assign them, > > > > > etc.. but usually the issue just simply goes away without any real > > > > > reason. maybe someone has experienced the same and has an idea what > > > > > could be going wrong? > > > > > > > Some more info: I have one project A, which contains a classloader. I > > > > > have one project B which is loaded by A and executed. I have one > > > > > project CTest, which is the testNG project that fires up A and > > > > > communicates with it such that B is eventually executing (and being > > > > > tested). > > > > > > > It is generally tricky to set up the classpath list for the TestNG > > > > > project, since the TestNG project should be able to refer to (in the > > > > > example above) CTest and A, but not B, because this is to be left to > > > > > the classloader in A. Also order seems to play a huge difference. > > > > > > > Any ideas or help is welcome! > > > > > > -- > > > > Cédric > > > > -- > > Cédric > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "testng-users" group. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] For more options, visit this group at http://groups.google.com/group/testng-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
Free forum by Nabble | Edit this page |