Twitter github

New Target Platform Preference

To give plug-in developers out there a heads up… I want to say that there will be a new preference available to you when working with target platforms in 3.4M7:

What does this preference do?

Well, first, let me tell you about how PDE goes to build your target platform. By build, I mean what PDE does when you point it to a location and you get a target platform out of it. There has always been a little magic inside that operation. The magic involves PDE analyzing your target platform location and looking to see if it can find a configuration of plug-ins installed. How did PDE do this? In the the era of before p2, there was a platform.xml file that was kept by Update that listed the set of recognized plug-ins. In the era after p2, there is a file called bundles.info which serves a similar purpose. These files were there so the runtime can make smart decisions on what to actually run when started. For example, you could have 10 versions of plug-in A on disk, but only one version listed in one of those configuration files so when Eclipse is ran, the runtime only knows about what is listed in the configuration file (see a sample bundles.info below).

So if PDE found one of these “configuration files” it would construct your target platform to reflect what would actually be running in your target. If it didn’t find one of these configuration files, it will then just manually scan the file system and build a target platform with what plug-ins PDE found on disk. In the 10 versions of plug-in A case, it would populate the target platform with all 10 versions if it couldn’t find a target “configuration file.”

When p2 was introduced in the SDK (3.4M6), the bundles.info file was always around and caused confusion for people when they grabbed the SDK, unzipped something like WTP and all their dependencies, and pointed their target platform to the location to only see the SDK set of bundles. PDE was almost being too smart here… it’s analysis of the target platform was correct, ie., only the SDK set of bundles have been discovered by p2 and since the target hasn’t been launched, the unzipped set of bundles (WTP) haven’t been discovered yet.

To not break people’s existing workflows, PDE added this preference to the target platform preference page with some smart initialization. If you’re target == host, we will attempt to build the target platform using the target’s configuration. If your target != host, PDE will revert to manually scanning for plug-ins on the file system to build your target platform. It seems 99.9% of the Eclipse plug-in development community has been spoiled by that workflow so PDE needs to adapt. However, if you wish to change this behavior, the preference will allow you to do that based on your needs.

I hope this clarifies things for some people who have been experiencing growing pains with the 3.4M6 version of Eclipse. It pains me to expose this preference, but it seems it may be a good thing in the long run. The important thing to take away here is that an unzipped plug-in != installed plug-in.

Related bugs:
[bug 226037] – initialization policy for target platform should be different based on location
[bug 225148] – P2 PDE target doesn’t work, easily

  • Eugene Kuleshov

    Chris, can you clarify what “build your target platform” is actually mean?

  • Eugene Kuleshov

    Chris, can you clarify what “build your target platform” is actually mean?

  • Chris Aniszczyk (zx)

    Sure, when you point to a new target location, PDE will “build” a target platform based on that location. In most cases, PDE will simply scan the filesystem of the location and use the plug-ins it finds. In fancier cases, PDE will use the target configuration to build a target platfrom that reflects the actual running instance of the target (ie., if it were actually running at that given time)

  • Chris Aniszczyk (zx)

    Sure, when you point to a new target location, PDE will “build” a target platform based on that location. In most cases, PDE will simply scan the filesystem of the location and use the plug-ins it finds. In fancier cases, PDE will use the target configuration to build a target platfrom that reflects the actual running instance of the target (ie., if it were actually running at that given time)

  • Wassim Melhem

    This new complexity in self-hosting makes me sad 🙁

  • Wassim Melhem

    This new complexity in self-hosting makes me sad 🙁

  • Chris Aniszczyk (zx)

    It makes me a bit sad too… but p2 complicates life Wassim.

  • Chris Aniszczyk (zx)

    It makes me a bit sad too… but p2 complicates life Wassim.

  • Wassim Melhem

    If it takes a full blog post to explain what a single checkbox does, you know there is a problem.

    PDE has always tried hard to shield the user from self-hosting complexities and I feel we could do better here. Perhaps post-3.4, this situation could be revisited.

  • Wassim Melhem

    If it takes a full blog post to explain what a single checkbox does, you know there is a problem.PDE has always tried hard to shield the user from self-hosting complexities and I feel we could do better here. Perhaps post-3.4, this situation could be revisited.

  • Simon Archer

    Chris, the checkbox’s label is far from clear to me. Maybe it’s just that I’m now having to learn about PDE implementation details that I never had to think about before, but I can honestly say that I’m unsure when I need to check the checkbox and when I don’t.

    There are two use cases that I care about:

    1. I’m an OSGi bundle developer and I want to roll my own target platform, which consists of a handful of Equinox bundles and a handful of my own. In this case I am setting my workspace’s Target Platform preferences to point a predefined target.

    2. I’m an Eclipse plug-in developer and I just want to build plug-ins for the same version of Eclipse that I’m using for development (just to keep things simple). In this case I’m not setting my workspace’s Target Platform preferences, since the default is fine.

    What state should the checkbox be for both these use cases? Thanks.

  • Simon Archer

    Chris, the checkbox’s label is far from clear to me. Maybe it’s just that I’m now having to learn about PDE implementation details that I never had to think about before, but I can honestly say that I’m unsure when I need to check the checkbox and when I don’t.There are two use cases that I care about:1. I’m an OSGi bundle developer and I want to roll my own target platform, which consists of a handful of Equinox bundles and a handful of my own. In this case I am setting my workspace’s Target Platform preferences to point a predefined target.2. I’m an Eclipse plug-in developer and I just want to build plug-ins for the same version of Eclipse that I’m using for development (just to keep things simple). In this case I’m not setting my workspace’s Target Platform preferences, since the default is fine.What state should the checkbox be for both these use cases? Thanks.

  • Chris Aniszczyk (zx)

    Simon, your normal workflow won’t be interrupted. The whole purpose of the checkbox was to allow more flexibility when building a target platform. Certain users were confused due to PDE magic under the covers.

    In your case, you won’t have to modify the preference at all. PDE defaults to your style of workflow which is about 99.9% of plug-in developers out there.

  • Chris Aniszczyk (zx)

    Simon, your normal workflow won’t be interrupted. The whole purpose of the checkbox was to allow more flexibility when building a target platform. Certain users were confused due to PDE magic under the covers.In your case, you won’t have to modify the preference at all. PDE defaults to your style of workflow which is about 99.9% of plug-in developers out there.

  • Nikos

    May be you should just “hide” this option if it’s for 0.1% of us 😉

  • Nikos

    May be you should just “hide” this option if it’s for 0.1% of us 😉

  • Phillipus

    I tripped up over this seriously. I installed the RCP Delta Pack into Eclipse 3.4 and couldn’t get any Multi-platform exports at all until I unticked this box. This is going to be a pain.

  • Phillipus

    I tripped up over this seriously. I installed the RCP Delta Pack into Eclipse 3.4 and couldn’t get any Multi-platform exports at all until I unticked this box. This is going to be a pain.

  • Chris Aniszczyk (zx)

    Phillipus… can you try your scenario in 3.4M7 when it comes out? I think I fixed all workflow related issues.

    Sorry for the trouble :/

  • Chris Aniszczyk (zx)

    Phillipus… can you try your scenario in 3.4M7 when it comes out? I think I fixed all workflow related issues.Sorry for the trouble :/

  • Phillipus

    Hi Chris…do you never rest? 😉 Thanks for the quick reponse. I will try it…

  • Phillipus

    Hi Chris…do you never rest? 😉 Thanks for the quick reponse. I will try it…

  • Phillipus

    It seems to be broken again in eclipse-SDK-I20080507-2000-win32.

    I can’t see the delta pack fragements unless I untick this.

  • Phillipus

    It seems to be broken again in eclipse-SDK-I20080507-2000-win32.I can’t see the delta pack fragements unless I untick this.

  • Chris Aniszczyk (zx)

    Correct Phillipus, this is required when using the delta pack. I have updated most of the documentation in the Plug-in Developer Guide to cover this case. The problem is that p2 won’t install bundles not relevant to your platform so the delta pack doesn’t appear.

    Thanks for providing quick feedback.

  • Chris Aniszczyk (zx)

    Correct Phillipus, this is required when using the delta pack. I have updated most of the documentation in the Plug-in Developer Guide to cover this case. The problem is that p2 won’t install bundles not relevant to your platform so the delta pack doesn’t appear.Thanks for providing quick feedback.

  • Phillipus

    OK, Chris. By default it is checked. New users to 3.4 who use the Delta Pack and multi-platform .product files will get bitten by this.

  • Phillipus

    OK, Chris. By default it is checked. New users to 3.4 who use the Delta Pack and multi-platform .product files will get bitten by this.

  • Chris Aniszczyk (zx)

    It’s checked by default when your target == host. Although there is a compelling argument that it should always be off by default.

  • Chris Aniszczyk (zx)

    It’s checked by default when your target == host. Although there is a compelling argument that it should always be off by default.

  • Denni Bonn

    Hello, I like your blog. It is rather interesting, that is why I decided to browse the net and on this great site http://www.pisseconsumer.com I learned about this company a little more. Target is an American retail company. Target is the fifth largest retailer in the US in terms of sales. Target specializes in retail selling a wide range of products: clothes, footwear, home decor, furniture, garden products, jewelry, beauty products, electronics, pet products, and sporting goods.

  • A furniture outlet can be a terrific way to outfit your home or office in comfort and style at a low cost. Outlet stores have been around for years now and have been a way for anyone, but especially bargain shoppers to get the brand name and top of the line products such as clothing, shoes and even pots and pans, at lower prices than they would find at a regular retailer. The manufacturers are able to do this by cutting out some of the middlemen and selling more directly to the consumer.