I just switched my day-job development from Windows to Linux. I use IBM Rational® Software Modeler™ every day for its various advanced features, and among other things the software that I develop extends some of its features. Therefore, I self-host my PDE.
As it happens, my software project also depends on other Eclipse-based components that are not included in RSM. So, I install them into my RSM workbench. On Windows, this works fine because I am an administrator of the system and p2 installs the stuff into the shared bundle pool.
However, on Linux, the picture turns out to be a very different one. I installed RSM as root but I run it as a regular user. It seems that some kind of funky extension to Equinox causes p2 to install my extra features into my home directory, and the launcher finds its configuration there instead of in the main product installation location. Very cool! Great for a multi-user environment.
However, not so great for my PDE target. PDE only recognizes the plug-in locations installed in the product, not this extra location in my home directory. Enter the PDE Target Definition.
drum roll ...
I use the New Target Definition wizard to create a new PDE target, and it creates one that includes my current Eclipse configuration by default. Then, I add another location in which it will find plug-ins. I could even, if I wanted to, add plug-ins from my workspace, although this seems odd because the workspace generally is implicitly in the target, anyhow.
With one click in the top right corner of the editor, this target is installed in my PDE environment and it now finds every plug-in that I need. It's too easy!
5 comments:
But what about the need for sharing that target definition? The paths in your target definition are absolute, so it can't be used by others on your team. That is the need I'm facing now; with 3.3 I was able to simply check in an entire target platform and everyone on the team could use it; but p2 has screwed with that.
Can the target definition be made sharable (ie, using only relative paths)?
@Eric: I think so. The locations that you specify in the target definition can use Variables. ${eclipse_home}, ${workspace_loc}, ${env_var}, etc. ...
yes, you can use variables in target definitions and that's what a lot of people do to share them.
However, we are changing target definitions soon in 3.5 if everything goes as planned. It'll be a surprise ;)
@Chris: Oo! I do like surprises, esp. at Christmas time. Do you mean that it will be a surprise that everything goes as planned? ;-)
The surprise is around using p2 to materialize target definitions and also force people to start using target definitions as a way to manage targets. For example, the dreaded "Target Platform" preference page will be rehauled... it will look similar to the "Installed JREs" page but you'll have "installed targets"
This will pave the way for us to have targets on a per-project basis which is a popular demand from people doing single-sourcing (RCP/RAP)
Post a Comment