#2 Customizable steps in install/uninstall
The current (development) version of VAInstall uses a integral state defined
in AbstractInstall.java :
protected static final int LANGUAGE = 0;
protected static final int START = 1;
protected static final int WELCOME = 2;
protected static final int LICENSE = 3;
protected static final int README = 4;
protected static final int UPGRADE = 5;
protected static final int DIRECTORY = 6;
protected static final int INSTALL = 7;
protected static final int SHORTCUTS = 8;
protected static final int END = 9;
The nextStep() method is stepping through these hardcoded values. We have
a tight coupling in the flow which we have to duplicate everytime we create
a new UI.
As an 'Application Packager' you often want to customize how an installation
should be.
I have a XML-look-a-like proposal:
1. A step is an entity with attributes defining a single step.
2. The ordering of the steps defines the installation flow.
3. The set of steps is a type of install: It could a an install
or an uninstall.
4. For all steps that requires input. An input f.ex. destination directory
should be named so we can acces that 'property' globally and support
unattended install(using a response file).
5. A GUI application where you can test and generate the installation
flow.
6. The XML syntax should be 'Ant' friendly.
7. I vote for that we use a XML parser for the job. We could use Xerces which
we use for building VAInstall anyhow.
I think we need all the 10 types of steps and a few more:
1. 'Dependency' Step.
This is a step that allows the packager to test if a certain JDK/JRE level
is available. If a certain Java Class is in classpath or another
application is installed(Using VAInstall).
If this step fails the installation aborts after showing a panel with
information.
2. 'Custom' Step.
This is a step that allows the advanced packager to interact with VAInstall
by creating own steps.
The step is loaded with dynamic class loading. It has to be included in the
packaging step and I have a easy solution for this later in another
proposal I have.
3. 'Package' Step
This is a step that allows the user to select sub-packages for an
application.
Often an application can installed with a required 'core' and one or more
optional sub-packages like 'documentation' or 'tutorials'.
This requires that VAInstall supports that but I have a easy solution
for this later in another proposal I have.
4. 'Information' Step
This is a panel that is able to show HTML (JEditorPane) just as a basic
information window.
Now for the XML stuff. I have not defined a DTD for this yet.
A set of installation steps is defined as:
<steps type="install">
...
</steps>
The type can be "install" or "uninstall".
Inside the steps entity you can have step entities:
<step type="readme">
<property name="vainstall.archive.readme" value="src/doc/readme.txt"/>
</step>
The property is a global property.
The custom step could be:
<step type="custom">
<lproperty name="class" value="com.memoire.vainstall.test.CustomStep"/>
</step>
The lproperty is a local property.
The think most of the basic work could be done in the AbstractInstall class.
A detailed document of this feature has to be written.
What do you think ?
Henrik Falk
Logged In: YES
user_id=179443
The XML stuff is great when we are talking about VAInstall from the packaging side.
We have a minor problem when we want to deploy this solution because we then have to include
an 'lightweight' XML parser in the distribution or parse the file ourselves or find another format
for the installation side.
Logged In: YES
user_id=159757
We use for another project a tiny XML parser which you
certainly know: Aelfred from microstar.com.
Logged In: NO
This sounds like exactly the king of feature I need.
I have some config settings for my app which are machine
specific and I need to prompt the user for them on install
and configure the application properties file accordingly.
If my understanding of your above description, and the way
VAInstall currently works is correct it may not be as much
of a problem as hfalk mentions.
As I understand it the config XML file is read at build
time in order to configure the Java class which is generated
When in comes to the install the vai file is not used, just
the java .class file - so no need for an XML parser.
Anyone had any further thoughts on if/how/when the changes
could be made ?
Great application guys.