> Now onto the answers to the questions: > >This appears to be where install handler equivalent functionality would be > performed > This would only be true if what you were trying to achieve in the > install handlers were OS level things. Other things may need to be done by > other touchpoints.
More generally yes, touchpoints can be used in place of install handlers. In many cases features all contained the same install handler perhaps with a different data file. Here you can take that install handler, make it into a touchpoint and write an IU that has data for that touchpoint. This way the "install handler" code is only downloaded once, versioned and managed. > >Also is Rhino JavaScript envisioned to be the main scripting mechanism for > the native touchpoint > Currently we have been using rhino for simplicity since java objects > can just be made scriptable and we did not have to define an input format. > That said, rhino is big, may be too powerful and could make the > understanding of configuration scripts hard, therefore it is likely that we > will try to replace it with something else more declarative. But all that > is still up for discussion. touchpoint writers are free to use whatever technology and markup they want. As Pascal points out, we currently have chosen JavaScript for the Eclipse and Native touchpoints and while that may remain an option, it we will likely move to a simpler, a more declarative approach. Jeff
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
