Announcement : New version of JLaunchPad 1.0.1 - universal java launcher

This program tries to resolve the following challenges:

1. It gets rid of complex starting scripts to run JVM with different parameters (memory optimizers, classpath,
bootclasspath, native library path, system properties etc.). The idea is to have one universal script that fits all possible scenarios. The part that is different from one project to another is moved to configuration file. JLaunchPad provides ready to use scripts both for Windows and Unix environments that can be used by any Java program. If you need to customize the process of starting JVM, you don't modify these scripts. Instead, you make modifications in the configuration file.

For example, if you want to run your program that requires native library (*.dll), your configuration will
look something like this:


# my_prg.jlcfg
# my configuration

<java.library.path>
_path_to_your_dll_library_

<jvm.args>
-Xms256m
-Xmx512m

<launcher.class>
_your_fully_qualified_class_name_

<command.line.args>
_param1_
_param2_


You can use the following sections within your configuration file:

- "java.classpath";
- "java.endorsed.dirs";
- "java.ext.dirs";
- "java.library.path";
- "java.system.props";
- "java.bootclasspath";
- "java.bootclasspath.prepend";
- "java.bootclasspath.append";
- "jvm.args";
- "launcher.class";
- "set.variables";
- "command.line.args".

It seems that for projects with simple start scripts it's not worth using it. But JLaunchPad
offers some other features that could be useful for your project.

This part of the functionality is based (with some modification) on Java App Launcher project.

2. It downloads all dependent libraries (if necessary) from remote server and installs them locally. You don't have to install libraries manually. Once you declare the dependency, it will be downloaded and installed automatically.

It requires to have all used libraries located on remote server. It's true for all
installations that exist in WWW, but we have to organize these installations a little bit more. To eliminate infamous jar hell we want to introduce separation based on group name and version. Closest candidate that could make this organization happen is maven repository.

We have to make these changes in configuration to make it happen:


# my_prg.jlcfg
# my configuration

<launcher.class>
_special_launcher_class_

<command.line.args>
-deps.file.name=_my_deps_file_.xml


Remote maven repositories are used as the storage for libraries and maven project file is used for describing dependencies. As you can see, we try to reuse maven abilities as much as possible.

This part of functionality becomes available thanks to "bootstrap-mini" project that is
the part of maven2 source.
It provides file delivery mechanism, independent from maven2 standard delivery mechanism.

3. It builds CLASSPATH dynamically based on declared dependencies. You can put all the dependencies for your project in dependencies file. Current implementation
uses maven2 pom.xml file for describing dependencies. As an example, if you want to run JRuby engine, you need to have these files:

a). JLaunchPad configuration:


# my_prg.jlcfg
# my configuration

<launcher.class>
_special_launcher_class_

<command.line.args>
-deps.file.name=_jruby_deps_file_.xml
-main.class.name=org.jruby.Main


b). JRuby dependencies file


<!-- _jruby_deps_file_.xml -->

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.sf.scriptlandia</groupId>
<artifactId>jruby-starter</artifactId>
<version>1.0</version>
<packaging>pom</packaging>

<name>JRuby Starter</name>
<description>JRuby Starter</description>

<dependencies>
<dependency>
<groupId>jruby</groupId>
<artifactId>jruby</artifactId>
<version>1.0.2</version>
</dependency>
</dependencies>
</project>


This functionality is possible thanks to classworlds project.

JLaunchPad's main responsibility is to integrate these 3 different approaches into one powerful solution.
Classworlds takes care of classloader management. We read dependencies files and inform classworlds about new libraries that should be added to CLASSPATH. To accomplish it, "_special_launcher_class_" should be substituted with "org.codehaus.classworlds.Launcher" class.
We only need to tell classworlds which class to run: "org.sf.jlaunchpad.JLaunchPadLauncher". This class is main integration point that performs main preparation work: it reads dependencies file, download them if required and add them dynamically to CLASSPATH. Then it tries to execute java class declared with "main.class.name" parameter.


Changes for current release:

- added proxy with authentication;

- storing configuration parameters (proxy, local repository location, remote repositories location)
in settings.xml file;

- added new examples;

- changes in installation program layout;

- other changes and improvements.