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

Is there a guarantee that the Target Platform will be hosted by Eclipse.

e.g.: i develop a rcp-application
in 5 years i have to implement some new features. will i be able to build my application against the target definition pointing to the eclipse galileo update site?

if not, what would you suggest instead?

at our company we are allready using a target platform. we just used all the plugins from the ganymede release for 3.4 target platform. but it’s huge and there are lots of unneeded plugins in it. i’ve tried to minimize it, but from a certain point i was able to build our applications, but unable to launch them. and the error message didn’t tell me what.

alex

Thanks for your answer – at least I now know that I didn’t miss anything important ;-)
I very much agree that products should be specified using features; the only drawback which I see with this is that your RCP app becomes more bloated than it is necessary (as many features also contain plugins that you normally would not want to add). Still, trying to maintain the complete list of plugins is a real nightmare, so I opted for the features :-)

Kai

thanks for this useful hint!

Martin

I agree that it would be nice to specify dependency information in one place and reuse it for development and builds. Maybe some day we’ll get to a Maven-like dependency approach. Also, it should be noted that currently a product definition is a concatenation of target platform and workspace resources, so it’s not a one-to-one mapping.

Currently, there’s no way that I’m aware of to avoid duplicating the information. I highly suggest basing product definitions on features instead of bundles, which makes a definition simpler and easier to maintain.

Regards,

— Patrick

These target platforms are a very useful feature indeed. Thanks for the hint to the target file, now I also know how this setup can be easily shared among the team members :-)

There is just one thing I ask myself: What is the best way to keep this target platform definition and my RCP product definition in sync? In the .product file you also list all features/plugins that make up your application (e.g. org.eclipse.rcp) and thus this information is very close to the content of the target file.

What is your suggestion to deal with this?

Cheers,
Kai