Copyright © 2008 Panayotis Katsaloulis (panayotis *at* panayotis.com). Original content in this work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Greece License
Table of Contents
Thank you for trying Jupidator. This is an open source developer library which is used to automate the updating procedure of an application. It is written in Java and has been tested in all major platforms. The update mechanism itself is not platform agnostic, so that the developer can choose the appropriate files per platform.
Usually an application has no mechanism by default, to inform the user that a new version of the application is available. Although some operating systems support downloading of new packages, in most desktops this is not applicable. More sophisticated applications can check the current version, by loading a specific web page and inform the user that a newer version is available. Then the user is directed to manually download the newest version and install it.
A few applications have an integrated update feature. The user is informed of the new version, the application is downloaded in the background and when ready, the application is restarted. The user experience is much improved then. With this approach newer version is automatically installed and the user doesn't need to go to a specific page in order to download it. In big and complicated applications, the updater is able to fetch only parts of the application, or "packages", which have been upgraded from one version to the other.
Jupidator is a library to intergrade the update feature to any program, while going one step further. Instead of fetching the complete application or separated packages, it is able to fine grain the update procedure by working with files. Although it is still possible to work with packages or a complete replacement of the whole application, the developer can work with file groups or even single files, while keeping track of the change-log in the desired granularity. Files that have been updated through more than one version, only the latest version is brought. Even if a file exists in one version, and is missing in a future version, the system is able to delete this file - and bring it back if this file appears again.
Granularity in various levels is not the only advanced feature of Jupidator. It uses a single centralized XML configuration file to simultaneously support all desired platforms. Platform support is not limited by it's popularity. The developer is able to define the platform he is interested in, or even revert to the general non-specific platform for all other cases. The platform manipulation is flexible to completely fit the developer needs.
Jupidator has been checked in most major platforms. File management can not be really multi-platform, due to the nature of file storing. Still, this library does it's best and is supposed to properly work with any system that has JRE version 5 ( in other words 1.5 ) and above.
Jupidator can be used to update any application, not only Java applications. Although it is basically a library, it is also a stand alone application. The distributed JAR can be run as: java -jar jupidator.jar. The required parameters will be displayed on screen. Reference to the text below for more detailed explanation of these parameters.
Jupidator shows its strength when it's integrated into a Java project. The only requirement is to be defined in the classpath of the application. The most easy way is to use the JAR provided (dist/jupidator.jar) as an external library. Jupidator's license is LGPL, thus it is allowed for you to bundle this JAR file with your application.
If you prefer to change some parts of Jupidator itself, or if you don't want to distribute a separated JAR file, you can add Jupidator source code to your project. Just copy the source tree of Jupidator and you are ready! In any case, just make sure that you are in accordance with the Licenses which come together with Jupidator.
To use Jupidator, you have to define two simple things:
Bindings with the running application
An XML file which describes the updated parts of the application
Jupidator is using a incremental updating mechanism. In any new version the developer needs to provide only the changed files, and not the whole distribution. The updating mechanism parses all versions newer than the currently running and cleverly downloads the latest version of every part, even if parts are brought in various versions. Even if a file exists in one version, then gets deleted in a future distribution and then appears again, the file will be downloaded if nessesary.
The updating scheme can be used in two contexts: with operating systems that support updating of the main application and with operating systems that the applications should be take care of themselves for updating. The first system is for example Debian, while the second is Windows. The first type of operating systems needs only to update parts like plugins of the application, and not the application core itself, while the other type requires all files to be updated. This difference is taken into account when using Jupidator updater.
The bindings with the actual application are divided in the following 2 parts:
Execution of the updater
Feedback mechanism of the updater
A com.panayotis.jupidator.Updater object is required to start the actual updating procedure. The user only needs to create a new object of this class, and everything else is handled by the updater automatically. It is constructed as follows:
public Updater(String xmlurl, String appHome, String appSupportDir, String release, String version, UpdatedApplication application) throws UpdaterException
xmlurl the URL of the XML file which describes the updated parts. See next section.
AppHome the directory path of the application. Typically is where the JAR file is found. Usually it is writable by a user with elevated privileges.
AppSupportDir is the directory path where application locally stores files. Typically resides in the $HOME directory of the user, and thus the user has write permissions in it.
release the numerical version of the application. This should be an increasing integer number which marks every release.
version the human readable version of the application. This is a free text versioning scheme, for displaying reasons.
UpdatedApplication the object implementing the com.panayotis.jupidator.UpdatedApplication interface, as described below.
To start the actual updating procedure, the actionDisplay() should be called. All further actions are handled by Jupidator, in a separated thread if needed. All arguments, except UpdatedApplication, are required for the updater to work correctly.
The main program needs to receive some feedback of the updater process. Firstly, it needs to receive debugging information and secondly it needs to be informed that application restart is needed. Thus an object implementing com.panayotis.jupidator.UpdatedApplication is required. The two required methods are defined as follows:
public void receiveMessage(String message)
Mechanism for the main application to receive debugging messages. These messages can be ignored of course, or stored wherever the application think is appropriate (i.e. in a log file). These messages are possibly localized.
public boolean requestRestart()
The updater requests to restart the application. No actual restart is performed yet. This method is used to do the necessary housekeeping, like for example to save open files. If the application returns "true" then housekeeping is successful and the updater is allowed to restart the application. Or else the updating procedure is stopped.
Here is an example how to use Jupidator with a simple application. The developer just needs to create a new MyAppUpdate object with the desired information.
import java.io.File;
import com.panayotis.jupidator.UpdatedApplication;
import com.panayotis.jupidator.Updater;
import com.panayotis.jupidator.UpdaterException;
public class MyAppUpdate implements UpdatedApplication {
public MyAppUpdate() {
try {
new Updater(
"http://www.myapp.com/update/update.xml",
"/usr/lib/myapp",
System.getProperty("user.home") + File.separator + ".myapp",
"413",
"4.1.3",
this).actionDisplay();
} catch (UpdaterException ex) {
ex.printStackTrace();
}
}
public boolean requestRestart() {
return check_if_we_can_restart();
}
public void receiveMessage(String message) {
System.err.println(message);
}
}Jupidator needs a XML file to store the various updated files. In this section a brief introduction to core elements will be presented. For more information amd detailed documentation please refer to the DTD documentation of this XML file.
The root element of this XML should be updatelist. Required arguments are:
application : The application name
baseurl : The base URL of the downloading files. This is the reference "parent" URL, where all remote URL addresses are defined.
icon : The image icon of the application. It should be in a format that the JRE will be able to understand (e.g. PNG).
A list of architectures is currently required with element name architect, in order to distinguish between different architectures and machines. Required arguments are:
tag : The tag which marks this architecture. More than one architectures can share the same tag and are used the same by Jupidator. Two special tags exist: "any" to define any other architecture not strictly described and "all" to perform work for all architectures, in addition to their specialized entries.
os : The operating system of this machine.
arch : The machine architecture.
Element architect hosts exactly one launcher element.
For every new version of the application, a new element version is required. It is preffered to list all older version elements, since this will also serve as a changelog of your application. Required attributes are:
For every architecture (even the "any" architecture), an arch element is required.
The element arch is the core container of actions, that will be performed when updating from this architecture. There is one required attribute:
name : The name of this architecture, as defines with the architect element.
Please have a look at the list of supported nested elements. The most common element is file. This element is responsible to download files, or even packages if the compress="zip" attribute is used.
Here is an example of the jupidator XML file:
<?xml version="1.0" encoding="UTF-8"?>
<updatelist application="Jubler" baseurl="http://www.jubler.org/files" icon="icons/jubler.png">
<architect tag="any" os="" arch="">
<launcher exec="${JAVABIN}">
<argument value="-jar"/>
<argument value="${APPHOME}/Jubler.jar"/>
</launcher>
</architect>
<architect tag="win32" os="Windows" arch="x86">
<launcher exec="${APPHOME}\Jubler.exe"/>
</architect>
<architect tag="linux" os="Linux" arch="x86">
<launcher exec="${JAVABIN}">
<argument value="-jar"/>
<argument value="${APPHOME}/Jubler.jar"/>
</launcher>
</architect>
<version release="15" version="0.2.0">
<description>Some more updates</description>
<arch name="win32">
<file name="Jubler.exe" sourcedir="0.2.0" destdir="${APPHOME}" size="1217834" compress="gzip"/>
</arch>
<arch name="any">
<file name="Jubler.jar" sourcedir="0.2.0" destdir="${APPHOME}" size="1138527" compress="gzip"/>
</arch>
<arch name="all">
<file name="ReadMe.html" sourcedir="0.2.0" destdir="${APPHOME}/lib" size="4298" compress="gzip" />
</arch>
</version>
<version release="10" version="0.1.0-RC1">
<description>Minor updates</description>
<arch name="win32">
<file name="Jubler.exe" sourcedir="0.1.0" destdir="${APPHOME}" size="942915" compress="gzip"/>
</arch>
</version>
<version release="1" version="0.0.1">
<description>Initial release</description>
</version>
</updatelist>
The URL of the file to-be-downloaded is http://www.jubler.org/files/0.2.0/Jubler.exe.gz or http://www.jubler.org/files/0.2.0/Jubler.jar.gz depending on the architecture. Additionally, all architectures will download the http://www.jubler.org/files/0.2.0/ReadMe.html.gz file.
Description of this XML file can be found in DTD documentation.
This section is about various properties that can be used inside the XML file, as well as some configuration options, which will override the defaults.
Jupidator supports variables inside the various URLs and filenames. This is a list of predefined variables:
APPHOME
Home directory of the application, as given to the runtime environment
APPSUPPORTDIR
Support directory of the application, as given to the runtime environment
VERSION
Human readable version, as given to the runtime environment
RELEASE
Numeric release, as given to the runtime environment
IGNORERELEASE
Last release, which the user requested not to upgrade.
JAVABIN
Path to Java executable.
WORKDIR
The current working location of Jupidator. It is usually in the temporary storage of the operating system. Its value change every time Jupidator is launched.
Any Java System property, i.e. ${java.io.tmpdir}
Any environmental variable, i.e. ${UID}
The developer can define it's own variables and use them inside the XML file. New variables are stored inside the com.panayotis.jupidator.ApplicationInfo object, by calling the method setProperty(String name, String value)
In order to use these variables, should be enclosed in curly brackets and prepended with a dollar sign. For example, to define a directory inside application support directory, with the username in the path, the following expression should be written:
${APPSUPPORTDIR}${file.separator}${user.name}${file.separator}myfile.txt
The supported Jupidator GUIs might understand some properties, which will fine-tune the apperance of the information. To set these properties the developer has to call the method setProperty(String key, String value) in the GUI class.
To receive the reference of the current (default) GUI, the method getGUI() of com.panayotis.jupidator.Updater should be called. The developer can of course change the default Jupidator GUI, by calling the setGUI() method.
These properties are case insensitive. If the values are boolean, then the words "enable" "true" "yes" "on" and "1" can be used to enable this feature; all other words are used to disable the feature.
Note that the GUI decides which property to support. If a property has no meaning for a specified GUI, it is silently ignored.
About: Show about information regarding th Jupidator installer.
LogList: Display full changelog information.
SystemLook: Use system look and feel. Not applicable to console UI.
There is one special property which can be used with Jupidator - whether the desired update method is distribution based or not. If, in other words, the operating system itself takes care of the main update process of the application. This feature has been described here.
To turn on this feature, the developer has to call method setDistributionBased(true) in com.panayotis.jupidator.ApplicationInfo object.
GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. http://fsf.org/
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
This version of the GNU Lesser General Public License incorporates
the terms and conditions of version 3 of the GNU General Public
License, supplemented by the additional permissions listed below.
0. Additional Definitions.
As used herein, "this License" refers to version 3 of the GNU Lesser
General Public License, and the "GNU GPL" refers to version 3 of the GNU
General Public License.
"The Library" refers to a covered work governed by this License,
other than an Application or a Combined Work as defined below.
An "Application" is any work that makes use of an interface provided
by the Library, but which is not otherwise based on the Library.
Defining a subclass of a class defined by the Library is deemed a mode
of using an interface provided by the Library.
A "Combined Work" is a work produced by combining or linking an
Application with the Library. The particular version of the Library
with which the Combined Work was made is also called the "Linked
Version".
The "Minimal Corresponding Source" for a Combined Work means the
Corresponding Source for the Combined Work, excluding any source code
for portions of the Combined Work that, considered in isolation, are
based on the Application, and not on the Linked Version.
The "Corresponding Application Code" for a Combined Work means the
object code and/or source code for the Application, including any data
and utility programs needed for reproducing the Combined Work from the
Application, but excluding the System Libraries of the Combined Work.
1. Exception to Section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License
without being bound by section 3 of the GNU GPL.
2. Conveying Modified Versions.
If you modify a copy of the Library, and, in your modifications, a
facility refers to a function or data to be supplied by an Application
that uses the facility (other than as an argument passed when the
facility is invoked), then you may convey a copy of the modified
version:
a) under this License, provided that you make a good faith effort to
ensure that, in the event an Application does not supply the
function or data, the facility still operates, and performs
whatever part of its purpose remains meaningful, or
b) under the GNU GPL, with none of the additional permissions of
this License applicable to that copy.
3. Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from
a header file that is part of the Library. You may convey such object
code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure
layouts and accessors, or small macros, inline functions and templates
(ten or fewer lines in length), you do both of the following:
a) Give prominent notice with each copy of the object code that the
Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license
document.
4. Combined Works.
You may convey a Combined Work under terms of your choice that,
taken together, effectively do not restrict modification of the
portions of the Library contained in the Combined Work and reverse
engineering for debugging such modifications, if you also do each of
the following:
a) Give prominent notice with each copy of the Combined Work that
the Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the Combined Work with a copy of the GNU GPL and this license
document.
c) For a Combined Work that displays copyright notices during
execution, include the copyright notice for the Library among
these notices, as well as a reference directing the user to the
copies of the GNU GPL and this license document.
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this
License, and the Corresponding Application Code in a form
suitable for, and under terms that permit, the user to
recombine or relink the Application with a modified version of
the Linked Version to produce a modified Combined Work, in the
manner specified by section 6 of the GNU GPL for conveying
Corresponding Source.
1) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (a) uses at run time
a copy of the Library already present on the user's computer
system, and (b) will operate properly with a modified version
of the Library that is interface-compatible with the Linked
Version.
e) Provide Installation Information, but only if you would otherwise
be required to provide such information under section 6 of the
GNU GPL, and only to the extent that such information is
necessary to install and execute a modified version of the
Combined Work produced by recombining or relinking the
Application with a modified version of the Linked Version. (If
you use option 4d0, the Installation Information must accompany
the Minimal Corresponding Source and Corresponding Application
Code. If you use option 4d1, you must provide the Installation
Information in the manner specified by section 6 of the GNU GPL
for conveying Corresponding Source.)
5. Combined Libraries.
You may place library facilities that are a work based on the
Library side by side in a single library together with other library
facilities that are not Applications and are not covered by this
License, and convey such a combined library under terms of your
choice, if you do both of the following:
a) Accompany the combined library with a copy of the same work based
on the Library, uncombined with any other library facilities,
conveyed under the terms of this License.
b) Give prominent notice with the combined library that part of it
is a work based on the Library, and explaining where to find the
accompanying uncombined form of the same work.
6. Revised Versions of the GNU Lesser General Public License.
The Free Software Foundation may publish revised and/or new versions
of the GNU Lesser General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Library as you received it specifies that a certain numbered version
of the GNU Lesser General Public License "or any later version"
applies to it, you have the option of following the terms and
conditions either of that published version or of any later version
published by the Free Software Foundation. If the Library as you
received it does not specify a version number of the GNU Lesser
General Public License, you may choose any version of the GNU Lesser
General Public License ever published by the Free Software Foundation.
If the Library as you received it specifies that a proxy can decide
whether future versions of the GNU Lesser General Public License shall
apply, that proxy's public statement of acceptance of any version is
permanent authorization for you to choose that version for the
Library.
The Apache Software License, Version 1.1
Copyright (c) 2001 The Apache Software Foundation. All rights
reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. The end-user documentation included with the redistribution, if
any, must include the following acknowlegement:
"This product includes software developed by the
Apache Software Foundation (http://www.apache.org/)."
Alternately, this acknowlegement may appear in the software itself,
if and wherever such third-party acknowlegements normally appear.
4. The names "Ant" and "Apache Software
Foundation" must not be used to endorse or promote products derived
from this software without prior written permission. For written
permission, please contact apache@apache.org.
5. Products derived from this software may not be called "Apache"
nor may "Apache" appear in their names without prior written
permission of the Apache Group.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
====================================================================
This software consists of voluntary contributions made by many
individuals on behalf of the Apache Software Foundation. For more
information on the Apache Software Foundation, please see
http://www.apache.org/.
This package is based on the work done by Keiron Liddle, Aftex Software
keiron@aftexsw.com to whom the Ant project is very grateful for his
great code.