Jörn Kottmann wrote:
To work around this issue, you can add a PEAR file to your cas editor
project and install it on demand and then check if the PEAR file is
already installed or not. When doing this, you can also check if the
installation location for your PEAR has changed (if the workspace has
been moved to another place) and in such a case reinstall the PEAR
again to the new location.
Sounds good, but if the PEAR is installed to the workspace then manual
changes done to its artifacts are overwritten
if the location has changed (since it must be reinstalled).
I think the installation location should be in a temp directory or at
least outside the workspace. If its already there
he PEAR installation is reused.
You are right local changes might be a problem here, maybe the user can
be ask what to do in that case (reinstall or not) and ask him to backup
his changes.
I personally don't like the idea to install PEARs outside of the project
into a temp directory.
I think there is another issue:
The cas editor project has a type system which is used to edit the cas
files.
What happens if the PEAR has its own type system ?
Can the PEAR extend the already existing type system ?
Every PEAR I think has it's own type system, since it should run out of
the box. If there is no type system specified in the PEAR it won't run.
If the two type system can work together can be checked when the PEAR
file is installed. If there is an error that the two type systems cannot
be merged, the PEAR install routine can throw an error so that the user
know what to fix? Does this make sense?
Another use case might be to first deploy a PEAR to the project and use
the PEAR type system as project type system. In that case there seems to
be no issue.
-- Michael