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

Reply via email to