Recent changes to patches

Expand environment variables in classpath and jre path

2011-12-02T21:08:18Z

This patch modified jsmooth-0.9.9-7 for the .exe wrapper to expand environment variables within the classpath and the bundled JRE path at run time.

Patch for "Scanning directories for JAR files"

2010-02-07T20:56:51Z

This is a patch for tracker item #1432057
I patched the skeletons so that they use all .jar-files in each directory entry on the classpath. When the classpath entry is no directory, everything works as before. I did not patch the GUI (I don't use it for the classpath anyway because of bug #866154), so you have to edit the xml-file manually.

The attachment contains only the changed sources. I wanted to include the binaries, too, but sourceforge didn't let me, because the file was too big. So good luck compiling and linking yourself (I had quite a hard time figuring it out). Does anyone know a little overhead way of posting patched data bigger than 256k to sourceforge?

Use memory mapped I/O instead of loading entire jar into mem

2009-11-16T17:19:26Z

Use memory mapped I/O instead of loading entire jar into Java memory. This solves OutOfMemoryError when running JSmooth on Win32 with several hundred MB JAR files.

Enable a vmparameter= in .jsmooth config files

2009-10-16T13:29:20Z

Add the possibility to pass any possible java parameter to the jvm by adding a line like "vmparameter=-Xmx256m -Xmn128m".

Create x64 binaries

2009-10-16T13:25:48Z

Create 64bit binaries for all skeleton wrappers except the autodownload wrapper.
If you are interested in these binaries I can send you the sources and the compiled binaries.

Make jsmoothcmd support absolute paths inside .jsmooth files

2009-08-14T23:03:04Z

Our .jsmooth files get generated by build scripts, and paths in the files (to JDK, classpath, etc.) produced by the scripts are absolute.

When we used jsmoothgen.exe to process these generated files, it worked fine.
But when I tried jsmoothcmd.exe to do the same (and also tried the JSmooth ant task) -- it failed with error messages that JSmooth could not resolve paths to JDK and other jars.

The GUI version of JSmooth converts absolute paths to relative when it loads the model from a .jsmooth file.

So I've just added this 1 line into net.charabia.jsmoothgen.application.cmdline.CommandLine to do the same and it solved the problem (the command line JSmooth util now works OK with our files):

model.normalizePaths(basedir, true);

The modified CommandLine.java file is attached.

allow java properties without '-D'

2009-03-26T19:25:54Z

Allows you to enter a Java Property that starts with a '-' but not '-D' by entering the property (including the leading '-') in the name field on the Java Property Editor.
Some examples would be

-Xrs
-splash:splash.png

Add java system properties over the command line

2008-12-24T07:55:04Z

Pass all "-Dkey=value" parameters on the command line to the vm.
To do this replace the addUserArgument method from ResourceManager with the attached one.

JSmooth 32 bits with alpha channel icon support

2008-09-30T23:14:52Z

I use Jsmooth on Davmail, this tool is just great (single process, easy to use, ant task...).

Yet I noticed that the exe icon does not take alpha channel into account.

I wrote a small patch to add 32 bit icon to Jsmooth :
- changed icocodec to load 32 bits ico images
- created a ResIcon32 class to handle exe resource output
- also had to patch ExeCompiler and ExecutableIcon to use ImageIO to load png images and call ResIcon32 for output

Execute in Headless Mode without Exception

2006-08-03T09:12:41Z

When using JSmooth 0.9.7 in headless mode, an exception will be thrown
in line 236 of ExeCompiler.java, because a dummy JLabel instance is
created for a MediaTracker.

I simply commented out lines 236 to 243 inclusive; using the media
tracker is not necessary, at least if the .ico file is supported by the ICO
decoder contained in JSmooth (it blocks until the .ico file is read, anyway).

After making this small change and recompiling, I can now invoke
JSmooth on a headless Linux machine to build the .exe-Wrapper.