Anyone want to tackle trying to enable the demos to run via webstart?
Might allow people to see what jme can do easily and drum up more interest.
It took an afternoon of work (!) but I’ve created a preliminary JNLP jME test. You can find the Webstart version of TestWireframeState here. It appears to work correctly on my machine, I hope the same is true for the rest of you! Note that Linux support is currently unavailable.
I had to make some changes to LWJGLDisplaySystem to get it to work. Specifically, I had to remove the explicit library load (which is handled inside of lwjgl anyhow). I replaced it with a log of the lwjgl version being used.
When I have more time, I’ll explain what needs to be done to get the rest of the tests working with webstart.
Well, for some odd reason my home pc doesn’t have webstart installed with Java 1.4.2. So, I’m downloading 1.5 and installing it. Unfortunately, I have dial-up, yes, I live in squallor. So it’s going to take awhile.
I have no problem removing the library load. It wasn’t really needed as you said.
Thanks, Eric. I’ll see about getting the JNLP stuff set up on my server.
I notice your website uses cPanel ;). If it works like my site, you’ll need to add the “application/x-java-jnlp-file” MIME type and associate it with the “jnlp” extension. Then just tell me where on the site you’re going to stick everything, and I’ll reconfig the JNLP files. (mojomonkeycoding.com/webstart/ would be good place, I think.)
Since all the JARs need to be signed, I’ve created a keystore for Mojo Monkey Coding - registered with my info, however. It’s small, so if you want I can email it to you along with the passwords. If you create a new one, just be aware that every JAR needs to be signed with the same key.
Now to the more serious issues facing putting more demos online. The problem revolves around the way resources need to be handled. The only way to properly access a resource in a JAR is to use AClass.class.getClassLoader().getResource(“a_file_inside_the_package_structure”); This returns a URL, but none of jME’s methods are currently structured to accept URLs.
Here’s what I propose we should do:
- create a new package: com.jme.test.data where all test data should be stored. Everything in the current data/ folder should be removed from CVS.
- add URL methods for methods that previously accepted only file strings
- change all tests to use the new resource access format
- webstart the tests, and show the world! :D
[/list:u]
So ... that's that.
Sounds great Eric. But you know, I say we go even further. I think Tests should be removed from the API as it is. So, move com.jme.tests.* to test.* or something. Creating a secondary test jar that is optional for the user to download. We could then move all data there and jar it up how you like.
Does that sound reasonable?
Sounds good. I think src/test exists already. We can delete what’s there and replace it with the new tests. I think we should wait until we’ve completed the URL changes, however.
Also, would you mind adding URL support to TextureManager and the model loaders? You know them better than I, and I’m gonna be busy the next few days.
Also, would you mind adding URL support to TextureManager and the model loaders? You know them better than I, and I'm gonna be busy the next few days
yeah, I'll add them as soon as possible.
Where in the CVS tree should I place the tests? src/test is already “used” so to speak. And from what I know of CVS, you can’t delete folders to structe things the way I’d want. Maybe src/jmetest then? So then we’d have the jmetest.* package. That sounds good, actually.
(Forgive my naïveté, but is it possible to somehow blow away the entire CVS tree and start fresh with a nice, clean directory structure? And even if you can’t, can dev.java.net do it for you? It’d be nice clean things out.)
Unfortunately, you can only destroy directorys locally on the cvs server. I can ask if they can do it for me. I’ll let you know what they say. I agree, it’s a complete mess right now.
Place the tests where ever you deem best. I have no preference.
Okay then. I’ll hold off on adding that directory until you get word back from dev.java.net. Let’s hope they’re feeling nice! 
No reply from the dev.java.net folks. But I assume they are busy. So, anyways, I’m getting my server set up to support the demos. I’ll create the webstart directory so we should be able to just “dump” them to that directory.
jmetest.* is also fine with me. With luck, I’ll be able to get them to wipe CVS and we can upload a clean version. But let’s assume that it’s going to take a long time for that to happen.
Finished MD2 so I’ll start supporting your need for URLs. I’ll get those up as work allows.
Ok, before I start with the URL, let me know exactly what you need, what you expect, etc. I want to make sure we are on the same page with this, and you are leading this effort, so I’ll defer to you.
Thanks for helping me with this. So: consider all the loader methods that currently accept a String to point to a file. TextureManager.loadTexture(String, int, int, boolean) is a prime example. I would like overloaded methods that also accept a URL pointing to a file instead of a String. Using my previous example, we’d now have a method that looks like TextureManager.loadTexture(URL, int, int, boolean). Also, if you need to create a URL at anypoint, just ignore the MalformedURLException. No sense in passing it on to the user.
After this, I’ll start migrating tests to the new format. A request: all new tests should now be written using AClass.class.getClassLoader().getResource(“res”); It’ll save me from having to change it after. 
Ok, gotcha. I’ll try to get that done soon. Shouldn’t take too long.
Ok, texture images support URLs and it’s in CVS. Models next…
Website now supports JNLP, directory is up “webstart” to hold the files. So all the infrastructure is in place.
The support for the models is proving a little bit more difficult to support URL due to them referencing textures. But I’ll get them taken care of soon.
Could you try something for me? I can’t seem to get it working on my server, and I’m wondering if it’s merely my configuration.
In the /webstart directory, could you create a .htaccess file with the following entry?
<Files jmedemo>
ForceType application/x-httpd-php
</Files>
Then go and create a php file "jmedemo" without the .php extension.
Inside it, put
<?php
$nav = $_SERVER["REQUEST_URI"];
$script = $_SERVER["SCRIPT_NAME"];
$nav = ereg_replace("^$script", "", $nav);
echo $nav;
?>
First, try if going to www.mojomonkeycoding.com/webstart/jmedemo works. Then check if going to www.mojomonkeycoding.com/webstart/jmedemo/inputval shows "inputval". Thanks!
(If it works, I'll have an elegant way of using only one JNLP file to run all the demos. If it doesn't work, I can still get away with one file, but the syntax won't be as nice. Alternatively, if you have mod_rewrite installed, I could also work a fairly elegant solution for serving the demos. Whatever the situation, I can get something nice working.)
Ok, created the two files. Seems to work. I left them there for you.
I’m glad someone knows about web development… this is muddy territory for me.
Excellent. I’m really glad that it works. Now we’ll be able to serve the demos using URLs like “jmedemo/effects.TestParticleSystem”. It also means all we need to do to add a new demo is simply update the demo JAR, and the PHP script will take care of the rest. (Well, excluding, of course, actually linking to the demo. )
As soon as I can find the time, I’ll finish the PHP script and update the JNLP file. I’ve already moved the tests to jmetest.* on my local copy, so once I’m done with making the URL changes I’ll upload to CVS. I think I’ll also create a separate build.xml for the demos as well.
Sounds good. I haven’t had a chance to get the models url loading working yet, but I’ll get to it soon.