my code works nicely when I run it on SDK
Clean & build shows no error
but after i try to open the .jar file, it crash immediately
the problem lies at the asset files
i’m using the .scene files which i convert from 3dsMax using Ogremax
everytime i load the file, it crash on the .jar file, but it works nice on SDK
i’m using jMonkeyEngine SDK 3.0beta
Java: 1.6.0_24; Java HotSpot™ Server VM 19.1-b02
System: Windows XP version 5.1 running on x86; Cp1252; en_US (jmonkeyplatform)
do i need to copy asset foldet to the .jar location ?
or the problem lies on my converter ?
I want to use external class, which separated from the .jar files
i’m not sure on where to put the folder of code
I run it like this
[java]
String currentDir = (new File(".").getCanonicalPath())+ “/External Code” ;
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
compiler.run(null, null, null, currentDir + “/Main.java”);
You work with java.io.Files, tere is no files when the assets are compressed to a jar file. Use the classpath and load your files from there (if you actually need to do that and can’t just use the assetManager to load the files).
As for your own files, jme apps exhibit normal java behavior, so your execution path is the main jar folder. But on modern OSs you most definitely can’t write to that folder but have to acquire some “user data” path, e.g. the user.home variable.
i realized my problem, its because i don’t use the .j3o file
when JME build the project, all files on assets folder compressed into a jar file (assets.jar) right ?
then if my assets folder is empty, is it okay to delete the “assets.jar” file ?
and this just hit me right now,
if you could guide me, on how to load a j3o file and convert it into spatial without using assetManager ?
I tried to run external code from the root directory in the SDK
it run as nice and smooth
but again when i tried to execute the .jar files, it won’t work
any idea about this ?
note : the code above are the only code in my src file.
the rest are in the “External Code” folder.
Assets get packed into the jar file, yes. Unless you reconfigure things in a very nonstandard fashion.
You can indeed delete jars without content. In terms of loadable resources, an empty jar is equivalent to a nonexistent one, yes.
However, unless you know what the asset manager is doing and decide you don’t need it, don’t move to an alternate resource loading schema.
What’s your reasons to avoid the asset manager?
Most of the standard reasons don’t work out, but we don’t know what yours are.
BTW the same question goes for why you’re trying to compile Java from source at runtime.
You’re either doing something very smart here, or something very dumb
why avoid using assetManager ?
assetManager load asset from the assets folder, means it would be compressed into jar file
in case sometime in the future i want to update several asset files, i don’t need to upload all the asset files, just the one i want to update by replacing it with the new one
it will be okay if the file size is small, but if it’s too large, it would be a pain to upload it :’(
of course if there is a way to load asset file from another folder and I could still use assetManager there, I would like to know it :mrgreen:
same goes for the runtime compile
in case i want to update some class, i don’t need to upload the jar file, just several ones which i need
if i put all my code in src folder, when I build it would be one jar file
oh and yes, I think about it too, either I’m very smart or I’m very dumb on choosing this way for my project right now XD
but even if i don’t use this, i’m still willing to learn about it, might be useful someday :mrgreen:
<cite>@Tensouha said:</cite>
why avoid using assetManager ?
assetManager load asset from the assets folder, means it would be compressed into jar file
in case sometime in the future i want to update several asset files, i don't need to upload all the asset files, just the one i want to update by replacing it with the new one
it will be okay if the file size is small, but if it's too large, it would be a pain to upload it :'(
of course if there is a way to load asset file from another folder and I could still use assetManager there, I would like to know it :mrgreen:
same goes for the runtime compile
in case i want to update some class, i don’t need to upload the jar file, just several ones which i need
if i put all my code in src folder, when I build it would be one jar file
oh and yes, I think about it too, either I’m very smart or I’m very dumb on choosing this way for my project right now XD
but even if i don’t use this, i’m still willing to learn about it, might be useful someday :mrgreen:
A jar file is basically just a zip file, which means you can modify it’s contents aswell, you don’t have to recreate it completely.
Hm… well, you can always split up the jar file into a separate jar per asset if you wish.
Umm… okay, you could also distribute the asset directory as it is and put it into the class path, that should work, too. However, you’re making it very easy for people to replace the distributed files with their own; this may or may not be what you want. (Usually you do not want that because people are better at messing up the software and come running to you with complaints, than at getting it done in a way that works.)
On sources: That’s indeed a dumb idea. If you want replaceable code, simply distribute the .class files.
Using the compiler at runtime is going to be horribly inefficient, and if any user modifies these files, they’ll just get compiler errors. If you don’t report the errors, the software will silently fail; if you do report errors, users will see warnings and come and ask whether they should be worried (and if you say “no don’t worry”, some won’t believe you anyway).
Again, doing a replace inside the .jar is doable as well. You’ll want to use existing libraries for that kind of distribution process.
In general, I wouldn’t worry about partial updates though. There are readymade libraries that will take an old and a new jar, compute the differences and pack them into an update bundle; the client software can unpack that and update the jars in place.
In other words, don’t worry about that now, you can afford to postpone that until you see that the updates are getting painful.
