Ah, I understand what you mean. Occasionally it makes sense to add bundles to your own features, especially if you only need a few from a particular eclipse feature. Bringing in org.eclipse.platform is usually overkill for most RCP apps.

I often create a “support” feature for the third party (including Eclipse) bundles I need for a given feature. For example:

com.modumind.myapp.feature
com.modumind.myapp.support.feature

I usually create a separate folder to hold the support bundles for each feature, and these can be versioned if you like. These folders can then be added to your target platform in the normal way.

— Patrick

I agree that managing the target is easier with features, but what I was trying to figure out was the mapping between a required plug-in in my run configuration and what feature it was in (so I could add that feature to my target). I’ve been developing against my (bloated?) eclipse install for quite some time, so I had some plug-ins I wasn’t sure what feature they were in. Eg. org.hamcrest.core… turns out that plug-in is in the eclipse platform. It’s how to determine what feature that plug-in is included in that I wasn’t sure about. In that case, I was just looking through the eclipse platform, rcp, pde, etc. zip packages from that site and saw it in there.

Ryan

Here are my thoughts on your questions:

1. The RCP SDK contains source bundles. When you’re creating a target platform for development use, you want source bundles so you can browse and debug into it. The source bundles also provide the extension point definitions and it’s difficult to developer RCP apps without them. For a build machine, I would generally use the regular RCP Runtime + Delta Pack.

2. It’s no problem to just download the RCP SDK, extract it, and then add that file to your target platform definition. It’s true that the RCP SDK (and Runtime) are platform independent and that does seem strange. I suppose it makes it possible to export your app from the IDE, though PDE Build will still fail. Anyway, you only need the RCP SDK for development, RCP Runtime + Delta Pack for a build machine.

3. The link in your post is the correct place to download any of the RCP-related zip files.

4. Generally it’s easier to manage your target platform at the feature level. This means that even if certain bundles are not required by the run configuration, they are still part of your target platform. It’s possible that you could weed out the bundles that are not required, but in my opinion it’s better to think of features as the real building blocks for RCP apps and to leave them intact in the target platform.

I hope this helps,

— Patrick

Thanks,
Ryan

There’s no way I know of to link target platforms and product definitions. The target platform specifies all of the bundles which *may* become part of your product. The product definition specifies the bundles that *are* part of your product.

I agree that there is some redundancy here and it would be nice if you could simply specify things once.

— Patrick

Martin

Yes, you will almost always need to add other bundles to your target platform. JUnit is a common one, third party libraries will need to be added as well.

You can structure these additions in various ways. For some, you may want to create a directory and place the bundles there. For others (JUnit for example), you may want to point at an installation and select the bundles you need.

One thing to be careful of is to add only the bundles you really need. Adding the EclipseSDK to your target platform is usually unnecessary. Remember that you don’t have to limit a target platform to features, it can contain individual bundles as well. You’ll want to create your own features to contain those bundles. For example, you may want to create a com.mycompany.myproduct.test feature to reference your JUnit bundle.

Regards,

— Patrick

one little remark I have realized when playing around with target platform …
As long as I only have my RCP application in my Eclipse workspace everything is OK. But as soon as I want to add some junit test to my code the target platform in not sufficient any more. If I want to run pure java unit test as well as plugin junit tests I need to expand the target platform further. I ended up using the at least the EclipseSDK package as target platform, in order to work as usual!
Nevertheless, I still think that the concept of target platform is very valuable.

What are your experience in this area? Any possibilities I have missed?

Regards
Paul

That would be a good question to ask the Eclipse Foundation, but I doubt if they would provide a guarantee. I was talking to Jeff McAffer at EclipseCon about this issue and he suggested Yoxos as a solution. This is really the same problem as depending on a Maven repository for builds, but they have a longer track record of supporting this type of thing.

In my work, I do not yet use update sites for build targets, only for development. I usually construct build targets locally and then archive them along with my source code.

— Patrick