Community
Participate
Working Groups
After moving to p2, the PDE development environment doesn't automatically load all plugins from the target. It appears to only load the platform plugins, and I have to manually click the Reload button to get it to load other plugins. While this is a pretty simple workaround, this regression is annoying when switching between multiple development environments. FWIW, I've heard reports from others where this hasn't even worked, making M6 unusable as a development environment. I've asked them to submit separate bugs.
what do you mean automatically load all plug-ins? Is there a simple reproducible test case I can do?
Do you mean when you switch targets, plug-ins are unchecked?
Plugins aren't unchecked, they're completely missing from the list. I moved to M6 as my development environment, restarted a workspace with a PDE target pointed to this week's WTP I-build, and all the plugins in my workspace failed to compile. When I went to the PDE target preference page, it was picking up all the platform plugins from the target, but none of the EMF/GEF/WTP plugins. Clicking Reload solved that - the number of plugins in the list jumped from ~200 to ~800 and a rebuild of the workspace removed the compile errors.
Are the WTP builds producing p2 metadata yet? ie., a bundles.info etc...
No, I think the platform is the only build that does.
I've had trouble with this too. In my case, reload didn't even help, except now that I've restarted my workbench, reload does seem to find 'dropins' in the target. Here's one way you can try and reproduce. I'll describe my first attempt, though I've tried many others since (and don't currently have this, exactly). You can start with one of our recent builds: http://build.eclipse.org/webtools/committers/wtp-R3.0-S/20080401132642/S-3.0M6-20080401132642/ To create dev. env. first install the M6 SDK. Then I install the following pre-reqs from that page: EMF v2.4 Runtime Minimum executable code. emf-runtime-I200803181800.zip EMF XSD v2.4 Runtime Minimum executable code. xsd-runtime-I200803181800.zip Graphical Editing Framework (GEF) GEF-SDK-I200803262022.zip Data Tools Platform (DTP) dtp-sdk-1.6M6-200804011008.zip Eclipse Test Framework eclipse-test-framework-3.4M6.zip Eclipse releng tool org.eclipse.releng.tools-3.4M6.zip and WTP itself, the result of that build ... for self hosting! wtp-sdk (83M) My first attempt I tried installing each zip in a separate subdirectory of eclipse/dropins, such as emf, xsd, gef, dtp, etc. ... and that all works fine as a dev. environment (meaning, it finds everything, and I can use WTP, etc). Next, I simply copied, that whole install, to another 'targets' directory. Then, when I went into PDE preferences, target runtime, and tried to change the target to that 'targets/eclipse' directory it would only find the eclipse/plugins (290) ... not anything from 'dropins'. Reload did not help, at first, though 'reset' would correctly find all the subdirectories from my host install. After several re-tries and restarts, I ended up with a subset of the the above in 'dropins' only (not a subdirectories for each pre-req) and now, after restarting, it seems to find them, using reload ... but ... pretty frustrating and time consuming! and I'm still not sure what "made it work" ... the subset, the restarting, the single 'dropins' directory?
Oh, and, I meant to say ... using a build from just a few days before M6 declared, my procedure worked fine ... first time I tried, with everything, with subdirectories, etc.
I don't think it's finding things in the dropins directory because PDE isn't aware of changes in the bundles.info after things are put in the dropins directory. A restart is required or reloading the target platform should take care of it. The way the logic works is if PDE finds a bundles.info, it will use that to build its target platform. If it doesn't find one, it will just scan directories and find all the plug-ins it can. I would be curious to see the state of the bundles.info while this is happening.
(In reply to comment #8) > > The way the logic works is if PDE finds a bundles.info, it will use that to > build its target platform. If it doesn't find one, it will just scan > directories and find all the plug-ins it can. > That explains alot. So the work around is to remove bundles.info in the scenario I describe ... where I sort of "duplicate" my whole install (with the goal of eventually updating parts of the target, as new builds come out). In fact, besides restarting, I think at some point I went and tried to "run" the target, as itself (as host), to see if it would find everything (which it did) ... so perhaps that created a "state" by which the next time PDE could find everything when used as a target?
(In reply to comment #8) > > I would be curious to see the state of the bundles.info while this is > happening. > I can report the state now, after all churn ... the bundles.info lists "everything", even things in the dropins folder. Sounds like this was probably created updated when I "ran" the target? I'm assuming PDE would not update this file, right?
(In reply to comment #10) > I can report the state now, after all churn ... the bundles.info lists > "everything", even things in the dropins folder. Sounds like this was probably > created updated when I "ran" the target? I'm assuming PDE would not update this > file, right? No, p2 touches the bundles.info file and is responsible for it. PDE simply reads it to construct the target platform if available. This is similar to what we did if we found a platform.xml in the past (well still do if you target an old version of Eclipse)
So, you haven't said ... is the right work around for a developer to delete the bundles.info file when making a target that is a collection of these "in progress" pieces? Why is it that "reload" works at all (at least some sometimes)?
Right now I think the workaround is reload... if the bundles.info has been updated, reload should pickup all the new bundles. If this isn't the case, it's a bug. I need more time to do investigation on this one. Sorry for the bumpy plug-in development ride, we tried to catch everything when p2 was dropped.
Here's a little easier way to re-create, and I've confirmed it is the "running" of the target that allows the dropins to be discovered. I unzipped the M6 SDK, and before running it (don't know if that's significant), copied that directory to another 'target' directory. Unzipped the platform's releng tool in the dropins folder of the target. Started the original sdk and set the target preference to the target/eclipse I created by copying. and no amount of button pressing or restarting would get it to discover the releng tools in the dropins folder. It sometimes did not even "remember" the target I set (upon restart) though eventually it did, but still no dropins. I tried deleting bundles.info in the target, but that did not help at all. Eventually I "ran" the target (after restoring the bundles.info file). That bundles.info file was now updated with releng plugin info. Closed, that instance, and went back and restarted the original sdk. At this point PDE would "discover" the releng plugin. (didn't even have to press reload :) But, I then tried to add the test framework to the target dropins folder (in a new directory) and it would not find that new dropins folder/plugins. Sigh ... I don't know how Tim got this to work so easily ... but, if others had this same problem, I'd mark this as blocker ... I am not sure I can recommend our developers use a P2 environment with this "bumpiness". I'm not confident that even disabling P2 would help.
David, I'll make it my top priority to investigate this tomorrow morning, don't have time tonight :) For now, all I can say is check out the migration guide: http://wiki.eclipse.org/Equinox_p2_Migration_Guide By the way, Ed/Nick, how have you solved issues in regards to EMF / Modeling? This issue can't be unique.
The cool thing about the current behavior (just taking contents of bundles.info) is that your PDE target platform contains exactly what has been installed into that target system. If you start up that target system and install some things into it, then its bundles.info will be updated and the dev workspace pointing to it will have an updated target platform. This has the nice attribute that the PDE target platform has exactly the same set of bundles as the target system if it were currently running. The problem here is that you have dropped some extra content into plugins or dropins of that target platform, but never ran it, so the dropped in content has not yet been discovered and installed. The workaround would be to startup/shutdown the target platform once so that everything gets discovered and installed. There are scenarios where it's not the right answer to automatically include everything in the target plugins directory into the target platform (for example when using bundle pooling and multiple applications share the same plugins directory). I think what's scary here for users is that the behavior of PDE here is "magic" - the target platform pref page just shows a location, so it's a reasonable user expectation that all plugins in that location will be discovered. I'm wondering if it would be better to have a checkbox that says something like "Include only plug-ins installed into the target platform". If this is on, it consults only the bundles.info file. If this is off, it grovels over the file system and pulls in everything it finds. I.e., is the "target platform" treated just as a directory full of plug-ins, or is it treated as a real installed application.
(In reply to comment #16) > The cool thing about the current behavior (just taking contents of > bundles.info) is that your PDE target platform contains exactly what has been > installed into that target system. If you start up that target system and > install some things into it, then its bundles.info will be updated and the dev > workspace pointing to it will have an updated target platform. This has the > nice attribute that the PDE target platform has exactly the same set of bundles > as the target system if it were currently running. John is correct here. > I think what's scary here for users is that the behavior of PDE here is "magic" > - the target platform pref page just shows a location, so it's a reasonable > user expectation that all plugins in that location will be discovered. There really isn't that much magic, this behavior has been consistent for many releases in PDE. In the past, if we discovered a platform.xml, that would be used to build the target platform. The only change now is that we use the bundles.info (kind of like the platform.xml) if it exists. If we can't find a bundles.info or a platform.xml, we manually scan directories for plug-ins. I don't think exposing a preference to just scan directories is the right direction yet.
Here's a couple scenarios that I tried: Scenario A 1) started SDK, went to software updates and installed each zip via adding 'Archive' 2) restarted SDK, everything is OK in target platform Scenario B 1) unzipped all deps to c:/targets 2) started SDK, went to software updates and installed each zip via adding 'Local' 3) restarted SDK, everything is OK in target platform Scenario C 1) unzipped all deps to c:/targets 2) setup link files 3) started SDK, pointed to c:/targets 4) it's all good Scenario D 1) unzipped all deps to c:/targets 2) started SDK, went to target platform pref page, and Added directories (in C:/targets) via target provisioner 3) it's all good Scenario E 1) unzip GEF plug-ins zip in dropins directory 2) started SDK, GEF is in target platform 3) it's all OK
I have two more scenarios coming :)
Scenario F 1) unzip SDK to c:/targets/eclipse-wtp, then unzip all deps to drop-ins 2) start another SDK, point c:/targets/eclipse-wtp 3) only Platform plug-ins appear... This is correct behavior as PDE reads the bundles.info and only sees what's there Scenario G 1) unzip SDK to c:/targets/eclipse-wtp, then unzip all deps to plug-ins directories 2) start another SDK, point c:/targets/eclipse-wtp 3) only finds platform plug-ins due to bundles.info This is correct behavior as PDE reads the bundles.info and only sees what's there This shouldn't be different than what happened in the past when we came across the platform.xml file in the target. However, I believe by default, we didn't come across a platform.xml file until someone actually launched the target... I believe Update would write one out when launched
If I run Scenario G, and delete the bundles.info before starting the SDK, and pointing to the location, it picks up all the bundles since it scans directories.
Looking at scenarios F and G, I think the new target provisioner (bug 204347) might be of some use. Rather than downloading and extracting two separate SDK's and WTP, you would just download the SDK you want to develop on and use the target provisioner to download WTP (and a specific SDK if you wanted to). This would require that WTP was available from an update site (preferably with p2 metadata). Just a thought.
I think Scenario G is the one that is surprising people here, and is different from the past. In the old world the platform.xml would just have a URL for the base plugins directory (platform:/base/). It was assumed that every bundle at that location was part of the target. With p2, there may be bundles in that base location that are not installed in the target application (not listed in bundles.info): 1. The plugins directory may be a shared bundle pool used by multiple applications 2. There plugins directory may contain bundles that have been uninstalled from the application, but not garbage collected 3. The plugins directory may contain bundles that have been downloaded by p2 but not yet installed (there are preferences that allow updates to be downloaded automatically, but only installed when the user is ready). 4. The user may have dropped in new bundles manually but they have not yet been discovered because the target application has never been started. In cases 1-3, including only the contents of bundles.info is the most accurate and correct answer. In case 4 users are surprised that their bundles are not part of the target platform. This comes down to one of the central educational messages about p2: unzip != install.
(In reply to comment #23) The reason scenario G worked before is because the platform.xml didn't get generated until you first started whatever you unzipped... so PDE would just scan the directory of the target platform location for plug-ins. However, if you ever started that target, and the platform.xml appeared, PDE would just use whatever is in there instead of scanning locations. I think that's the issue here... we have a bundles.info by default now that's included in the SDK so when people unzip things, we come across that file and ignore the rest.
The only "PDE" solution I can think of is introducing a preference in PDE to support ignoring any target platform data... and just scan directories. However, this is still a different workflow from what we had before... and I'm not comfortable with this option yet. Is there anything we can do as part of build output possibly to solve this issue. John, thoughts? Also, I think if there's a WTP-all-in-one build, that could come with the proper bundles.info and things should be peachy.
As I mentioned, deleting the bundles.info did not work for me, so suspect it works for you due to the exact order of the steps you followed. It seems to me we should get the same "smart" behavior from PDE that we get from starting the target eclipse ... it seems smart enough to know when to discover and when not to. What's up with that? Also, Scenario D was a logical approach, which I tried, but then all that work of adding 5 or 6 pre-req directories is lost when I hit reload ... see bug 216359. Perhaps this could be improved with more user choice ... "keep added directories or reload from pristine condition". As for unzip != install ... disregarding the lack of "central education" :) ... it seems unzip-to-dropins-folder _does_ equal install when starting eclipse, so why not here. To say "it's working as designed", or "working like it used to if you had ran the target" (which I never did) is a very technology oriented answer ... not really a user oriented one. But, heck, maybe I am the only user who ever develops this way and the only one who has lost time trying to adjust to these changes. Maybe everyone else working on a tight deadline is completely unaffected. I'd suggest you also check the use cases with P2 disabled ... It doesn't appear the instructions at http://wiki.eclipse.org/Equinox_p2_Removal would change the behavior of PDE back to it's previous self ... and, I just happen to know some adopters are counting on restoring previous behavior -- at least temporarily. (It may be fine, I'm just suggesting some thought and testing be given to it).
Scenario H 1) unzip SDK to c:/targets/eclipse-wtp, then unzip all deps to plug-ins directories 2) start another SDK 3) create wtp.target file, add additional directories 4) set target platform using wtp.target 5) things are OK There's another scenario that works
Ok, here's another possible solution: PDE can detect the timestamp on bundles.info, if it's less than the plugins or dropins folder, we just scan directories like the old fashion way This is similar logic p2 uses on startup. Investigating a possible patch...
(In reply to comment #26) > But, heck, maybe I am the only user who ever develops this way and the only one > who has lost time trying to adjust to these changes. Maybe everyone else > working on a tight deadline is completely unaffected. > I am seeing the same behavior as David (though I didn't figure out why one of my target platforms was working and the other was not until I read this). Just letting you know you're not alone ;)
(In reply to comment #27) > 3) create wtp.target file, add additional directories Remember who you're talking to here :) I don't know what this is, but sounds intriguing (and maybe something we in WTP should be doing anyway). But, agree, the timestamp solution sounds like a good one to restore previous user-experience.
I'm changing summary, to P2 PDE target doesn't work, easily as I think the "reload" has been discounted. And, attempting to set to major, since I think this is "missing function" to what we had ... would be blocking, except there is an easy work around ... to just "run" the target with the new stuff in the dropins (or eclipse/plugins) folder.
Also note https://bugs.eclipse.org/bugs/show_bug.cgi?id=225410 where command line PDE build does not work until you run the target eclipse installation once.
(In reply to comment #32) > Also note https://bugs.eclipse.org/bugs/show_bug.cgi?id=225410 where command > line PDE build does not work until you run the target eclipse installation > once. > Hi Chris, this was the point I was trying to make on IRC on Weds.
(In reply to comment #3) > Plugins aren't unchecked, they're completely missing from the list. I moved to > M6 as my development environment, restarted a workspace with a PDE target > pointed to this week's WTP I-build, and all the plugins in my workspace failed > to compile. When I went to the PDE target preference page, it was picking up > all the platform plugins from the target, but none of the EMF/GEF/WTP plugins. > Clicking Reload solved that - the number of plugins in the list jumped from > ~200 to ~800 and a rebuild of the workspace removed the compile errors. > I get the same behaviour when using M6, *with p2 removed* (by following instructions at http://wiki.eclipse.org/Equinox_p2_Removal). My use case: - Install the M6 drop - Add update site for AJDT 3.4 (http://download.eclipse.org/tools/ajdt/34/dev/update) - Install AJDT - Restart (-clean) - Go to Preferences ... Target Platform => org.aspectj.runtime plugin is not listed - Click Reload. => Large number of plugins appear, including AspectJ runtime.
Created attachment 94740 [details] org.eclipse.pde.core (jar) Here is a test jar for people to confirm this is working if they want to test early.
Created attachment 94741 [details] org.eclipse.pde.core.patch The simple way of doing this...
I believe this will return the wrong answer for the following cases: - The target has been run, and some plugins/feature were uninstalled but still exist on disk - The target has been run, and some updates have been downloaded but not yet installed - The target bundle pool is shared across multiple applications - The user dropped in content into a sub-directory of dropins. The dropins folder timestamp will not be updated in this case. - bundles.info refers to files outside either plugins or dropins (for example a common bundle pool used in multi-user installs, or dropins contains a link that points outside the install tree) - perhaps others... This patch looks fine as a short term workaround so that user expectations about the behavior of past releases is met. However, I think it opens up many new problems for the future because the target platform in PDE will not reflect what is actually installed in the target application. I.e., it preserves old user expectations but will not meet new user expectations for all the new scenarios now possible in p2 that we didn't support in the past.
(In reply to comment #37) I agree John, but getting people to change their workflows is tough. I haven't dropped the fix in yet... if people use target definitions, their old workflows seem to be supported.
I have tested the attached patch and can confirm it fixes the "unzip and run" (or, I should say, "unzip and target") scenario that I expected to work, which is the workflow I've grown accustom too. I will admit, I think now with P2, I would be surprised (and users will still open bugs :) for the case John mentions about - The user dropped in content into a sub-directory of dropins. The dropins folder timestamp will not be updated in this case. As that seems to be "the new workflow" encouraged by P2's dropins folder. I'm not sure, but seems the current quick fix could be easily extended to look at subdirectories of dropins too. It seems like the other cases are sort of "brand new" use-cases that perhaps deserve some "brand new" integration with PDE ... so that basically PDE can cause an "update" of the target (of it's meta data that is), so it would act like it had been "started up and shutdown", without the user actually having to start it up and shut it down. (After all, the I in IDE stands for "integrated" :) and "updating independent targets" is one of P2's claim to fame? If the the fix can be extended to include subdirectories of "dropins", I think this fix has merit, to use with M6, and leave the "brand new" cases for later. Without extending to look at subdirectories of dropins, I think it would cause nearly as much confusion as no M6 fix at all. (Not as much .. but nearly as much .. and still be perceived as "missing function").
There's certainly all kinds of neat directions we can explore in 3.5. As you said, since p2 supports installing into other applications and non-running applications, it would be possible to set up a target application and install things into it directly from your dev workspace without ever starting the target. As Curtis mentioned in comment #22, there is planned support in 3.4 to provision target platforms directly from p2 repositories, so you will be able to set up your target platform without manually downloading and unzipping things at all.
+1, In reply to comment #26: > > I'd suggest you also check the use cases with P2 disabled ... It doesn't appear > the instructions at http://wiki.eclipse.org/Equinox_p2_Removal would change the > behavior of PDE back to it's previous self ... and, I just happen to know some > adopters are counting on restoring previous behavior -- at least temporarily. > (It may be fine, I'm just suggesting some thought and testing be given to it). > I just want to be able to use my 3.3 projects with 3.4. So far, it's a matter of hitting reload, when I'm very sure that I shouldn't need to. I'll check out the Jar when I get a chance to do a clean install (poss after a quick beer :)
This patch seems a workaround for PDE to digest p2-ized targets, but the end behavior is an approximation of the real solution. Could be good enough for now (like quick and dirty). Looking further, I feel that p2 should provide an API to compute a model of a target installation. This could be computed by running a provisionning operation (similar to what is performed during target startup) and producing some parallel /alternate metadata (not altering the target installation). This would avoid the need for PDE to try emulate p2, simply iterate a p2 model. To insist on parallel/alternate metadata, I would imagine that in the future, the client PDE/p2 may differ from the target p2, and thus having client provision the target could be an issue (think of 3.4 provisioning a 3.5 target app which would be missing some new 3.5 metadata for start level etc...). Having the client PDE/p2 produce the client side model for client side tooling (PDE/JDT) is ok, but it should not alter the running application, which should still perform its provisioning operation (using target implementation of p2). Last on this line, a p2 developer should be able to debug its starting target app, and put breakpoints in the code doing the first provisioning operation on startup; if it had been done already when configuring target, it would not allow to run the real thing any longer.
So, I've opted to go the preference route after thinking about this. The reason for this is because MOST people are accustomed to PDE scanning their target platform directories for bundles versus relying on something like the platform.xml In order not to break the majority of people's existing workflows, PDE will declare a new preference accessible via the Plug-in Development preference page. This preference will allow users to select whether or not they want PDE to attempt to inspect their target and mimick the target running instance if possible (ie., scan for a platform.xml or bundles.info file and use that to build the target platform list). This preference will be disabled by default, therefore PDE will attempt to just scan your directory for plug-ins just like it did in the past for the majority for users. If you wish to have PDE inspect your target a bit more and try to realize what it is actually running, you will have to enable the preference. I will have a patch ready for the next I-build, I just need to land in India first. If people have any issues with this approach, feel free to raise any complaints. I think this approach is the best one given the circumstances.
I met a problem about pde with p2 or without p2. first, I think it's p2 bug. But it may be a pde bug? I add a snapshot to show my case. If it's not, I will open a new bug.
Created attachment 94988 [details] pde_bug_with_without_p2 Note: this problem exists with both p2 and p2-removal(from M6). M5 is good in this case.
(In reply to comment #43) > This preference will be disabled by default, > therefore PDE will attempt to just scan your directory for plug-ins just like > it did in the past for the majority for users. If you wish to have PDE inspect > your target a bit more and try to realize what it is actually running, you will > have to enable the preference. > > I will have a patch ready for the next I-build, I just need to land in India > first. > > If people have any issues with this approach, feel free to raise any > complaints. I think this approach is the best one given the circumstances. > I agree this is the best approach, makes it clearer, and more evolutionary (in that people can learn from the interface ... instead of having to just hear or read about the different methods of using targets. I'll document a few "look and feel" issues that might be important ... though I suspect you have thought of them too. And, they are just ideas ... nothing radical, or too strongly felt. You may want the "preferences" to be closely tied to a pushbutton ... basically an "apply" action ... or, I guess the current "update" button would play this role? Perhaps preferences would be named, "update by meta data", and "update plugin search". I say all this since the way it it now, if you browse for a new location, the action takes place as soon as you select the location. I'm concerned now, that behavior requires the user know they have to select the preference first. (Not always easy) ... though, I guess they way this will work is that they could always pick the other preference and hit 'update' and it would still work ... that is, nothing in the target is changed. Its' just, if the big scan happens by default, upon selection ... it might take a long time to finish that first time, in a huge target project. Hope that makes sense (I shouldn't write this early in the morning :) Have a good trip.
(In reply to comment #45) > > Note: this problem exists with both p2 and p2-removal(from M6). M5 is good in > this case. > Jin, to be clear, do you mean P2 removed from your target? In fact, is your target a complete install? Looks almost like it might just be a few plugins? Maybe the experts can comment, but seems like for a long time I've had to have a complete install, as the target .... in which case, seems it should work, if P2 disabled in that target. (That is, it would do the whole scan -- besure to try the 'reload trick' others have mentioned in this bug). If you are expecting just "a list of plugins" to work as the target, then I'm not sure that is supported any more (at least, I haven't gotten that to work for a number of releases.
Re: comment 43 I don't see how this does address my concerns in comment 42. How can PDE emulate p2 story without help from p2 ? If p2 was offering support, would this preference still be necessary ? (the pref feels like a 'refresh/try harder' button... )
(In reply to comment #47) > (In reply to comment #45) > > > > Note: this problem exists with both p2 and p2-removal(from M6). M5 is good in > > this case. > > > Jin, to be clear, do you mean P2 removed from your target? In fact, is your > target a complete install? Looks almost like it might just be a few plugins? > Maybe the experts can comment, but seems like for a long time I've had to have > a complete install, as the target .... in which case, seems it should work, if > P2 disabled in that target. (That is, it would do the whole scan -- besure to > try the 'reload trick' others have mentioned in this bug). If you are expecting > just "a list of plugins" to work as the target, then I'm not sure that is > supported any more (at least, I haven't gotten that to work for a number of > releases. Hi,David. I try my case in M6 without p2, according to Equinox p2 Removal: http://wiki.eclipse.org/Equinox_p2_Removal. It seem that the PDE development environment doesn't automatically load all installed plugins(the default case before M6 is: all installed plugins in host is avaibable for pde using, no need to load/reload manually).
I think the preference approach is probably good enough for 3.4. The only problem I see is that many users will never know about the preference and won't be aware of the new functionality. It would be interesting when a target is set for the first time to scan both the directory and target metadata (bundles.info). If they are different, the user could be prompted to select a value for the preference ("The target directory contains bundles that are not installed in the target application. Do you want to include uninstalled bundles from the target directory in the target platform?") with Yes/No/Don't ask me again choices. Longer term, Philippe's suggestion of performing some p2 operation on the target is a better answer. PDE will never be able to perfectly emulate p2's discovery mechanism due to the complexity involved (potentially open-ended set of bundle pools, running the SAT-solver, etc). Ultimately this will lead to subtle bugs and confusion for PDE users when their PDE target platform doesn't properly emulate the actual target runtime environment.
Created attachment 95039 [details] org.eclipse.pde.patch There is a new preference now located on the target platform preference page. It's an a very obvious location that anyone who has worked with a target platform will see it. The value is off by default so PDE will always attempt to scan manually for plug-ins based on the directory set. This is the expected behavior that the majority of people have relied on. For those people who want to be able to work against a target based on its target configuration, they simply need to apply the preference and reload the target platform... viola! The PDE documentation will be updated based on this new preference. PDE has done a good job of not exposing implementation level details of realizing targets... but that process has turned into something magical and incosistent with user expectations... this preference should take away from some of that magic at least :) >20080407
Created attachment 95040 [details] mylyn/context/zip
Thanks for everyone's feedback and it's my hope this solution works for everyone.
I am not convinced we need a new preference to solve the problem. Who would ever want the behavior when it is turned off ? (pls educate me)
(In reply to comment #54) > I am not convinced we need a new preference to solve the problem. Who would > ever want the behavior when it is turned off ? (pls educate me) Philippe, for the longest time this has been people's workflow. That they can simply point to a target and have PDE scan the directories (and link files) to build a target platform out of. For example, it's common for people to download the SDK + WTP + EMF + GEF + (whatever other WTP deps) and unzip them to a place and then simply point your target platform there and have all the plug-ins appear in the target platform. After awhile, PDE added code when building the target platform to inspect the configuration of your target. This involved looking for a platform.xml file which is only available typically when you RUN YOUR TARGET before you develop against it. Most people just unzip files full of plug-ins and point, instead of actually running their target... so this functionality kind of went unnoticed by the masses in my opinion. The problem PDE hit in 3.4M6 with p2 is that the bundles.info (think platform.xml file) SHIPS WITH THE SDK... the target doesn't need to be run for this file to be there. PDE didn't think this all the way through and assumed the bundles.info would always mimick what the user wanted to develop against (similar to how it was the case with the platform.xml for the most part). So in order for not to break people's existing workflows, we added a preference that is off by default to please probably 99% of the community that relies on the traditional way of building a target platform. For those 1% who actually understand that PDE can build them a target platform based off their target configuration, they will now have to enable this. I see this as an acceptable compromise as PDE. If anything, most people don't realize PDE can realize a target platform based on a target's configuration... this was something that PDE did magically under the covers without a developers' awareness. I hope this explains it a bit better Philippe even though I'm a bit jetlagged now :P I believe the p2 team is happy with the fix along with the community of plug-in developers as am I.
(In reply to comment #55) > Philippe, for the longest time this has been people's workflow. That they can > simply point to a target and have PDE scan the directories (and link files) to > build a target platform out of. For example, it's common for people to download > the SDK + WTP + EMF + GEF + (whatever other WTP deps) and unzip them to a place > and then simply point your target platform there and have all the plug-ins > appear in the target platform. > +1 on this from me. I'm developing for OSGi, not for Eclipse, and therefore do not want to educate myself about Eclipse-specific behaviour. Now that Equinox is a top level project, perhaps we ought to aim for PDE to be a first class BDE (bundle development environment).
Since p2 has introduced an explicit mechanism to define which bunldes are installed in a runtime, I think we need a preference setting to control how the target platform is populated (installed bundles vs. all bundles present). However, I think the initial setting we have currently is not the right one. As well, I think the current wording of the setting is too complex/confusing for novice users. Using a timestamp fix feels like it could be too subtle and also cause confusion for users. Although most of the time things would just work the way they used to with the timestamp fix, there would be cases where people would get confused as the the behavior they are seeing and have no way to correct it from the UI/target platform page. I would suggest to have a check box preference as follows, that would by default be checked. "Only consider installed bundles/plug-ins vs. all bundles/plug-ins present at this location". For the WTP case this means a change in workflow - when they go to the target platform preference page, they have to uncheck the box (or we could have radio buttons to select the stragey used). I think this default setting (i.e. only considered installed bundles) plays better since in the p2 world where the target platform is the running platform by default, mulitple versions of the same bundle can exist for transient periods of time as new bundles are installed/garbage collected. In fact, the default seting for this preference could be different based on the location of the target platform - if the target platform is the default (i.e. the running instance of the SDK), the setting should be "only use installed bundles". if the target platform locatoin is no the default (i.e. some other directory), the setting should be "use all bundles at this location". Now - is it too confusing to have different preference defaults?
(In reply to comment #57) > Since p2 has introduced an explicit mechanism to define which bunldes are > installed in a runtime, I think we need a preference setting to control how the > target platform is populated (installed bundles vs. all bundles present). > However, I think the initial setting we have currently is not the right one. As > well, I think the current wording of the setting is too complex/confusing for > novice users. This is exactly what I have done... see the next i-build. We can argue about the wording, I'm open to newer suggestions. However, most novice users and even intermediate, are used to PDE just scanning directories to plug-ins. In PDE, we will have to improve our documentation to make people are of the differences here. In the past, we tried to do magic under the covers and we are at a point where we can't do that anymore. I personally can't find one case where a user is actually aware that PDE would be aware of the target's runtime configuration... so what we're doing here is right in my opinion.
(In reply to comment #58) > However, most novice users and even intermediate, are used to PDE just scanning > directories to plug-ins. In PDE, we will have to improve our documentation to > make people are of the differences here. In the past, we tried to do magic > under the covers and we are at a point where we can't do that anymore. I > personally can't find one case where a user is actually aware that PDE would be > aware of the target's runtime configuration... so what we're doing here is > right in my opinion. However, p2 is introducing a lot of new magic under the covers and is changing workflows (extracting != installing). It makes more sense to me to make the default behaviour change now, and provide the ability to do things the old way. I also think that the current wording is not satisfactory. It would add more crowding to the page (which is already a problem), but perhaps radio buttons describing the two possible behaviours would be of benefit. Darin was also suggesting that the default behaviour could be different based on whether you were pointing at the default location (the current SDK's folder) vs pointing at an extracted eclipse install elsewhere. This might make the right thing happen for everybody.
(In reply to comment #58) > This is exactly what I have done... see the next i-build. We can argue about > the wording, I'm open to newer suggestions. I'm just suggesting a refinement on this solution: (1) if the target platform's location is the default location (i.e. the running host), then the default bevaior should be "use installed bundles". (2) if the target platform's location is not the default location (i.e. some other external location such as in the WTP scenario), then the default behavior should be "use all bundles at this location". Things should work out of the box this way - and users would get better default behavior for the two different scenarios.
(In reply to comment #60) Can we open another bug for this issue to track the wording / preference issue? I believe we have the problem solved now, it's just a matter of how to present the information to the user by M7. I can go with a general preference in the Plug-in Development page that states: Build target platform using: * running (or installed?) bundles * all bundles
Sure - I have created bug 226037.
(In reply to comment #62) > Sure - I have created bug 226037. Thanks Darin. For everyone else, expect a blog entry and a new and noteworthy item to explain this functionality for users. This is an important concept for people to grasp... Thanks all for the feedback again.
Thanks Chris for explaining. My feel is still that the pref is a workaround for lack of p2 API for discovering proper target. If the API was around, I don't see why anyone would use the pref to prevent p2 discovery. Can PDE emulate enough of p2 behavior (99% usecase) until the p2 API shows up ? I guess I am concerned that tooling came short on this issue, and we are pushing the problem onto the user (go figure, and flip the pref as you want)... I guess this will be debated further in bug 226037.
Hi, I re-test my case toaday using m6(p2) and link files, my problem seem disappear. That is, the pde behaves in the same way as before. So, my snapshot maybe just show a unstable case.(I guess some cleaning work do this.) And so, my problem may be not a problem:) Jin
*** Bug 227200 has been marked as a duplicate of this bug. ***
