[testng-users] Error instanciating an inner class (eclipse plugin 5.14)

[c_inconnu]

Hi,
I just upgraded to eclipse plugin 5.14 and now all my tests with an inner
class are failling with this message :

RemoteTestNG starting
org.testng.TestNGException:
An error occurred while instantiating class aaa.bbb.Cccc$6. Check to make
sure it can be accessed/instantiated.
at org.testng.internal.ClassHelper.createInstance(ClassHelper.java:348)
at org.testng.internal.ClassImpl.getDefaultInstance(ClassImpl.java:89)
at org.testng.internal.ClassImpl.getInstances(ClassImpl.java:107)
at org.testng.internal.TestNGClassFinder.<init>(TestNGClassFinder.java:117)
at org.testng.TestRunner.initMethods(TestRunner.java:394)
at org.testng.TestRunner.init(TestRunner.java:228)
at org.testng.TestRunner.init(TestRunner.java:198)
at org.testng.TestRunner.<init>(TestRunner.java:154)
at org.testng.remote.RemoteTestNG$1.newTestRunner(RemoteTestNG.java:139)
at
org.testng.remote.RemoteTestNG$DelegatingTestRunnerFactory.newTestRunner(RemoteTestNG.java:272)
at
org.testng.SuiteRunner$ProxyTestRunnerFactory.newTestRunner(SuiteRunner.java:542)
at org.testng.SuiteRunner.init(SuiteRunner.java:142)
at org.testng.SuiteRunner.<init>(SuiteRunner.java:106)
at org.testng.TestNG.createSuiteRunner(TestNG.java:1051)
at org.testng.TestNG.createSuiteRunners(TestNG.java:1037)
at org.testng.TestNG.runSuitesLocally(TestNG.java:877)
at org.testng.TestNG.run(TestNG.java:820)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:110)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:205)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:174)

My class looks something like that :

public void testAAA()
{
new FacesRequestLocal("blabla") { ... }
}

It is working fine with Maven

<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>5.14.2</version>
<scope>test</scope>
</dependency>

Is it a bug or an expected (new) behaviour ?
Thanks
--
View this message in context: http://old.nabble.com/Error-instanciating-an-inner-class-%28eclipse-plugin-5.14%29-tp30354626p30354626.html
Sent from the testng-users mailing list archive at Nabble.com.

[Carsten]

Hi,

we noticed the same issue and I mentioned this here:
http://groups.google.com/group/testng-users/browse_thread/thread/1401e775970b0e29/ab62b152ca309f81?hl=en&lnk=gst&q=announcing#ab62b152ca309f81

There is a new check-in ClassHelper which is causing this new behavior
(came in between version 5.11 and 5.12):

if (null == result) {
//result should not be null
throw new TestNGException("An error occurred while instantiating
class "
+ declaringClass.getName() + ". Check to make sure it can be
accessed/instantiated.");
}

I commented these lines out in our testng version and now everything
works as before.

@Cedric: Is this new null check an improved error message and can be
removed/modified? ClassHelper.tryOtherConstructor(declaringClass);
returns null in case of anonymous inner classes.

Thanks,
Carsten

> View this message in context:http://old.nabble.com/Error-instanciating-an-inner-class-%28eclipse-p...

[Cédric Beust ♔]

Carsten,

TestNG should be able to instantiate all the test classes you specify, if this inner class is not a test class, can't you just excluded it in your testng.xml file?

-- 

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 testng...@googlegroups.com.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

--
Cédric

[Carsten]

Oh I only tried my inner class example with 5.13.1. It is actually
working with 5.14.1.

Inconnu, I tried your example:

if testAAA() is a @Test method I get the same error (does it makes
sense to create an inner class of another test-class within a @Test
method?)
if testAAA() is a @Factory method everything works as expected

Carsten

On Dec 2, 4:00 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
> Carsten,
>
> TestNG should be able to instantiate all the test classes you specify, if
> this inner class is not a test class, can't you just excluded it in your
> testng.xml file?
>
> --
> Cédric
>
> On Thu, Dec 2, 2010 at 1:48 AM, Carsten

> <carsten.guberna...@googlemail.com>wrote:

>
>
>
> > Hi,
>
> > we noticed the same issue and I mentioned this here:
>

> >http://groups.google.com/group/testng-users/browse_thread/thread/1401...

> > testng-users...@googlegroups.com<testng-users%2Bunsu...@googlegroups.com>
> > .

[c_inconnu]

http://old.nabble.com/file/p30362883/testng-test.zip testng-test.zip

hi,
investigating further, I found the problem. I created a really small project
(attached) to demonstrate this behaviour. If you launch "Test
embedded.launch" which use "allTests-embedded.xml" only, it works fine, but
if you launch "Test all.launch" which use "allTests-embedded.xml" AND
"allTests-standalone.xml", it does not work (with the aforementioned
exception)

so there is something wrong, one way or another (isn't it?)

thanks for developping testng, anyway !
David
--
View this message in context: http://old.nabble.com/Error-instanciating-an-inner-class-%28eclipse-plugin-5.14%29-tp30354626p30362883.html

[Cédric Beust ♔]

Salut David,

I think this is working as expected.

When you tell TestNG to run a package, it will run all the classes it can find in this package, including nested classes, and in this case, your nested class doesn't have a parameterless constructor, so TestNG can't instantiate it.

Either exclude your nested classes or make them instantiable (probably the wrong solution since they are not test classes so you're wasting TestNG's time).

-- 

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 testng...@googlegroups.com.

To unsubscribe from this group, send email to testng-users...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

--
Cédric

[c_inconnu]

ok, i think it's a little weird to run nested classes, but if this is the
expected behaviour... if you have some time, why is that ?

but there is something i cannot find in the documentation :

<test name="Standalone">
<groups>
<run>
<include name="standalone" />
</run>
</groups>

<packages>
<package name="test" />
</packages>
</test>

is it running all classes in test package ***AND*** belong to the
"standalone" group,
or
is it running all classes in test package ***OR*** belong to the
"standalone" group

i see "OR" happening, but i always thought it was "AND" ???

thanks for your time
David

--
View this message in context: http://old.nabble.com/Error-instanciating-an-inner-class-%28eclipse-plugin-5.14%29-tp30354626p30363298.html

[Cédric Beust ♔]

Hi David,

On Thu, Dec 2, 2010 at 2:13 PM, c_inconnu <c_inc...@yahoo.fr> wrote:

ok, i think it's a little weird to run nested classes, but if this is the
expected behaviour... if you have some time, why is that ?

Some people put tests in nested classes, but the bottom line is that excluding nested classes would make it hard to include these classes back, so I thought that running "all the classes" (even nested ones) was more logical.

 

but there is something i cannot find in the documentation :

   <test name="Standalone">
       <groups>
           <run>
               <include name="standalone" />
           </run>
       </groups>

       <packages>
           <package name="test" />
       </packages>
   </test>

is it running all classes in test package ***AND*** belong to the
"standalone" group,
or
is it running all classes in test package ***OR*** belong to the
"standalone" group

i see "OR" happening, but i always thought it was "AND" ???

<package> gives TestNG a list of all the classes to look into.

Out of all these classes, it will only run the classes that match the group specification.

So the short answer is: TestNG uses "AND".

--
Cédric

[c_inconnu]

http://old.nabble.com/file/p30363505/testng-test-2.zip testng-test-2.zip

well, i may miss something really obvious but in the new test case attached,
running "standalone" raises:
"An error occurred while instantiating class test.TestClassEmbedded$1. Check

to make sure it can be accessed/instantiated."

<test name="Standalone">
<groups>
<run>
<include name="standalone" />
</run>
</groups>

<packages>
<package name="test" />
</packages>
</test>

@Test(groups = { "embedded" })
public class TestClassEmbedded {}

@Test(groups = { "standalone" })
public class TestClassStandalone {}
--
View this message in context: http://old.nabble.com/Error-instanciating-an-inner-class-%28eclipse-plugin-5.14%29-tp30354626p30363505.html

[Brian M]

Chiming in on this: I agree with David that something seems amiss
here. I just upgraded to Eclipse plugin 5.14.3 and began seeing the
same problem David describes. My test suite won't run anymore because
not only is TestNG now trying to instantiate my test classes, it also
tries to instantiate nested classes and all my app classes (because
the way my app is structured, test classes and app classes are in the
same packages.)

> So the short answer is: TestNG uses "AND".

It seems like this might be broken. The Eclipse plugin 5.14.3 appears
to be using "OR". I say that because if you specify the a set of
groups and a set of packages, TestNG now tries to instantiate any
class--including nested classes--that is either in one of the groups
or in one of the packages.

And it ignores the existence of the @Test annotation. It tries to
instantiate classes regardless of whether they have @Test.

Brian M



On Dec 2, 2:40 pm, c_inconnu <c_incon...@yahoo.fr> wrote:
> http://old.nabble.com/file/p30363505/testng-test-2.ziptestng-test-2.zip

>
> well, i may miss something really obvious but in the new test case attached,
> running "standalone" raises:
> "An error occurred while instantiating class test.TestClassEmbedded$1. Check
> to make sure it can be accessed/instantiated."
>
>     <test name="Standalone">
>         <groups>
>             <run>
>                 <include name="standalone" />
>             </run>
>         </groups>
>
>         <packages>
>             <package name="test" />
>         </packages>
>     </test>
>
> @Test(groups = { "embedded" })
> public class TestClassEmbedded {}
>
> @Test(groups = { "standalone" })
> public class TestClassStandalone {}
> --

> View this message in context:http://old.nabble.com/Error-instanciating-an-inner-class-%28eclipse-p...

[Cédric Beust ♔]

Are you sure you're not using a <package> tag somewhere in your testng.xml?

-- 

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 testng...@googlegroups.com.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

--
Cédric

[Brian M]

Wow, you're quick. :-)

Yes, I am using a <package> tag in my testng.xml. Sorry I wasn't
clear. That's what I meant when I said that TestNG now seems to be
using "OR" instead of "AND." My testng.xml specifies two things:
1. A package (com.intuit.*)
2. A group ("functional")

Before I upgraded, TestNG would instantiate classes that:
- were in the com.intuit package AND
- were marked with @Test(groups = {"functional"})

Now, after the upgrade, TestNG seems to be trying to instantiate all
classes that:
- are in the com.intuit package OR
- are marked with @Test(groups = {"functional"})

The difference: AND changed to OR.

So now it basically tries to instantiate every class I have.

Brian M

> > testng-users...@googlegroups.com<testng-users%2Bunsu...@googlegroups.com>
> > .

[Cédric Beust ♔]

Hi Brian,

I am 99% sure that this behavior didn't change, because it's theoretically impossible to do it the way you say.

Before TestNG knows whether a certain method or class needs to be excluded, it needs to have instantiated that class so it can find the annotations on it.

Basically, you are saying that "before", TestNG knew that it didn't need to instantiate A$B because A$B didn't contain any @Test(groups = "..."). But in order to tell that, TestNG needs to instantiate A$B!

The bottom line is that TestNG always proceeds in this order:

• Instantiate everything it was told to. If it's <classes>, only these classes will be instantiated. If it's <packages>, TestNG will instantiate *all* the classes that belong to this package, including nested ones.
  
  
• Then look up the annotations on all these classes and exclude/include methods as appropriate.

Makes sense?

-- 

Cédric

To unsubscribe from this group, send email to testng-users...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

--
Cédric

[Brian M]

Hi Cédric,

Yes, theoretically that makes sense. In practice several of us on this
list, and my coworkers who upgrade to Eclipse plugin 5.14.3, are
seeing that TestNG now instantiates nested classes when it didn't do
that before the upgrade.

Or perhaps the difference is that it has always tried to instantiate
them but swallowed errors, and now it reports an error when it can't
instantiate a class?

My coworker who is still using version 5.14.2.9 of the Eclipse plugin
does not have this problem. She can run our test suite without errors.

Brian

On Dec 6, 4:26 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
> Hi Brian,
>
> I am 99% sure that this behavior didn't change, because it's theoretically
> impossible to do it the way you say.
>
> Before TestNG knows whether a certain method or class needs to be excluded,
> it needs to have instantiated that class so it can find the annotations on
> it.
>
> Basically, you are saying that "before", TestNG knew that it didn't need to
> instantiate A$B because A$B didn't contain any @Test(groups = "..."). But in
> order to tell that, TestNG needs to instantiate A$B!
>
> The bottom line is that TestNG always proceeds in this order:
>

>    - Instantiate everything it was told to. If it's <classes>, only these

>    classes will be instantiated. If it's <packages>, TestNG will instantiate
>    *all* the classes that belong to this package, including nested ones.
>

>    - Then look up the annotations on all these classes and exclude/include

> > <testng-users%2Bunsu...@googlegroups.com<testng-users%252Buns...@googlegroups.com>

[c_inconnu]

Hi everyone,

First thanks to Cedric who takes time to answer our questions, since i know
some forums where it's very rarely the case...

I think, indeed, that before that the error was swallowed: i saw somewhere
else that "if(result==null)throw" was added.
1. I now understand why I have "An error occurred while instantiating class
test.TestClassEmbedded$1" when I run my "standalone" test suite
2. Is there a way to exclude all inner classes then?

Thanks
David

> testng-users...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/testng-users?hl=en.
>
>
>

--
View this message in context: http://old.nabble.com/Error-instanciating-an-inner-class-%28eclipse-plugin-5.14%29-tp30354626p30394685.html

[Gordon M.]

Hi Cédric,

I'm another developer working with Brian M and seeing the same issue.

The change in question appears to be
TestNGClassFinder.isTestNGClass(), from this commit (https://
github.com/cbeust/testng/commit/
bb4cfdadd903ebefb0510bc8586b7b353cf29d17 -- "Allow abstract methods in
superclasses to specify @Test annotations. Also made isTestNGCLass()
return true all the time, even if no TestNG annotations are found.").

This issue is that previously, isTestNGClass() was filtering out
classes that weren't marked @Test. Now that it's stubbed out, TestNG
is much more aggressive about trying to instantiate ALL classes in the
package, regardless of whether they are annotated.

In our setup, both test and logic classes live in the same package but
different jars. My guess is that previously TestNG ignored the logic
classes because they weren't marked with @Test. Does that make
sense? Are we doing something screwy? It would suck to have to
manually exclude all of our logic classes!

Thanks for your help,
-Gordon

[Cédric Beust ♔]

Hi Gordon,

You are right, and I was wrong. This code did indeed introspect the classes without instantiating them and it prevented nested classes with no TestNG annotations from ever being instantiated. As you point out, TestNG is now more aggressive in instantiating classes that don't have TestNG annotations in them.

I committed this five days ago, though, are you using a testng.jar that you build yourself from github? Just curious.

I made this a change after a private discussion with a user who had architected his TestNG classes in such a way that his test classes no longer contained any TestNG annotation. Thanks to inheritance, he was able to write entire TestNG classes without ever using any TestNG annotations, which I found pretty neat (and which was also one of my primary goals with TestNG: to be as little intrusive as possible).

The problem he was facing was that because his class no longer contained any TestNG annotations, TestNG simply refused to see it :-)

A workaround is to add a dummy @Test annotation but I didn't like that solution, so I relaxed the check.

I'm still undecided about what the best solution is, so I'm happy to hear suggestions from both sides.

As for the nested classes, here is a simple way to tell TestNG not to instantiate nested classes when you're specifying packages:

    <packages>

      <package name="test.tmp.a">

        <exclude name=".*\$.*" />

      </package>

    </packages>

This simply tells TestNG to exclude any class that has a dollar sign in it, which is how nested classes are named by javac.

-- 

Cédric

To unsubscribe from this group, send email to testng-users...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

--
Cédric

[Cédric Beust ♔]

Actually, I think I found a solution that will work for everyone.

Please download the beta at http://testng.org/beta and let me know how it works for you.

-- 

Cédric

2010/12/7 Cédric Beust ♔ <ced...@beust.com>

--
Cédric

[Brian M]

Hi Cédric,

Thank you so much for the detailed explanation of what's going on and
the rationale for the change.

I haven't tried your solution at testng.org/beta yet but I will try
it.

In answer to your curiosity about whether Gordon and I got the code
straight from Github: no, we used Eclipse's "Check for Updates"
feature. It found the new version of TestNG at http://beust.com/eclipse.
The date stamp on the newest version there is 20101203, so it's after
the date you made the change on Github.

Your suggestion for excluding nested classes is helpful. I wasn't
aware that nested classes include a $ sign and that non-nested classes
don't.

You asked for feedback on the solution you tried out a few days ago. I
don't think I quite understood the description of how someone used a
class hierarchy to eliminate the need for the @Test annotation, but
maybe it would help to state some general goals:

- I would like to not have to maintain a lengthy testng.xml file,
adding new lines to it whenever I add new test classes or nested
classes (that don't contain tests). I strongly prefer a simple
testng.xml file with a couple of rules that never have to change when
tests are added or deleted.
- I don't mind adding @Test to each test method. It doesn't feel
intrusive to me. But I also wouldn't mind if TestNG followed a naming
convention. E.g., all public methods whose name starts with "test" are
considered test methods and all classes whose name starts with "Test"
are considered test classes. The important thing would be that it can
find the test methods very quickly.

Brian M

> > > > > <testng-users%2Bunsu...@googlegroups.com<testng-users%252Buns...@googlegroups.com>
> > <testng-users%252Buns...@googlegroups.com<testng-users%25252Bun...@googlegroups.com>

> ...
>
> read more »

[Cédric Beust ♔]

Hi Brian,

On Tue, Dec 7, 2010 at 11:43 AM, Brian M <bmor...@gmail.com> wrote:

Hi Cédric,

Thank you so much for the detailed explanation of what's going on and
the rationale for the change.

I haven't tried your solution at testng.org/beta yet but I will try
it.

In answer to your curiosity about whether Gordon and I got the code
straight from Github: no, we used Eclipse's "Check for Updates"
feature. It found the new version of TestNG at http://beust.com/eclipse.
The date stamp on the newest version there is 20101203, so it's after
the date you made the change on Github.

Oh, of course. I need to remember that I expose users to beta versions with every new Eclipse plug-in version I release :-)

 

Your suggestion for excluding nested classes is helpful. I wasn't
aware that nested classes include a $ sign and that non-nested classes
don't.

You asked for feedback on the solution you tried out a few days ago. I
don't think I quite understood the description of how someone used a
class hierarchy to eliminate the need for the @Test annotation, but
maybe it would help to state some general goals:

- I would like to not have to maintain a lengthy testng.xml file,
adding new lines to it whenever I add new test classes or nested
classes (that don't contain tests). I strongly prefer a simple
testng.xml file with a couple of rules that never have to change when
tests are added or deleted.
- I don't mind adding @Test to each test method. It doesn't feel
intrusive to me. But I also wouldn't mind if TestNG followed a naming
convention. E.g., all public methods whose name starts with "test" are
considered test methods and all classes whose name starts with "Test"
are considered test classes. The important thing would be that it can
find the test methods very quickly.

Are you aware that if you put @Test on the class, then all the public methods of this class automatically become test methods without needing individual @Test annotations?

Similarly, if you put that @Test annotation on a base class and you extend that base class, all your public methods automatically become test methods and you don't even have any TestNG annotations in your class any more.

--
Cédric

[Brian M]

> Are you aware that if you put @Test on the class, then all the public
> methods of this class automatically become test methods without needing
> individual @Test annotations?
>
> Similarly, if you put that @Test annotation on a base class and you extend
> that base class, all your public methods automatically become test methods
> and you don't even have any TestNG annotations in your class any more.

Nice. If I was previously aware of those facts, I had forgotten them.

Brian

On Dec 7, 11:49 am, Cédric Beust ♔ <ced...@beust.com> wrote:
> Hi Brian,
>

> On Tue, Dec 7, 2010 at 11:43 AM, Brian M <bmorea...@gmail.com> wrote:
> > Hi Cédric,
>
> > Thank you so much for the detailed explanation of what's going on and
> > the rationale for the change.
>
> > I haven't tried your solution at testng.org/beta yet but I will try
> > it.
>
> > In answer to your curiosity about whether Gordon and I got the code
> > straight from Github: no, we used Eclipse's "Check for Updates"

> > feature. It found the new version of TestNG athttp://beust.com/eclipse.

[Brian M]

Cédric,

I appreciate the patch. Is there a simple way to package it up for
Eclipse? It's been a long time since I ran TestNG on the command line
and I'm having trouble getting it working in my environment,
independent of which version of TestNG I use. If it's easy to package
it up for installation into Eclipse, that would make it easier for me
to verify the change.

Brian

On Dec 7, 11:33 am, Cédric Beust ♔ <ced...@beust.com> wrote:
> Actually, I think I found a solution that will work for everyone.
>

> Please download the beta athttp://testng.org/betaand let me know how it

> >> > > > <testng-users%2Bunsu...@googlegroups.com<testng-users%252Buns...@googlegroups.com>
> >> <testng-users%252Buns...@googlegroups.com<testng-users%25252Bun...@googlegroups.com>

>
> >> > > > > > .
> >> > > > > > For more options, visit this group at
> >> > > > > >http://groups.google.com/group/testng-users?hl=en.
>
> >> > > > > --
> >> > > > > 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 testng...@googlegroups.com.
> >> > > > To unsubscribe from this group, send email to
> >> > > > testng-users...@googlegroups.com<testng-users%2Bunsu...@googlegroups.com>
>

> ...
>
> read more »

[Cédric Beust ♔]

Hi Brian,

I just pushed a new version of the Eclipse plug-in that contains the new TestNG version.

-- 

Cédric

To unsubscribe from this group, send email to testng-users...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

--
Cédric

[c_inconnu]

Thanks but it does not work (with my project at least), I got:

RemoteTestNG starting
java.lang.NullPointerException
at
org.testng.internal.TestNGClassFinder.isTestNGClass(TestNGClassFinder.java:217)
at org.testng.internal.TestNGClassFinder.<init>(TestNGClassFinder.java:104)

at org.testng.TestRunner.initMethods(TestRunner.java:394)
at org.testng.TestRunner.init(TestRunner.java:228)
at org.testng.TestRunner.init(TestRunner.java:198)
at org.testng.TestRunner.<init>(TestRunner.java:154)
at org.testng.remote.RemoteTestNG$1.newTestRunner(RemoteTestNG.java:139)
at
org.testng.remote.RemoteTestNG$DelegatingTestRunnerFactory.newTestRunner(RemoteTestNG.java:272)
at
org.testng.SuiteRunner$ProxyTestRunnerFactory.newTestRunner(SuiteRunner.java:542)
at org.testng.SuiteRunner.init(SuiteRunner.java:142)
at org.testng.SuiteRunner.<init>(SuiteRunner.java:106)
at org.testng.TestNG.createSuiteRunner(TestNG.java:1051)
at org.testng.TestNG.createSuiteRunners(TestNG.java:1037)
at org.testng.TestNG.runSuitesLocally(TestNG.java:877)
at org.testng.TestNG.run(TestNG.java:820)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:110)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:205)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:174)

Hi Brian,

I just pushed a new version of the Eclipse plug-in that contains the new
TestNG version.

--
Cédric

--
View this message in context: http://old.nabble.com/Error-instanciating-an-inner-class-%28eclipse-plugin-5.14%29-tp30354626p30400749.html

[Cédric Beust ♔]

I'll follow up with you privately.

-- 

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 testng...@googlegroups.com.

To unsubscribe from this group, send email to testng-users...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

--
Cédric