Mac OS X + Eclipse + TestNG 5.13.0.3 plug-in == Show Stopper

[ngsunw]

Hi all,

Just upgraded MyEclipseIDE today from 8.5 to 8.6 and along with the
upgrade updated TestNG Plug-in to 5.13.0.3 and I get the following
exception (full stack trace below):

>>>> Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file <<<<

So here's the story:

1) The above line tells me that the 5.13.0.3 plug-in has been compiled
with EITHER:

a) Requiring JDK 1.6 and as such class compatibility level set to 1.6
OR
b) Has for some other reason been compiled with class compatibility
level set to 1.6

2) The problem is that although Eclipse on Mac OS X can run 1.6
Applications it can not be hosted on 1.6 because 1.6 on Mac OS X is
STRICTLY 64-bit and MyEclipse (Eclipse) requires a 32-bit JVM.

SO there does NOT appear to be a viable workaround EXCEPT perhaps if
1b) has occurred and 1a) is NOT the case then to compile say a test
version with 1.5 compatibility.

At this point TestNG on MyEclipse (Eclipse) on Mac OS X is
unusable... .

Thoughts anyone? Cedric?

--Nikolaos


Environment: Mac 10.5.X (Leopard), MyEclipse (Eclipse) Java 1.5.0_24
VM, also installed on system JDK 1.6.0_20 (64-bit)

Error logged from Debug UI:

eclipse.buildId=unknown
java.version=1.5.0_24
BootLoader constants: OS=macosx, ARCH=x86, WS=carbon, NL=en_CA

org.eclipse.core.runtime.CoreException: Plug-in org.testng.eclipse was
unable to load class org.testng.eclipse.launch.TestNGLaunchShortcut.
at
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.throwException(RegistryStrategyOSGI.java:
180)
at
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:
164)
at
org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:
874)
at
org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:
243)
at
org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:
51)
at
org.eclipse.debug.internal.ui.launchConfigurations.LaunchShortcutExtension.getDelegate(LaunchShortcutExtension.java:
410)
at
org.eclipse.debug.internal.ui.launchConfigurations.LaunchShortcutExtension.launch(LaunchShortcutExtension.java:
432)
at
org.eclipse.debug.internal.ui.actions.LaunchShortcutAction.run(LaunchShortcutAction.java:
73)
at
org.eclipse.debug.internal.ui.actions.LaunchShortcutAction.runWithEvent(LaunchShortcutAction.java:
121)
at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:
584)
at org.eclipse.jface.action.ActionContributionItem.access
$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem
$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1598)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1622)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1607)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1396)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:
3484)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3068)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:
2405)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:
332)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:
493)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:
149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:
113)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:
194)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:
110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:
79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:
368)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:
179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
Caused by: java.lang.UnsupportedClassVersionError: Bad version number
in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:676)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:
183)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:
576)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:
546)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:
477)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:
465)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:
445)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:
211)
at
org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:
381)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:
457)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:
410)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:
398)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:
105)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at
org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:
326)
at
org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:
231)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:
1193)
at
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:
160)
... 37 more

[Cédric Beust ♔]

I'll recompile the plug-in with 1.5 and I'll post it on the update site.

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

[ngsunw]

I had always heard that (as someone quite clearly put it):

"Eclipse is built against Carbon (re: not Cocoa) and will only operate
under a 32-bit JVM. On OS X, Java 6 is 64-bit only and therefore
Eclipse cannot run under Java 6 until 64-bit SWT framework for Mac OS
X is in place."

However I just read (in a recent forum):

"Eclipse *does* now support Java 1.6, 64-bit, and cocoa on OS X. Cocoa
builds have been available for over a year now, and since 3.5 they are
production. So just grab the cocoa 32 or 64 (preferred) builds form
download.eclipse.org and you're golden."

I tried getting MyEclipse 8.6 to run on Mac OS X 1.6 however it would
instantly crash with EXIT 1 error code.

I am going to see what I can do with that however the easiest - if
possible - solution would be to get the TestNG plugin compiled with
source compatibility set to 1.5 - albeit I know that may not be
possible.

--Nikolaos

[ngsunw]

Cedric,

Awesome!!! What would the version be?

--Nikolaos

P.S. I just noticed your reply but posted previously....

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

[Cédric Beust ♔]

On Wed, Aug 11, 2010 at 4:31 PM, ngsunw <ngs...@gmail.com> wrote:

I am going to see what I can do with that however the easiest - if
possible - solution would be to get the TestNG plugin compiled with
source compatibility set to 1.5 - albeit I know that may not be
possible.

I'm pretty sure it is, I might have to remove a few @Override but that's it. Stay tuned.

--
Cédric

[Cédric Beust ♔]

2010/8/11 Cédric Beust ♔ <ced...@beust.com>

Done, please update your plug-in and let me know.

--
Cédric

[ngsunw]

Cedric,

The exception has not changed. Still complains about bad version.

So I decided to check the version of the plugin you uploaded i.e.
version 5.13.0.4

I did the following:
cd /Library/Genuitec/Common/plugins/org.testng.eclipse_5.13.0.4/
mkdir tmp
cp eclipse-testng.jar tmp/.
cd tmp
unzip eclipse-testng.jar
file org/testng/eclipse/TestNGPlugin.class
org/testng/eclipse/TestNGPlugin.class: compiled Java class data,
version 50.0

Version 50 unfortunately corresponds to JDK 1.6. For 1.5 the version
should be 49.

So it appears the JAR is still compiled with a minimum compliance
level (or in other words a 'target') of 1.6 NOT 1.5.

Here's a good link and a test program (though I didn't try it) on JDK
compliance versions and verifying them:
http://www.rgagnon.com/javadetails/java-0544.html

Can you try again?

--Nikolaos

[Cédric Beust ♔]

Ok, I just pushed 5.13.0.6 and I verified that this time, the classes have the 49 version. Please update.

What's really weird is that the plug-in was compiled with javac 1.5 (I verified this) but when I ask the update site to assemble all the features, it just ignores the existing class files and it rebuilds then all itself (apparently using an ant script that I wasn't able to locate). And when it does that, it uses javac 1.6.

I couldn't find any way to configure this so I ended up changing my global Eclipse setting back to javac 1.5.

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

[ngsunw]

You are the man!!! Although the issue appeared to be quite obvious I
SINCERELY appreciate how quickly you turned this around.

I am still pursuing how to install MyEclipse (Eclipse) 8.6 on 1.6 as
their appear to be significant performance benefits however until then
I am happy to see that TestNG can continue to work on the Mac OS X
platform... until then.

Much Appreciated!!!

--Nikolaos

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

[Cédric Beust ♔]

On Thu, Aug 12, 2010 at 12:00 PM, ngsunw <ngs...@gmail.com> wrote:

You are the man!!!  Although the issue appeared to be quite obvious I
SINCERELY appreciate how quickly you turned this around.

You are welcome, I broke the plug-in, the least I could was to fix it as soon as possible.

Thanks for being patient.

--
Cédric

[ngsunw]

Cedric,

No problem. Regardless its much appreciated.

Though something else appears broken and it has to do with the DTD.
Test-Failed.xml reports the following:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="Failed suite [ui-web]" thread-count="5" verbose="2"
annotations="JDK" parallel="false" data-provider-thread-count="10"
junit="false" configfailurepolicy="skip"
skipfailedinvocationcounts="false">
<test name="ContentTests(failed)" junit="false" parallel="false"
annotations="JDK">
<groups>
<run>

It has errors showing for "configfailurepolicy" and
"skipfailedinvocationcounts".

Any ideas... normally it wouldn't bother me except our projects are
large and Eclipse percolates all errors so it isn't immediately
obvious when there is a red X on the project that it is related to
this vs. a real problem in the code... i.e. it just throws you off a
bit... especially during large refactorings.

Should we start a new thread?

Ideas on resolving?

--Nikolaos

[Cédric Beust ♔]

These attributes are new, and while I notice that I updated the local DTD:

<!ATTLIST suite
    name CDATA #REQUIRED
    junit (true | false) "false"
    verbose CDATA #IMPLIED
    parallel (false | methods | tests | classes) "false"
    configfailurepolicy (skip | continue) "skip"
    thread-count CDATA "5"
    annotations CDATA #IMPLIED
    time-out CDATA #IMPLIED
    skipfailedinvocationcounts (true | false) "false"
    data-provider-thread-count CDATA "10"
    object-factory CDATA #IMPLIED
>

I did not update the file on my web site. The fix is simple (I'll update the DTD on the web site), however, the fact that you are getting the error indicates that the resolver can't find the local DTD, so it goes to my web site all the time, which might slow down your builds. You might want to look into that.

I just updated the DTD on the web site, please confirm you no longer see this error.

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

[ngsunw]

Cedric,

Problem solved.

As far as tools go they are a lot smarter (or perhaps not as smart as
we would like) as I didn't see your fix until I removed the DTD in the
tools cache which allowed it to re-download and cache your fixed
version. I think updates are periodic but definitely cached. But we
have been through this before... .

In any event Thanks for the fixes... all appears well.

ASIDE: You might want to consider having the remote DTD update tied
to some build process - conditional obviously on success but also on
it having changed over its previous last good version. That way you
don't keep getting bitten by local DTD changes - though I guess there
are enough users using TestNG that you find out pretty fast that the
remote DTD didn't get updated ;-)

In any event all appears well. Many Thanks.

--Nikolaos

On Aug 12, 5:45 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
> These attributes are new, and while I notice that I updated the local DTD:
>
> <!ATTLIST suite
>     name CDATA #REQUIRED
>     junit (true | false) "false"
>     verbose CDATA #IMPLIED
>     parallel (false | methods | tests | classes) "false"

> *    configfailurepolicy (skip | continue) "skip"
> *    thread-count CDATA "5"

>     annotations CDATA #IMPLIED
>     time-out CDATA #IMPLIED

> *    skipfailedinvocationcounts (true | false) "false"
> *    data-provider-thread-count CDATA "10"

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