Note about recent SWT support

archive development-discussion-jme2
1

jME 2.0 note:



I've recently redone Canvas support to be more abstract and allow for different types of jME enabled canvases to be created.  One thing this means is that you don't need to include jme-awt.jar for jme apps anymore unless you are actually using it.  The other thing added is an SWT implementation of the canvas system.  Credit goes to the jme-swt guys for the some of the base code used, particularly in the input classes.





FOR ANY MAC USERS OUT THERE:



That's all good news… now the bad.  SWT will cause issues on some macs.  If you are on a newer mac (I believe any running 10.5.X), the SWT-carbon stuff will not run and even having it in your jme classpath can break non-swt jme stuff you are trying to run.  Basically, you'll see this on your console:


2008-07-19 18:14:48.689 java[7031:10b] [Java CocoaComponent compatibility mode]: Enabled
2008-07-19 18:14:48.690 java[7031:10b] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.100000
2008-07-19 18:14:49.633 java[7031:12503] *** -[NSConditionLock unlock]: lock (<NSConditionLock: 0x122702f80> '(null)') unlocked when not locked
2008-07-19 18:14:49.633 java[7031:12503] *** Break on _NSLockError() to debug.


It's crazy that this happens even when nothing is referencing swt... :(  For now, I suggest leaving swt.jar out of your classpath if you get the above issue and ignore the compile errors in com.jmex.swt.  I know that is not ideal...  Other projects integrating with SWT have the same problem (Xith for example).  Fortunately, folks at eclipse and elsewhere are working on a Cocoa version that will be both 32 and 64bit compliant.

EDIT: Having the mac carbon jar in there was causing mac devs pain as mentioned above.  Sorry!  I've made empty versions of all the classes, interfaces and methods that we currently touch in swt and jarred that up into a swt_fake.jar file you can now find in /lib/swt/macosx-cocoa.  The old carbon swt is now in macosx-carbon for those on older macs.  Let me know if there are any further issues.  I will post the source for the empty swt implementation on my blog if anyone needs it.
2

That's great!



Funny enough I started today to look in the canvas stuff. Is there a more basic example out there than RenParticleEditor? Something like a resizable JFrame (or SWTFrame) with a spinning monkey cube  :smiley:

3

JMESwingTest and JMESWTTest could be what you want.

4

Thank you, that's better  XD



BTW: I have no clue regarding maven, but it seems maven can't build any longer because the SWT reference is missing in mvn-lib-install…

5

After manual installation of swt in maven, it seems to build, but now a test fails (maybe from moving classes?):



Running jmetest.util.JMESWTTest

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.016 sec <<< FAILURE!






6

Yeah, it's because it ends in Test.  JMESwingTest would have the same issue but it's specifically ignored as I understand it.  We should clean our tests and junit stuff up.

7

That's really good news. We will use this as soon as possible in our work.

8

Since the SWT libraries are OS-specific, I'd suggest adding a profiles section that uses the system architecture and family to determine which version of the SWT library to include as a dependency.  I've added the following to my pom.xml.


    <!-- Eclipse OS-specific dependencies -->
    <profiles>
        <profile>
            <id>linux-x86</id>
            <activation>
                <os>
                    <arch>i386</arch>
                    <family>unix</family>
                    <name>linux</name>
                </os>
            </activation>
            <dependencies>
                <dependency>
                    <groupId>org.eclipse.swt.gtk.linux</groupId>
                    <artifactId>x86</artifactId>
                    <version>[3.2.0,4.0.0)</version>
                </dependency>
            </dependencies>
        </profile>
        <profile>
            <id>linux-x86_64</id>
            <activation>
                <os>
                    <arch>amd64</arch>
                    <family>unix</family>
                    <name>linux</name>
                </os>
            </activation>
            <dependencies>
                <dependency>
                    <groupId>org.eclipse.swt.gtk.linux</groupId>
                    <artifactId>x86_64</artifactId>
                    <version>[3.2.0,4.0.0)</version>
                </dependency>
            </dependencies>
        </profile>
        <profile>
            <id>solaris-sparc</id>
            <activation>
                <os>
                    <arch>sparc</arch>
                    <family>unix</family>
                    <name>SunOS</name>
                </os>
            </activation>
            <dependencies>
                <dependency>
                    <groupId>org.eclipse.swt.gtk.solaris</groupId>
                    <artifactId>sparc</artifactId>
                    <version>[3.2.0,4.0.0)</version>
                </dependency>
            </dependencies>
        </profile>
        <profile>
            <id>macosx</id>
            <activation>
                <os>
                    <family>unix</family>
                    <name>mac os x</name>
                </os>
            </activation>
            <dependencies>
                <dependency>
                    <groupId>org.eclipse.swt.carbon</groupId>
                    <artifactId>macosx</artifactId>
                    <version>[3.2.0,4.0.0)</version>
                </dependency>
            </dependencies>
        </profile>
        <profile>
            <id>win32</id>
            <activation>
                <os>
                    <arch>x86</arch>
                    <family>windows</family>
                </os>
            </activation>
            <dependencies>
                <dependency>
                    <groupId>org.eclipse.swt.win32.win32</groupId>
                    <artifactId>x86</artifactId>
                    <version>[3.2.0,4.0.0)</version>
                </dependency>
            </dependencies>
        </profile>
        <profile>
            <id>win64</id>
            <activation>
                <os>
                    <arch>amd64</arch>
                    <family>windows</family>
                </os>
            </activation>
            <dependencies>
                <dependency>
                    <groupId>org.eclipse.swt.win32.win32</groupId>
                    <artifactId>x86_64</artifactId>
                    <version>[3.2.0,4.0.0)</version>
                </dependency>
            </dependencies>
        </profile>
    </profiles>

9

I'd suggest moving "jmetest", since a lot of the Maven testing (and reporting) issues with the 2.x code-base are a result of placing both production source and test source in the same directory.  Although you can explicitly provide expressions to include and exclude source code and resources, the system works best when these are placed in separate directories.



This current configuration is causing the following problems:


  • Maven is included everything from "src" when compiling test code, meaning that classes like AnimationController exist in two different class paths:

      [li]./bin/classes/com/jme/animation/AnimationController.class
    • ./bin/test-classes/com/jme/animation/AnimationController.class


    [/li]
  • "mvn eclipse" doesn't generate the correct Eclipse configuration, since the resulting ".classpath" configuration only compiles "src" to "bin/classes".  This means that mixing Eclipse and command-line Maven results in strange errors.  Imagine AnimationClass was built using "mvn compile", but then the file was edited through Eclipse.  This would result in an updated version compiled to "bin/classes" and the original version in "bin/test-classes".  Rerunning the command-line wouldn't fix the problem since the version in "bin/classes" would have a timestamp after the source files.  The only fix would be to clean everything, something I've had to do when developing.

  • Creating JavaDoc reports actually documents the source code twice; once as production source and once as test source.  Other reports are also duplicated.



The simplest solution would be to simply move "src/jmetest" to another location (perhaps simply "jmetest"?).  This will eliminate the need to include or exclude code and resources from the production source tree.
10

I wonder if moving jmetest would result in a lot of newcomers unable to find the example code…

11

It sounds like you are concerned that developers will simply grab the codebase and look in the src directory.  The same concern would apply to the existing junit directory.  Perhaps we could merge both junit and jmetest into a single directory, and name the directory to highlight its purpose.  An example might be "test-src".



Another option might be to address your concern by looking at ways to automate a developer's configuration.


  • Ant - Command-line Ant execution would be addressed by making appropriate updates to the build.xml file.

  • Maven - Command-line Maven execution would be addressed by making appropriate updates to the pom.xml file.

  • IDE (with Maven) - There are several options for both Eclipse and Netbeans that work with Maven and the pom.xml file.  As an example, I used mvn eclipse:eclipse to generate my current Eclipse project.

  • IDE (with Ant) - I'm personally less familiar with this this type of configuration, but I know that it is possible.


12

Woody, I think you misunderstand the purpose of the jmetest directory. The test cases in there are not unit tests, but rather usage examples of the jME classes.

As such, the jmetest package is not even meant to be included in automated testing.

13

I know that the code is used for demonstration purposes on the web site.  I understand that they aren't unit tests in the JUnit sense of automated regression tests.  However, the code is not part of the packaged production codebase that is used when delivering a game.  Looking at the Ant build scripts supports this view, in the following ways:


  • Executing ant dist-all does not build a jar which includes any classes from jmetest.

  • The jmetest classes are compiled as part of the Ant target compile-test.

  • The jar jmetest.jar is built as part of the Ant target dist-test.



"test-src" was just a suggestion.  I'd be just as open to a third location, such as "demo-src".  I think the more important issue, is the impact that the current location has upon certain development environments.  Moving jmetest out of the production source tree to address this is really my goal.

I've personally used the code as a test platform for parts of the system while working on the JOGL development, which is probably why I feel comfortable thinking of it as part of the test system.
14
Woody said:

It sounds like you are concerned that developers will simply grab the codebase and look in the src directory.  The same concern would apply to the existing junit directory.  Perhaps we could merge both junit and jmetest into a single directory, and name the directory to highlight its purpose.  An example might be "test-src".

Another option might be to address your concern by looking at ways to automate a developer's configuration.

  • Ant - Command-line Ant execution would be addressed by making appropriate updates to the build.xml file.

  • Maven - Command-line Maven execution would be addressed by making appropriate updates to the pom.xml file.

  • IDE (with Maven) - There are several options for both Eclipse and Netbeans that work with Maven and the pom.xml file.  As an example, I used mvn eclipse:eclipse to generate my current Eclipse project.

  • IDE (with Ant) - I'm personally less familiar with this this type of configuration, but I know that it is possible.




Yeah, the reason I see it as an "issue" for new devs is mostly because in eclipse, the defaults will grab source from a "src" folder in the root of your project, so it flows in nicely.  We could always check in a .project file though (and perhaps the equivalent on the NB side)  We had good success at NC with just doing that.
15

Actually Eclipse will pick up more than just a directory named src.  It searches for all Java source code.  I just ran a simple test where I created the following directory structure, and then asked Eclipse to create a new Java Project.  Both src and test were correctly identified as source source code directories…


test
test/src/Foo.java
test/test/bar/Bar.java



Class Foo:

public class Foo {
}



Class Bar:

package bar;

public class Bar {
}

16

Note: see main post for some edits about mac support.

17

Hey everyone.



I'm a returning user. I used 1.0 and now i find we are at 2.0, Fantastic, however…



I am a mac user. I have installed jme 2.0 using SVN added the jars to the build path added the cocoa jar and referenced the native libraries.



This did not work so I tried it out with the carbon one, then i read the posts above and tried it out with the swt jars removed completely. I cannot get anything to build without errors.



It's been a while since I did any coding and I'm pulling my hair out over this. Can anyone suggest anything to get jme running?



Thanks in advance,



Alan

18

hmm, using a MAC here too with no problemos.



What IDE?



(Also, the Cocoa one is just a dummy jar…)

19
renanse said:

jME 2.0 note:

FOR ANY MAC USERS OUT THERE:

That's all good news... now the bad.  SWT will cause issues on some macs.  If you are on a newer mac (I believe any running 10.5.X), the SWT-carbon stuff will not run and even having it in your jme classpath can break non-swt jme stuff you are trying to run.  Basically, you'll see this on your console:

It's crazy that this happens even when nothing is referencing swt... :(  For now, I suggest leaving swt.jar out of your classpath if you get the above issue and ignore the compile errors in com.jmex.swt.  I know that is not ideal...  Other projects integrating with SWT have the same problem (Xith for example).  Fortunately, folks at eclipse and elsewhere are working on a Cocoa version that will be both 32 and 64bit compliant.

EDIT: Having the mac carbon jar in there was causing mac devs pain as mentioned above.  Sorry!  I've made empty versions of all the classes, interfaces and methods that we currently touch in swt and jarred that up into a swt_fake.jar file you can now find in /lib/swt/macosx-cocoa.  The old carbon swt is now in macosx-carbon for those on older macs.  Let me know if there are any further issues.  I will post the source for the empty swt implementation on my blog if anyone needs it.


Hi, I'm new to jME and using a Mac for development. It seems like the
latest build - jME_2.0_Complete_(r4093) - is still suffering from this
problem. I'm not familiar with SWT and it sounds like it is a 32/64-bit
problem with Eclipse's SWT? Are there any progress (it is now May 09)
on this front so far? Removing swt.jar from my build path is making it
really painful for development.

Thanks in advance..
20
rexguo said:


Hi, I'm new to jME and using a Mac for development. It seems like the
latest build - jME_2.0_Complete_(r4093) - is still suffering from this
problem. I'm not familiar with SWT and it sounds like it is a 32/64-bit
problem with Eclipse's SWT? Are there any progress (it is now May 09)
on this front so far? Removing swt.jar from my build path is making it
really painful for development.

Thanks in advance..


OK, I just did some research and can answer my own question.
The new Cocoa SWT will be released together with Eclipse 3.5.
Eclipse 3.5 is scheduled to be released on 24th June according
to the published project plan:

http://www.eclipse.org/projects/project-plan.php?projectid=eclipse


M1 08/08/2008
3.5M1
M2 09/19/2008
3.5M2
M3 10/31/2008
3.5M3
M4 12/12/2008
3.5M4
M5 01/30/2009
3.5M5
M6 03/13/2009
3.5M6 (API Freeze)
M7 05/01/2009
3.5M7 (Feature Freeze)

Our target is to complete 3.5 in late June 2009, in alignment with Galileo.