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.