Windows EXE Creation: Error?

Windows EXE Creation
/Users/Brainversation/Coding/Jmonkey/TeamAwesome/BlockBlock/BlockBlock/nbproject/launch4j-impl.xml:7: Warning: Could not find file /Users/Brainversation/Coding/Jmonkey/TeamAwesome/BlockBlock/BlockBlock/resources/launch4j/winapp-config.xml to copy.
BUILD FAILED (total time: 3 seconds)

The file is there but it can not find it?

Getting the same thing here. Is there a way to regenerate the whole directory structure or whatever? The only file left there is win-icon.ico.

Well, I think the SDK install just went the way of the dodo.

Hell has broken loose and all that jazz.

After fighting the system for a bit after getting the error above and the other GUI error, I decided to update Windows, walk away from the computer for some hours and fix things… Problem is, now I’m getting the following after rebooting. Mind that I “fixed” the error I was getting in the previous post by unticking the Windows .EXE generation then reenabling it.

Now when I try to “Clean & Build” I get this:

Windows EXE Creation Copying 1 file to H:\Users\Dany\Documents\jMonkeyProjects\Disenthral Compiling resources Generated resource file...

LANGUAGE 0, 1
2 RCDATA BEGIN “1.5.0” END
18 RCDATA BEGIN “1” END
12 RCDATA BEGIN “-Xmx1024m -Dorg.lwjgl.opengl.Window.undecorated=false -Xnoagent” END
1 ICON DISCARDABLE “H:\Users\Dany\Documents\jMonkeyProjects\Disenthral\resources\launch4j\win-icon.ico”
10 RCDATA BEGIN “Disenthral” END
21 RCDATA BEGIN “http://java.com/download” END
8 RCDATA BEGIN “.” END
20 RCDATA BEGIN “32” END
9 RCDATA BEGIN “true” END
101 RCDATA BEGIN “An error occurred while starting the application.” END
102 RCDATA BEGIN “This application was configured to use a bundled Java Runtime Environment but the runtime is missing or corrupted.” END
103 RCDATA BEGIN “This application requires a Java Runtime Environment” END
104 RCDATA BEGIN “The registry refers to a nonexistent Java Runtime Environment installation or the runtime is corrupted.” END
105 RCDATA BEGIN “An application instance is already running.” END
23 RCDATA BEGIN “com.madjack.games.disenthral.Disenthral” END
24 RCDATA BEGIN “Disenthral” END
17 RCDATA BEGIN “true” END

H:\Users\Dany\Documents\jMonkeyProjects\Disenthral\nbproject\launch4j-impl.xml:16:
net.sf.launch4j.BuilderException: net.sf.launch4j.ExecException: java.io.IOException: Cannot run program “H:\Users\Dany\Documents\jMonkeyProjects\Disenthral\lib\launch4j-3\bin\bin-windows\windres.exe”: CreateProcess error=2, The system cannot find the file specified
at net.sf.launch4j.Builder.build(Builder.java:144)
at net.sf.launch4j.ant.Launch4jTask.execute(Launch4jTask.java:111)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor258.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:392)
at org.apache.tools.ant.Target.performTasks(Target.java:413)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:283)
at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:541)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
Caused by: net.sf.launch4j.ExecException: java.io.IOException: Cannot run program “H:\Users\Dany\Documents\jMonkeyProjects\Disenthral\lib\launch4j-3\bin\bin-windows\windres.exe”: CreateProcess error=2, The system cannot find the file specified
at net.sf.launch4j.Util.exec(Util.java:152)
at net.sf.launch4j.Cmd.exec(Builder.java:212)
at net.sf.launch4j.Builder.build(Builder.java:97)
… 16 more
Caused by: java.io.IOException: Cannot run program “H:\Users\Dany\Documents\jMonkeyProjects\Disenthral\lib\launch4j-3\bin\bin-windows\windres.exe”: CreateProcess error=2, The system cannot find the file specified
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
at java.lang.Runtime.exec(Runtime.java:615)
at java.lang.Runtime.exec(Runtime.java:483)
at net.sf.launch4j.Util.exec(Util.java:117)
… 18 more
Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.(ProcessImpl.java:188)
at java.lang.ProcessImpl.start(ProcessImpl.java:132)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1021)
… 21 more
BUILD FAILED (total time: 31 seconds)

FYI this JUST started happening. Before I started getting the above (XML file missing) I was running/debugging frequently without a single issue. Then BAM this started.

I think the only alternative is to reinstall the whole thing. And do I hate reinstalling shit. -.-

Suggestion & ideas welcome.

Yo madjack!

Was able to faithfully recreate your bug on a Windows EXE build! er… yay?

Anyhoo, I messed with the project -> properties -> Libraries -> Libraries Folder -> Browse button
there’s a “wizard” there that magically alters … stuff.
if you try to make a windows executable after that… well, you have your bug.

So, Something is dropping out with Ant and launch4j when “default” stuff is being overwritten… :0

Heads up Dev Team!

Other oddities I’ve noticed, but they don’t seem serious…
Included JRE is 7 - works just fine, so far
Encoding standard target for java files is set to utf-8 when Java 7 seems to want utf-16 as of Unicode 4.0 - again just fine for me, Windows is still (windows)utf-8 based
Project standard target is 5 - seems to work just fine
Ant standard target for EXE deployment is “1.5” - I’m guessing its set for Java 5

That’s about it. Hope it helps the Dev Team. I’m too much of a newbie in Java/Ant/jMonkeyEngine architecture to actually be able to suggest solutions for this problem.

Game On…

Looks like botched user rights. Like you executed some app “as admin” or moved/created folders in another account.

Yo Normen!

Hello again! It’s definitely possible to me at this point. You will probably be needing better information from me to “see” what I am missing. Sooo, with that in mind:

[video]http://www.youtube.com/watch?v=d8Ko_fycoPM[/video]

I am totally wanting to make some cool games on this platform. I haven’t been able to find a good tutorial/specification on how ant/launch4j is supposed to work for Windows yet. What would be a good work around/ant script fix? Any help would be greatly appreciated. I would also be able to do the same for Java console apps under the JRE7. Read the tutorial I mentioned earlier.

Oh, you should not change the libraries to be loaded from a folder, then you would have to put all libraries needed (e.g. Launch4j) into that folder too. Basically its not a bug but you tell the SDK you know what you do :wink:

Cool! Thanks Normen!

I will go ahead and do research on Ant/XML/Windows/Launch4j. If you happen to have resource links available for me to absorb, I would love it. Otherwise, I’ll probably write up an article when I have found the right documentation, and clarify it for future Monkeys.

Game On…

@Relic724 said: Cool! Thanks Normen!

I will go ahead and do research on Ant/XML/Windows/Launch4j. If you happen to have resource links available for me to absorb, I would love it. Otherwise, I’ll probably write up an article when I have found the right documentation, and clarify it for future Monkeys.

Game On…

Note: If I’m reading normen’s response right, this problem was not specifically a launch4j problem but a “mess with settings that shouldn’t be changed” problem. Launch4j is just the first issue you noticed but you surely would have had other problems at some point.

Yo pspeed!

Yes, I see that. And I did, in fact. This problem first occured when I was going through an external tutorial while learning Java. I wanted to be able to write a simple console app that printed good ol’ “Hello World” - and was executable in Windows for the JRE7 installed on my computer, much like a standalone executable is naturally generated in Visual Studio for Windows. That fails immediately for export to a Windows executable. It shows a lack of knowledge on my part on how jMonkeyEngine interacts with it’s Templates and libs of Ant and Launch4j. Not a big problem, I just need to keep learning and have patience. Currently, I can’t find any information on this forum for “properly messing with settings” that -can- be changed(Yeppers, can and should are not known to a starter, like me, for a good example. LOL). Maybe I can rectify that, merely by posting my questions, and figuring out which settings -should- be changed to accomplish my goal. Again, not much documentation… yet.

So far, I know these things for Windows and jMonkeyEngine:
Somebody -can- just start up a jMonkeyEngine basic game, add w/e they like to it, test it and debug it. It is possible to export it to Windows, without knowledge of Ant and Launch4j.
Somebody -cannot- do the previous item, if they mess with the libraries tab… and do not have the knowledge to correctly adjust the Ant & Launch4j Templates properly to compensate.
Somebody -cannot- do like the first item for a Java->Java Application project, naturally, within jMonkeyEngine without the knowledge of the second item.
Do you concur?

So, yeppers, I gotta learn me some more info so that I can accomplish my goal. I think it would be cool to have a series that would let someone learn how to do Java, and then be able to take the program that they made and head over to a friend’s house, and show them on (the friend’s) PC. The next series would then introduce how to work jMonkeyEngine’s true power of Game Making… which they will definitely want to take over to their friend’s house and show off.

Game On…

The SDK itself has a help menu (F1) and in the sidebar of this webpage you find a “Documentation” menu that has an entry “SDK” too. Both contain info on how to handle the libraries in a project.

Yo Normen!

Yes, I found that information that you are referring to. It deals with the Libraries in the project view and Library inclusion just as you said. It does not cover Library storage. The “bug” is occuring if anybody messes with the libraries storage setting in the project properties dialogue window, and only applies to how jMonkey utilizes Launch4j via an Ant build script for Windows. Currently, It looks like the software does not adapt it’s Ant to Launch4j syntax correctly if the Library storage is changed. Is this a good clarification?

Right now, the best solution that I have found for a work-around is to:

  1. Uncheck the Deploy to Windows checkbox under the project properties.
  2. Download Launch4j from http://launch4j.sourceforge.net/
  3. Manually wrap the JAR from inside Launch4j’s UI.

This is one of the Obscure Bugs for which I have not found documentation, but there is a work-around to keep going, until this one is fixed. I hope I’ve been of help and, thank you for the quick response. :smiley:

correction I don’t know how to unmark a [support request] signifying that I have found my answer, is that done on the Moderator’s side? end correction

Game On…

No, the best solution is to specify the Library via the Library settings page and add it to the project without specifying a project-local lib directory. If you first enable the deployment to windows and then enable local storage of libraries the lib folder is populated as needed, if you don’t do that then you have to manage the lib folder yourself when you make changes that require other libraries as I said.

Yo Normen!

You are correct, and it can still be kerfluffled by an “uneducated” user. Thus, qualifying as an actual bug. LOL I kinda figured this from the beginning, and now know how I am “messing it up”, and why-ish. And now to break it down for the folks in this forum. To avoid, in the first place, for people not knowing the specific flavor of jMonkeyEngine. To fix, in the second place, in case they happened to actually do it, as I did. So… with that in mind.

  1. It is not necessary, nor recommended to, press the Browse button for the Libraries Folder under the Libraries Category and pass through the wizard on default. It will cause this “bug”, in the first place. And, the result of the change cannot be undone to my knowledge. EG: There is no button to press to restore back to “global/unset libraries”, your project now -requires- a directory containing the file “nblibraries.properties” <– a possible bonus fix from Developer side?

  2. If you press it (intermediate user who knows better), you can still avoid this “bug” in the wizard by selecting “use existing Libraries in Library Folder” for launch4j if you have already checked “Create Windows EXE” as a create launcher option under Project Properties->Application->Desktop. <– this is not where the actual bug is, this is one way of avoiding it.

  3. If you did not mean to press it at all, I am sorry but you cannot go back to global libraries at the time of this post… see point 1. the best solution I can offer is to delete these Launch4j lines from the nlibraries.properties file that is now set at that directory:

libs.launch4j.classpath=\ ${base}/launch4j/launch4j.jar;\ ${base}/launch4j/xstream.jar
  1. If you did mean to press it and properly move it to your library storage. And the bug is…
    go to your jmonkeyengine installation folder->jmonkeyengine->libs->
    copy these directories and their contents:
    bin, head, manifest, and <OS Specific Folder> w32api, in my case
    go to your libraries storage folder and go inside the one labeled launch4j
    paste them in alongside Launch4j.jar and xstream.jar
    Those jars now have the required files to function properly, everything runs fine

The “bug” for someone who shouldn’t do it is that they can’t undo it.
The “bug” for someone who wanted to do it is that 4 required folders and their contents are not copied for launch4j’s functionality.

So! Whew! My fingers are tired! LOL. Thank you, Normen and pspeed. I now have been able to educate myself to work around these two items. I am now up and running my executables just nicely! oh, and one other thing…

Bonus Info I learned:
default launch4j configuration for jMonkeyEngine projects is “javaw” using the guihead.o file found inside the head folder of the important 4 folders. This naturally makes for a pretty launch as that it suppresses the console side of a jMonkeyEngine Game.
This means that console-based Basic Java Application projects cannot be exported to executables. This requires the ability “somewhere” of switching the launch4j configuration to “java” using the consolehead.o file, rather than the guihead.o file. <– Another possible fix info.

also, for exported console apps or for jars created for console(java -jar “path\to\location\ConsoleApp.jar”) here’s a useful four lines of code, for Windows.

[java]import java.util.Scanner; // just below package declaration
//… other code
Scanner waitForEnter = new Scanner(System.in);
System.out.print("Press Enter to continue…);
waitForEnter.nextLine(); // right at the end of “public static void main(String Args)” block
[/java]
This keeps the console window in Windows open until the Enter key is next pressed. This replaces the Windows standard of “Press any key to continue…” to keep the console open until any key is next pressed. The default behavior for Windows is to immediately close the console/command line once execution is completed. Why keep the console window open? So that we can look at our pretty output, right?

Game On…

@Relic724 said: This keeps the console window in Windows open until the Enter key is next pressed. This replaces the Windows standard of "Press any key to continue..." to keep the console open until any key is next pressed. The default behavior for Windows is to immediately close the console/command line once execution is completed. Why keep the console window open? So that we can look at our pretty output, right?

Note: in the long run you will probably be happier with some kind of logging that can be configured to write to a file.

And for your own local testing, you need not run it as an exe anyway.

Just change the lanuch4j configuration if you want to change how the app is run, its stored in the project. If I take your definition of bug the whole windows device manager is a huge bug… i don’t know if I can agree with that.

@normen actually I agree, doing some detections only on install time, wtf is wrong with that thing?

Yo pspeed & Normen!

@Normen:

@normen said: Just change the lanuch4j configuration if you want to change how the app is run, its stored in the project. If I take your definition of bug the whole windows device manager is a huge bug.. i don't know if I can agree with that.
launch4j configuration? it's "messable withable"? Sweet! and noted! "out of the box" settings can be changed for Basic Java Application projects requiring deployment to console... and that can be found as ... (assumption) XML code somewhere in the nbproject folder of the project? and it's probably good practice(assumption) to edit the -build- file as an override, rather than the file where it's at...? Note: I'm still learning and finding solutions as I learn. This discussion is merely fleshing out my knowledge of jMonkeyEngine SDK, Thank You for your patience with me, Normen. :D oh, and bug. I think I might have forgotten my "quotes", my bad. So for further info... My official definition of a bug is when something happens in code for which neither the developer nor the end-user were expecting and neither desire, which affects the outcome of the program. See: bad-stuff happens - Life. My official definition of a "bug" (perceived bug) is when something happens in code for which either the developer or the end-user were not expecting and for which either may find undesireable. I won't hash into a perceived bug too much, I *will* toss out some analogies though. from the developer's viewpoint: Coke is made with sugar, and is dangerous according to some research group... let's introduce "new Coke" and Obsolete Coke! (and we also lost the original formula...) from the user: New Coke tastes like @#%@.... hello Pepsi from the Developer: Sales are down... Introducing Coca Cola Classic! from the user: Yeah, that tastes pretty good, but for those of us who Like Sugar.... Hello Mexican Coke! (oh so many implications on that one... XD) from the Developer: Yeah, okay that works. from Pepsi: Thank you, Coke. My sales are doing great here, too. "Throwback" anyone? from Jones Cola: Eesh! Don't forget about me! "bug" fixed... I don't percieve the windows device manager as a huge bug, either. It's been there since Win95 in the control panel as a hub for managing device drivers and files. It works great for people wanting to manage their device driver files, manually inside of windows. In another aspect of Windows, a "bug" does happen if anyone just tries to associate a .jar file with java in Windows: a screen flickers and disappears if you click it... It contained the help console message, and windows automatically closes finished console apps. the actual "bug" is that the -jar switch is missing from in front of the referred file name. It requires a customized command line reference which has been there since Win95. The deprecation of customized referring started with WinXP, as Microsoft tested out its new referral standard via GUI. I have Vista, where this is fully obsolete. So, you have to create a shortcut containing that custom command line referral. What is expected by developer/end-user in Windows GUI: "activate" an associated file, It is then referred to the associated program, which then fires up... displaying/executing the file. The "bug" in this case, is that you can't setup a situation using only windows settings to: activate a .jar file and have java run it in windows Vista. You will just get the help screen, which then closes before you can even see it. You have to console activate it, or create a shortcut to "work around". Is it Microsoft's fault for obsoleting a working custom referrer? Is it Java's fault for requiring the -jar switch in front of the file name? Is it my fault for choosing Windows Vista? Is it my fault for not knowing about some obscure registry fix for .jar file association? Eeesh... In all cases, lack of knowledge, for some unconsidered situation leads to a true bug. And "bug" fixes are the quickest way to achieve true bugs.

So, Yeppers, -I- for one will remain an end-user for jMonkeyEngine, for quite some time. I will eventually contribute to the source, when I feel I can be of assistance there. I am contributing to this forum and my own personal knowledge development, currently, by asking my questions, learning as I go, and appreciating all the help I’m getting.

Thank You, Normen

@pspeed

Note: in the long run you will probably be happier with some kind of logging that can be configured to write to a file.

And for your own local testing, you need not run it as an exe anyway.

Yeppers, on both counts.
[video]http://www.youtube.com/watch?v=iF2fSc_LGEk[/video]

correction LoL, I mis-clicked, the rest of this was supposed to all in, as well end correction
This is part of my current work in progress: Youtube - jMonkeyEngine Java Primer

@Empire Phoenix said: @normen actually I agree, doing some detections only on install time, wtf is wrong with that thing?
Oh, the Eclipse users have an opinion about NetBeans again? xD What happens is that you switch to manual library management at some point. Whatever you had set up "automagically" at that moment will be transferred. From then on its what it says on the box: "manual management".

@Relic724:
That java “-jar” example is exactly the same as the “lib” folder… If you install Java with the installer then the .jar files are associated correctly. If you decide to take things in your own hand you have to know what you do and specify the -jar option. I think you just gave another example of where our opinions on if thats a bug or not are different. I don’t think its a bug.