If you using eclipse, just do below:
|
Thursday, August 23, 2012
install and run an app on multiple devices with a single click under eclipse
Wednesday, August 22, 2012
Mass convert CR2 file to JPEG with Ubuntu
- apt-get install ufraw
- cd <dir of cr2>
- for i in *.CR2; do ufraw-batch $i --out-type=jpeg --output $i.jpg; done;
Thursday, August 16, 2012
Add new struts2 maven project in eclipse
1. Click File > New > Project...
2. New Project will be prompted. Choose Maven > Maven Project. Click Next.
3. New Maven Project will be prompted. Click next.
4. Choose Nexus Indexer for Catalog. highlight maven-archetype-webapp(Artifact Id) and click next.
5. Fill in the Group Id, Artifact Id, version and click Finish.
6. Set the tools.jar dependence in your pom.xml.
Add
<profiles>
<profile>
<id>default-tools.jar</id>
<activation>
<property>
<name>java.vendor</name>
<value>Sun Microsystems Inc.</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>C:/Program Files/Java/jdk1.6.0_23/lib/tools.jar</systemPath>
</dependency>
</dependencies>
</profile>
</profiles>
This will solve the Missing artifact com.sun:tools:jar:1.5.0:system problem.
7. Add strut2
There are 2 ways to do it:
a. Right click the source folder, Maven > Add Dependency. Type struts2-core. Then, highlight the org.apache.struts struts2-core and click ok.
b. Add below in pom.xml
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>2.2.1.1</version>
</dependency>
8. Add log4j and javassist dependencies.
<dependency>
<groupId>javassist</groupId>
<artifactId>javassist</artifactId>
<version>3.12.1.GA</version>
</dependency>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>2.2.1.1</version>
</dependency>
</dependencies>
** log4j is encouraged to be manually added to prevent Missing artifact log4j:log4j:bundle:1.2.16:compile
** Final pom.xml attached on below
9. Right click on the project: Run as > Maven install. This will build war file in the target folder of your project.
10. Deploy the war file.
[attached]
2. New Project will be prompted. Choose Maven > Maven Project. Click Next.
3. New Maven Project will be prompted. Click next.
4. Choose Nexus Indexer for Catalog. highlight maven-archetype-webapp(Artifact Id) and click next.
5. Fill in the Group Id, Artifact Id, version and click Finish.
6. Set the tools.jar dependence in your pom.xml.
Add
<profiles>
<profile>
<id>default-tools.jar</id>
<activation>
<property>
<name>java.vendor</name>
<value>Sun Microsystems Inc.</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>C:/Program Files/Java/jdk1.6.0_23/lib/tools.jar</systemPath>
</dependency>
</dependencies>
</profile>
</profiles>
This will solve the Missing artifact com.sun:tools:jar:1.5.0:system problem.
7. Add strut2
There are 2 ways to do it:
a. Right click the source folder, Maven > Add Dependency. Type struts2-core. Then, highlight the org.apache.struts struts2-core and click ok.
b. Add below in pom.xml
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>2.2.1.1</version>
</dependency>
8. Add log4j and javassist dependencies.
<dependency>
<groupId>javassist</groupId>
<artifactId>javassist</artifactId>
<version>3.12.1.GA</version>
</dependency>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>2.2.1.1</version>
</dependency>
</dependencies>
** log4j is encouraged to be manually added to prevent Missing artifact log4j:log4j:bundle:1.2.16:compile
** Final pom.xml attached on below
9. Right click on the project: Run as > Maven install. This will build war file in the target folder of your project.
10. Deploy the war file.
[attached]
ClassNotFoundException when Maven2 project on Tomcat 6 from with Eclipse
Start Dynamic web project with M2Eclipse, Maven2, Eclipse.
SEVERE: Servlet /CommunityWebServer threw load() exception
java.lang.ClassNotFoundException: com.cnx.community.servlet.HttpTransportServices
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1671)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1516)
Solution:
1. Delete the project from workspace.
2. Delete .project and .classpath from project folder
3. Make sure Maven Integeration for WTP (optional) is install, else install it from
http://m2eclipse.sonatype.org/sites/m2e-extras
4. Import the project again as Maven project.
End.
SEVERE: Servlet /CommunityWebServer threw load() exception
java.lang.ClassNotFoundException: com.cnx.community.servlet.HttpTransportServices
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1671)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1516)
Solution:
1. Delete the project from workspace.
2. Delete .project and .classpath from project folder
3. Make sure Maven Integeration for WTP (optional) is install, else install it from
http://m2eclipse.sonatype.org/sites/m2e-extras
4. Import the project again as Maven project.
End.
Webapps with Eclipse and Maven (maven-war-plugin)
Webapps with Eclipse and Maven (maven-war-plugin)
Web applications created by the Eclipse IDE contains an annoying folder WebContent to host the web resources and deployment descriptors. Quite natural for Eclipse users, this feature ignores the Maven convention and force the developers to hack the pom files in order to get the project up and running in Eclipse. In this aspect, Eclipse if far behind the other IDEs regarding Maven support, even if you consider the very good M2Eclipse plugin. So, for you lazy Christmas hackers, here it is a solution for the Maven integration problems in Eclipse based on the maven-war-plugin.
ERRATA: please use the WTP plugin instead of changing the project structure. I figured out the wtp plugin after writting this blog, so I suggest you to check just the 1st and the 3th steps of the below instructions. I kept the original blog information in case you really need or want to change the project structure.
- Create a Web Project in Eclipse:
right-click on the Project Explorer > New > Project > Web \ Dynamic Web Project
- Create a pom.xml file in the project root folder, with the following content:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.cejug</groupId> <artifactId>webapp-test</artifactId> <packaging>war</packaging> <version>1.0-SNAPSHOT</version> <name>webapp-test Maven Webapp</name> <url>http://maven.apache.org</url> <repositories> <repository> <id>maven2-repository.dev.java.net</id> <name>Java.net Repository for Maven</name> <url>http://download.java.net/maven/2</url> </repository> </repositories> <build> <finalName>${project.name}</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.0.2</version> <configuration> <webResources> <resource> <directory>$/WebContent</directory> </resource> </webResources> <warSourceDirectory>WebContent</warSourceDirectory> <warSourceExcludes>WebContent/WEB-INF/lib/*.jar</warSourceExcludes> <archiveClasses>false</archiveClasses> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix /> </manifest> <manifestEntries> <url>${pom.url}</url> <Implementation-Build>$</Implementation-Build> <Implementation-Title>${project.name}</Implementation-Title> <Implementation-Vendor>CEJUG</Implementation-Vendor> <Implementation-Version>${project.version}</Implementation-Version> <Built-By>${user.name}</Built-By> <Built-OS>${os.name}</Built-OS> <Build-Date>$</Build-Date> <SCM>$</SCM> </manifestEntries> </archive> </configuration> </plugin> </plugins> </build> </project>
- Compile and prepare the project for eclipse:
mvn -Dwtpversion=2.0 compile eclipse:eclipse
Notice the usage of the plugin -Dwtpversion to enable Maven to add Eclipse WTP Support to the project. That simple flag do the trick :). Actually just using that flag will work, but not all plugins of Eclipse will work out of the box without the WebContent folder - it is up to you to decide if it is worthy to modify your project structure or just go straight ahead with the plain Maven folder.
Done, now you can refresh the project in Eclipse and continue to work. Remember that jjust the resources folder is hard coded in Eclipse, the
src/main/java
continues as Maven expects. Perhaps some day we can have the confluence between the conventions of Maven and Eclipse and then we will finally becomes free of this daily basis hacks.Convert Exist Eclipse Dynamic Web Project to Maven project
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.0.2</version> <configuration> <webResources> <resource> <directory>$/WebContent</directory> </resource> </webResources> <warSourceDirectory>WebContent</warSourceDirectory> <warSourceExcludes>WebContent/WEB-INF/lib/*.jar</warSourceExcludes> <archiveClasses>false</archiveClasses> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix /> </manifest> <manifestEntries> <url>${pom.url}</url> <Implementation-Build>$</Implementation-Build> <Implementation-Title>${project.name}</Implementation-Title> <Implementation-Vendor>CEJUG</Implementation-Vendor> <Implementation-Version>${project.version}</Implementation-Version> <Built-By>${user.name}</Built-By> <Built-OS>${os.name}</Built-OS> <Build-Date>$</Build-Date> <SCM>$</SCM> </manifestEntries> </archive> </configuration> </plugin>
Configure java logger
Basic configurations for Java Logger ( since JDK 1.4)
LoggerManager will load <JRE_HOME>/lib/logging.properties as default logging setttings. In-order to load your own logging settings,
you may need to include the following line during jvm start:
-Djava.util.logging.config.file=mylogging.properties
where mylogging.properties is my own config base on <JRE_HOME>/lib/logging.properties.
You may also do your own logging.properties during your application startup, the detail please refer to Hildeberto's BLog .
LoggerManager will load <JRE_HOME>/lib/logging.properties as default logging setttings. In-order to load your own logging settings,
you may need to include the following line during jvm start:
-Djava.util.logging.config.file=mylogging.properties
where mylogging.properties is my own config base on <JRE_HOME>/lib/logging.properties.
You may also do your own logging.properties during your application startup, the detail please refer to Hildeberto's BLog .
How to run java application as Window Service ? [JSmooth Manual]
JSmooth 0.9.9-7 User Manual
Build 20070519-254
Rodrigo Reyes
Revision History | ||
---|---|---|
Revision 1.0 | 10 Sep 2003 | RR |
First draft | ||
Revision 2.0 | 19 May 2007 | RR |
Update for release 0.9.9-7 |
Table of Contents
JSmooth is a Java Executable Wrapper generator with advanced JRE detection features. It builds standard Windows executable binaries (.exe) that contain all the information needed to launch your java application, i.e. the classpath, the jvm version required, the java properties, and so on.
It also offers full control on deployment issues such as missing, old, or broken JRE installed on the end-user computer. The JSmooth wrappers provide smooth solutions, such as automatic JRE download and installation, redirection to a web site, or simply a meaningful message to the users on what's going wrong.
Because JSmooth is 100% java, it can build windows executables from any environement running Java, including linux, solaris, etc.
It also offers full control on deployment issues such as missing, old, or broken JRE installed on the end-user computer. The JSmooth wrappers provide smooth solutions, such as automatic JRE download and installation, redirection to a web site, or simply a meaningful message to the users on what's going wrong.
Because JSmooth is 100% java, it can build windows executables from any environement running Java, including linux, solaris, etc.
- The JSmooth web page is located at http://jsmooth.sourceforge.net/. Please visit it for the latest news.
- The JSmooth Project web page is hoster at http://sourceforge.net/projects/jsmooth.
- Should you find any bug, please submit it to the jsmooth tracker. For any question relative to JSmooth, please use the forum (hosted at sourceforge's).
- Your users see and use a standard windows Exe binary. No more technical explanation on .jar, on javaw association, etc.
- The JSmooth EXE are smart: They know how to swiftly search for all the JVM installed on a computer, and determine which best suits the requirements of your application. If no VM is found, your end-users are in good hands with jsmooth: the wrappers can redirect them to a web page, or even better, they can propose the user to automatically download and install a Java Environment.
- Detects the location of any Sun JVM installed. The wrappers use several strategies to detect all the JVM available on a computer, using windows registry, environment variables, or windows path (basically, whatever gives hints is used).
- Detects and uses Microsoft's JView (for 1.0 and 1.1 Java applications only), if available.
- The JVM search sequence is fully customizable using the GUI. You can force the executable to search in the path first, and in the registry last, or in JAVA_HOME first. We have all the flavours!
- Sometimes it's more convenient to bundle your own JRE with your application. JSmooth can deal with that too: you just need to define in which folder the JRE is packaged. It falls back nicely to a standard JVM search if the JRE is not where it should be.
- Specify which versions of the JVM are compatible with your software! You can set a minimum version, but also a maximum JVM version.
- A graphical project editor makes configuring and customizing your exe wrapper a breeze. The inline help balloons provide non-intrusive yet extensive information on each parameter available.
- Associate an icon to your executable, using a .ICO, .PNG, or .GIF file (automatic color reduction is done if necessary).
- Easy java properties configuration: specify the tag=value pairs you want the wrappers to pass to your java application.
- Pass also environment variables from the system: just define the java properties to pass to your application, and use the standard Windows %VARIABLE% syntax.
- Some special variables that are normally not available to Java program, such as the executable path and name, and even the Windows computer name, can be passed as well!
- Specify all the classpath configuration, adding .jar, .zip, or directories, with an intuitive GUI.
- Need to modify the current directory used by your java application ? The wrappers will handle this for you.
The JSmoothGen application is the project editor. It provides a (hopefully nice) graphical user interface for the configuration of all the parameters available to the wrappers.
Building your own EXE wrapper for your java application just needs a few simple steps: specify the name of the executable, define the main java class, optionally a classpath if it needs more than its own jar, and that's all.
The minimum data you need to start the creation of the binary executable for your application is to specify a classpath and the fully-qualified name of your main class. You can configure both in the
Once done, go to the
Of course, you can specify many more options for the java wrapper, but this is enough for a basic java application. Now, click on the save button (or in the File+Save menu) and select a filename for the project. This is an important step, because all the path stored in the file, and displayed in the GUI are relative to this project file. Selecting a location under the root directory of your project is a good (and safe) choice.
Once your project is saved, it is just a matter of clicking on the Project+Create Exe. And that's it. You can use the Project+Run Exe to run the program, or use the windows explorer to run the executable.
Application
panel (add new jars or directories using the icon with a yellow + sign, and type the class name in the Main Class field.Once done, go to the
Windows Executable
panel, and type the name of the executable in the Executable Name field. Do not forget to add the .exe suffix, for your executable name. Something like my-app.exe
should be fine.Of course, you can specify many more options for the java wrapper, but this is enough for a basic java application. Now, click on the save button (or in the File+Save menu) and select a filename for the project. This is an important step, because all the path stored in the file, and displayed in the GUI are relative to this project file. Selecting a location under the root directory of your project is a good (and safe) choice.
Once your project is saved, it is just a matter of clicking on the Project+Create Exe. And that's it. You can use the Project+Run Exe to run the program, or use the windows explorer to run the executable.
Warning | |
---|---|
You can modify the location of the every file in the project, but you must always keep this simple rule in mind:
|
The JSmooth application is based on a template system called "skeleton". Choosing a skeleton is the first step in the creation of a jsmooth executable.
A skeleton is a template with a specific behaviour. For instance, the following skeleton are bundled with JSmooth as of version 0.9.3:
Each skeleton has its own set of option, most of them are optional. Be sure to check them all, as they can modify drastically the behaviour of your wrapper. Please refer to the inline help for the details.
A skeleton is a template with a specific behaviour. For instance, the following skeleton are bundled with JSmooth as of version 0.9.3:
- The Console Wrapper is a skeleton designed for console applications (ie. which are run in the windows console). This skeleton takes care of passing the command line arguments to java application, it ensures the i/o are routed to the current console, and so on.
If no JVM is found, the application displays a text message to the standard output. - The Autodownload wrapper is designed for standard Windows applications, which do not use console.
If no JVM is found, the wrapper displays a customized message, and offers the end-user to automatically download and install a JRE. The version of the JRE to download is a configurable parameter of the wrapper, and uses the Sun's autodownload feature initially provided for Web Start. - The Custom Web Download wrapper is a wrapper for GUI-only applications (no console)
If no JVM is found, the wrapper displays a customized message, and offers the end-user to download a customized file from the internet. The URL is a configurable parameter of the wrapper, and accepts http, https, and ftp. The file download is automatically executed or displayed (according to the nature of the file). - The Windowed Wrapper is designed for standard Windows applications, which do not use console.
If no JVM is found, the skeleton displays a Windows OK/Cancel alert. If the user selects the OK button, the default web browser is launched on a web page. Both the message of the alert and the URL of the web page are configurable. - The Windows Service Wrapper provides a wrapper for application designed to work as services.
The wrapper can be installed, uninstalled, started, or stopped just like any other windows service. If no JVM is found, the service does not run, and a specific message is logged.
Each skeleton has its own set of option, most of them are optional. Be sure to check them all, as they can modify drastically the behaviour of your wrapper. Please refer to the inline help for the details.
The windows executable created by the JSmooth wrapping system can be configured in many ways.
- The executable name is the most obvious parameter. This is simply the name of the win32 file created by JSmooth.
- The current directory can be modified to suit your needs. For instance, if you want your executable to be in a
bin\
sub-directory, but still want it to access the resources as if it were in the base directory, it may be convenient to modifiy the current directory to be..
.
When this parameter is specified, the wrapper simply changes the current directory with the value "as is". For instance, to change the current directory to ares
subdirectory, writeres
in the Current Directory field.
Warning When run as a Windows Application, the default current directory is always the directory of the executable binary. However, for a console wrapper, the default current directory is the path where the command line is currently tied.
Changing the current directory for a console application is probably not what you want. A common issue is for a console application to find resources which are located in the file system (i.e not in the jar of the application). Lots of application work this way, but Java applications, unfortunately, do not have access to the information they need: the location of the binary executable they are launched from. A work-around is to use an environment variable specific to your application. This is was ANT does, for instance.
You can do something equivalent with JSmooth without using an environment variable (which may be complicated to set under windows). Instead, define a Java Property, and set${EXECUTABLEPATH}
as its value. The effect of this is to pass to your application a java property that contains the directory where the executable is located. Just useSystem.getProperty()
call to retrieve the value.
For GUI application, it's easier: just enable the option "Sets the executable folder as current directory of the application" and define a standard file association in Windows. Alternatively, you can also use the JNI features of jsmooth to retrieve the executable path. - The executable icon field specify the icon image that is associated to the executable, under Windows. The default configuration of JSmoothGen support Windows Icon files (.ICO) as well as the standard types supported by the JVM (GIF, PNG, and JPG files).
The current implementation only sets up a single icon image in the executable. Here is a brief description on how JSmoothGen creates the executable icon:
- If the user selects a standard Windows icon (.ICO), it chooses [1] first 32x32 icons, then 64x64, then 16x16.
- If the user selects any other recognized image file, the image is scaled to be 32x32, and quantized to fit in 256 colors. The color reduction is rough and it is always better to use an image processing software for the job.
This is the panel where you can specify all the parameters related to the java application itself.
- Edit the Main Class field to specify the class used as entry point of the program. This field is mandatory.
- The Arguments field allows you to specify default parameters for the application. Those arguments are passed as if they were specified on the command line, and are made available in the String array of the main method by Java.
Warning The Arguments may be overriden by some wrappers. For instance, the Console Wrapper always uses the arguments from the command line instead. - Using the Embedded Jar field, you can optionally specify a jar to be embedded (as a resource) in the EXE wrapper. This jar is extracted each time the application is launched, therefore you should keep it as small as possible.
This is specially useful for application packaged as a single EXE file. - The ClassPath list provides a mean to edit an ordered list of classpaths. To add a classpath, click on the and select either a .JAR, a .ZIP or a directory using the file chooser. You can remove or edit the classpath entries with the and buttons.
The items can be ordered to reflect the class look-up priorities of your application. Select an item, and press either or . The rules are simple: the higher in the list, the higher the priority in the classpath search sequence.
Click on the JVM Selection tab to specify the Java look-up parameters.
If your application requires a minimum or a maximum version of Java to run, the Version of Target VM subpanel will probably be of high interest for you.
Just leave the field empty if you do not wish to any constraint on the JVM version required for your application.
To specify a version, either as a minimum or a maximum, you must specify the major, minor, and sub-minor version number you want to set the constraint on. You don't need to specify all of those three numbers, but remember that if you leave it empty, it is considered as 0.
The values are inclusive. For instance, if you specify 1.4 as a maximum means that the java wrapper accepts 1.4.0 JVM, but not 1.4.1.
If your application runs exclusively with JVM 1.2 and 1.3, but not 1.1 nor 1.4 or above, just specify 1.2 for the minimum version, and 1.3.99 as a maximum version.
Just leave the field empty if you do not wish to any constraint on the JVM version required for your application.
To specify a version, either as a minimum or a maximum, you must specify the major, minor, and sub-minor version number you want to set the constraint on. You don't need to specify all of those three numbers, but remember that if you leave it empty, it is considered as 0.
The values are inclusive. For instance, if you specify 1.4 as a maximum means that the java wrapper accepts 1.4.0 JVM, but not 1.4.1.
If your application runs exclusively with JVM 1.2 and 1.3, but not 1.1 nor 1.4 or above, just specify 1.2 for the minimum version, and 1.3.99 as a maximum version.
Even if the wrappers of JSmooth provide a reasonnable user experience for the users who do not have Java installed, you may wish to bundle a JRE with your application. In such a case, tick the Use JVM Bundle checkbox, and specify the directory location of the JRE.
For the option to work correctly, you have to put a JRE in a directory near the EXE (generally in a subdirectory called "jre" or whatever). Once the exe is generated, it will FIRST try to locate the JRE at the location mentionned. If it can't be found there, then it will fallback in the normal jre look-up mode (search for a jre or a jdk in the Windows registry or in commonly-used environment variables). There is no JVM-version check when using a bundled JRE, as the packager is supposed to bundle a suitable JVM for the application.
Consequently, if you use the "Bundle JVM" option, you'll need to install yourself the JRE at the same relative path to the EXE.
For instance, take the following example:
In this case, the generated myexe.exe tries to use the jre in the "jre" sub-dir as its first-choice JRE. To deploy it, either simply zip all the "myprog" directory, or tell your favorite installer to set-up the jre directory in the same configuration as in your original folder tree.
Warning | |
---|---|
What the "JVM Bundle" option really specifies, is a path (relative to the generated EXE) where a JRE can be found. This is NOT an option to bundle a JRE in the EXE, as many people think. |
Consequently, if you use the "Bundle JVM" option, you'll need to install yourself the JRE at the same relative path to the EXE.
For instance, take the following example:
+myprog/ |- myjar.jar |- lib/ + mylib1.jar + mylib2.jar |- jre/ + [full jre stuff here] |- myexe.exe
In this case, the generated myexe.exe tries to use the jre in the "jre" sub-dir as its first-choice JRE. To deploy it, either simply zip all the "myprog" directory, or tell your favorite installer to set-up the jre directory in the same configuration as in your original folder tree.
The wrappers are able to detect most, if not all, the JVM available on the end-user computer. Before launching the java application, they try to find a JVM using a preference order. The default is to use the Windows registry to look-up the JRE that have been installed, then use some environment variable, and finally try to use Microsoft's JView.
This search sequence is fine for most configuration, however you can still modify it to best suit your needs. Use the and button to modify the priorities..
This search sequence is fine for most configuration, however you can still modify it to best suit your needs. Use the and button to modify the priorities..
The JVM Configuration offers the possibility to specify the parameters passed to the Java Virtual Machine when launching your application.
The Options panel provides editable fields to configure the memory configuration of the JVM. Specify the numeric value in the text field, and the unit in the combo box.
Java properties are name/value pairs that are passed to the JVM, and are accessible by java applications using the System.getProperty() method.
To add a new Java Property, click on the . A dialog box pops up.
Specify the name and the value for this property, and click on the Done button.
To add a new Java Property, click on the . A dialog box pops up.
You can use the Java Property mechanism to pass special values to your java app.
- Environment Variable: If you pass a string of the form %ENV% in the value field of the property, the wrappers will replace the string with the content of the ENV environment variable.
For instance, to pass the content of the JAVA_HOME environment variable, adds %JAVA_HOME% in the Value field. - JSmooth also makes some special variable accessible for your application.
Form Meaning ${EXECUTABLEPATH}
Replaced by the path to the executable binary. For instance, if the executable binary launched is located at c:/program files/jsmooth/test.exe, this variable is replaced with c:/program files/jsmooth ${EXECUTABLENAME}
Replaced by the name of the executable binary. For instance, if the executable binary launched is located at c:/program files/jsmooth/test.exe, this variable is replaced with test.exe ${COMPUTERNAME}
Replaced by the name of the computer. ${VMSELECTION}
Replaced by the name of the selection method used to spawn the JVM. The value replaced is typically one of the following values:
registry
, when the VM location is found in the registryjdkpath
, when the VM if found in the %JDK_HOME% variablejrepath
, when the VM if found in the %JRE_HOME% variablejavahome
, when the VM if found in the %JAVA_HOME% variablejview
, if the VM is JViewexepath
, if the VM was found in the windows pathbundled
, if the VM bundled with the application is used
${VMSPAWNTYPE}
This variable is replaced by one of the following values:
JVMDLL
if the JVM is spawned using a DLL loading and instanciationPROC
if the JVM is spawned in a new process using the Windows' CreateProcess function
You can build a wrapped java application using the jsmoothcmd.exe command. However, note that it only takes as argument a project file created by the JSmoothGen graphical application. In other words, you can't create a project from scratch using only the jsmoothcmd program, which is provided only as a convenience for scripting purposes.
Usage
The .jsmooth suffix may be ommited. The application either creates the executable binary successfully, or returns an error message.
jsmoothcmd.exe [myproject.jsmooth]
The .jsmooth suffix may be ommited. The application either creates the executable binary successfully, or returns an error message.
JSmooth can also be used as an ant task. This permits using it as a tool integrated in a standard ant deployment chain.
This is the first step to be able to use jsmooth in your ant scripts. You need to add a
If your jsmooth project uses the Sun's JIMI library to recognize .ico files, you must add it to the classpath as well.
taskdef
tag that provides to ant the information required to create the jsmoothgen
task.<taskdef name="jsmoothgen" classname="net.charabia.jsmoothgen.ant.JSmoothGen" classpath="path/to/jsmoothgen-ant.jar"/>
If your jsmooth project uses the Sun's JIMI library to recognize .ico files, you must add it to the classpath as well.
The task takes two mandatory parameters:
Here is a sample, extracted from the jsmooth build.xml file:
project
: a reference to the project file.skeletonroot
: a reference to a directory where the skeletons can be found. Be careful, this is not the directory where the skeleton used by the project can be found, be rather the directory one level up.
Here is a sample, extracted from the jsmooth build.xml file:
<jsmoothgen project="jsprj/jsmoothgen.jsmooth" skeletonroot="${dist}/skeletons"/>
Some of the jsmooth wrappers provides Windows-specific JNI features that allow your application to optionnaly access native information.
In order to use those features, you must enable the JSmooth JNI option, and add the
Before using any JNI feature from the
In order to use those features, you must enable the JSmooth JNI option, and add the
jsmooth.Native
calls in your java code. You need to build your project using the jnismooth.jar
library, but don't need to package it with your application, as it is embedded (as well as the native functions implementation) in the wrappers.Before using any JNI feature from the
jsmooth.Native
, you must check that the native methods are correctly bound to their native implementation by using the jsmooth.Native.isAvailable()
method. If this method returns false, you cannot use any of the native method.
Using the
shellExecute()
, you can start the default application associated by windows to a document and perform any of the action among SHELLEXECUTE_OPEN
(opens the file for visualization), SHELLEXECUTE_EDIT
(opens the file for editing), SHELLEXECUTE_PRINT
(print the document), SHELLEXECUTE_FIND
(launch the windows Find utility on a specific folder), SHELLEXECUTE_EXPLORE
(launch the windows file Explorer tool on a specific folder).if (jsmooth.Native.isAvailable()) { jsmooth.Native.shellExecute(jsmooth.Native.SHELLEXECUTE_OPEN, "c:\\myfile.pdf", null, null, jsmooth.Native.SW_SHOWNORMAL); }
There are some java libraries available around to launch the default browser on an URL, but using the
shellExecute()
is probably the best solution for the windows platform on this traditional problem.URL target = "http://jsmooth.sourceforge.net/"; if (jsmooth.Native.isAvailable()) { jsmooth.Native.shellExecute(jsmooth.Native.SHELLEXECUTE_OPEN, target.toString(), null, null, jsmooth.Native.SW_NORMAL); } else { // Use a traditionnal java-based guessing method // to find and launch the default browser }
It may be useful to reboot or log off the computer/session programmatically at a given time. You can use the jsmooth
exitWindows()
method to shutdown or reboot the computer, but also disconnect the session of the user.// Log off the user session if (jsmooth.Native.isAvailable()) { jsmooth.Native.exitWindows(jsmooth.Native.EXITWINDOWS_LOGOFF); }
There is no way to distinguish between a removeable media, a cdrom drive, or a fixed disk using the standard java API. It is however a good usability point to use different icons to display fixed, removeable medias, remote drives, or cdrom. It may also be useful to know if there are enough free space on disk before saving a file, or to be aware that the filesystem used for a media is FAT16, in order to alert the user of a possible loss of precision in the filenames.
The
The
jsmooth.DriveInfo
object provides all this information for free, provided your application is launched with a jni-enabled jsmooth wrapper.File f = new File("d:/my/file/somewhere"); jsmooth.DriveInfo di = jsmooth.Native.getDriveInfo(f); if (di.getDriveType() == jsmooth.DriveInfo.DRIVE_REMOVABLE) { // This file is on a removeable drive ! } if (di.getFreeSpaceForUser() < (1024*1024*64)) { // there are less than 64MB free for the // user on this drive ! }
- 7.1.1. How does a wrapper extract the jar file?
- 7.1.2. What happens to the extracted jar file when the java application exits?
- 7.1.3. Jsmooth allows only one embedded jar in the executable binary. Does it mean that all the java application must be entirely contained in this jar ?
- 7.1.4. How can I run the ant task or the command line in headless mode (so that it can run on unix servers without X-Window)?
- 7.1.5. How do I pass JVM-specific arguments with the wrappers?
- 7.1.6. I have a filetype associated to my program. However, when I launch a document, my application can't find its resources, because the current directory is the directory of the document. How do I fix that ?
- 7.1.7. How do I convert my java application into a Windows service ?
The JSmooth generator is distributed under the terms of the GNU General Public Licence. Please read the License.txt file that comes with the package. Alternatively, you can find additional information on the GNU GPL license on the GNU Web Site
The generated executables are distributed under the terms of the GNU Library General Public Licence and as such do not constrain the licence of the Jar it may embed.
The generated executables are distributed under the terms of the GNU Library General Public Licence and as such do not constrain the licence of the Jar it may embed.
This product includes software developed by L2FProd.com (http://www.L2FProd.com/). The l2fprod-common library is licensed under the terms of Apache Software License. Source code can be found at the following location: https://l2fprod-common.dev.java.net/
JSmooth includes the JOX library. JOX is a set of Java libraries that make it easy to transfer data between XML documents and Java beans. It is distributed under the terms of the Lesser GPL. Source code for JOX is available at the library's web site: http://www.wutka.com/jox.html.
JSmooth includes the DTDParser library. It is distributed under the terms of either an Apache-style license or the Lesser GPL license. Source code for is available at the library's web site: http://www.wutka.com/dtdparser.html.
The autodownload skeleton uses the libmspack library (http://www.kyz.uklinux.net/libmspack/). The licence is not exactly the LGPL but is OK with jsmooth usage.
The autodownload skeleton uses the fltk library (http://www.fltk.org/). FLTK is provided under the terms of the GNU Library Public License, Version 2 with exceptions that allow for static linking.
JSmooth includes the JOX library. JOX is a set of Java libraries that make it easy to transfer data between XML documents and Java beans. It is distributed under the terms of the Lesser GPL. Source code for JOX is available at the library's web site: http://www.wutka.com/jox.html.
JSmooth includes the DTDParser library. It is distributed under the terms of either an Apache-style license or the Lesser GPL license. Source code for is available at the library's web site: http://www.wutka.com/dtdparser.html.
The autodownload skeleton uses the libmspack library (http://www.kyz.uklinux.net/libmspack/). The licence is not exactly the LGPL but is OK with jsmooth usage.
The autodownload skeleton uses the fltk library (http://www.fltk.org/). FLTK is provided under the terms of the GNU Library Public License, Version 2 with exceptions that allow for static linking.
[1] The Windows ICO file format can store several images in a single file. A single file often stores icons at several resolutions.
Subscribe to:
Posts (Atom)