Upgrading TestNG

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Upgrading TestNG

ignace.saenen@gmail.com


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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading TestNG

Cédric Beust ♔

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading TestNG

ignace.saenen@gmail.com

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading TestNG

Alexandru Popescu ☀
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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading TestNG

Cédric Beust ♔
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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading TestNG

ignace.saenen@gmail.com


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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading TestNG

Steve Loughran-7
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
-~----------~----~----~----~------~----~------~--~---