Marshall Schor wrote:
[EMAIL PROTECTED] wrote:
Here's an apparent catch-22 about installing PEAR files that I don't
quite
understand.
How is installation supposed to work when there's a configuration
parameter
or external resource in the component descriptor that is both
required and
doesn't have a default value?
For example, I have one external resource that is the name of a
certain file
you want the annotator to use (it's some static reference data).
This is
required--the annotator can't operate without it. And there can be no
reasonable default--we can't guess the name of the file the customer
will
want to use when we create the component descriptor.
What is suggested here is to include a dummy version of the static
reference data as a resource. Then set the parameter to reference
that resource. Of course, after "install", the user will need to
configure this to their actual data file.
So the user installing the PEAR file really must set it to something
before
running the annotator.
So I bound a path that works on my development machine. However, on
the customer's' machine this fails when installer attempts verify the
component
by loading the annotator classes and calling initialize():
com.ibm.uima.resource.ResourceInitializationException:
Could not access the resource data at
file:/C:/blah/blah
You want to bind a path that is a resource in the PEAR, and then use
the $macro capabilities to have that path adjusted at install time to
take into account where it was installed.
I tried just leaving the resource unbound, but first the component
editor
complains ('There is no resources satisfying the required resource
dependency
with key "blah.blah.blah"'), and then during installation I get the same
ResourceInitializationException.
I also tried binding it to a URL that doesn't exist, but the component
editor complains about that too ('Could not access the resource data
at blah'), and then the installer throws ResourceInitializationException
again.
A similar thing happens with configuration parameters that are required
and not defaulted, it just happens later in the installation process,
when you try to run the AE in the CVD, and the call to process()
fails when
our software throws an exception about the missing value.
Right - to get this to pass validation, you have to have some defaults.
At least with configuration parameters there's a opportunity in the
install
process between pushing "Install" and "Run your AE in the CAS Visual
Debugger" to edit the descriptor file. But there's no such opportunity
with the required external resources, since verification happens
immediately
after the files are extracted from the PEAR file.
What is the intended path of sucess here? It doesn't seem possible.
It seems to me that the installation process needs a step between
extraction
and verification in which the user can configure the AE by editing the
descriptor (either in a text or XML editor, or in the Eclipse Component
Descriptor editor).
This is a good suggestion for an enhancement. Absent this enhancement,
will the approach outlined abouve work in your situation?
I also think that this will be a good enhancement for the PEAR installer
GUI.
If all the suggestions above doesn't work, besides the PearInstaller GUI
there is also a PEAR API that can be used to install pear files to a system.
With the PEAR API you can specify if you only want to install the pear
or if you additionally want to verify it. With this, you
can provide your own "pear installer" that is integrated to your
application. For more details about the PEAR API please refer to the
documentation (chapter 6.2 in the references book) where you will also
find a short example.
-- Michael
