Community
Participate
Working Groups
In M5 WorkspaceModelManager.isBinaryPluginProject() should not have to consult with the Team plugin to discover whether or not a project is binary. There is a property on projects which specifies this (the one used by the binary project decorator) This is causing the Team plugin to be activated prematurely.
A corollary to this is that the amount of work required to implement the binary project filter is too large. In a workspace with some binary projects but non- visible in the UI (due to a binary project filter), we still have to activate PDE Core and load over 150K (40+ classes). The user may have no intention of using anything related to PDE (other than the binary project filter).
Every now and then we get into this discussion on whether people would want to use PDE or not. Two of the most used functions are binary project importing and second instance launching. Both will cause PDE to load. So to claim that you might want to filter binary projects but not load PDE is not very realistic. Even if you use an already set up workspace you will load PDE the moment you want to launch. On to the main question: we didn't make the dependency lightly. When team replaces the binary project with the project from repository, they do not delete the project. Instead, they delete project contents and modify its description, but the properties stay. If you follow project property only, you will continue to claim that a project is binary even though its content has been replaced with the repository files and folders. Nevertheless, the entire 'binary project' test can be scripted, and we do it in case of the lightweight decorators. So the solution here would be to have lightweight filters that would have their filtering logic declared in XML.
There is another reason we use Team: we register our own repository provider for binary projects that have been imported with linking. Since the linked files are the ones from the target platform (and in the default case, from the very Eclipse you are running), we use move/delete hooks in the provider to veto modifications that would corrupt the target platform. This part of the dependency cannot be scripted. I would conclude that a lightweight filter would be a way to go here, and not looking for a way to break PDE->Team dependency.
I want to use PDE. I imported a bunch of plugins as binary projects. Shut down and then restarted. I used PDE in the past but not I pay for it even though I have not used any PDE functionality. But wait you say, you have, you enabled a binary project filter. True. My only point with this report is that if we can figure out how to decorate projects just by looking at properties etc, we should be able to figure out how to filter them using the same logic. Doing this would still have PDE getting activated. That's ok since, as you point out, we don;t have a lightweight filter mechanism (I entered a bug report about that too). But the amount of work done could be about 4 lines of code that would not in any way reference/touch Team or much else of PDE (i.e., PDE Core is likely not needed either). This comes down to understanding this use case for PDE UI being activated and trying to reduce its foot print. I believe this to be a common case as I often run with binary projects (filtered out) and in any given session may or may not invoke PDE proper.
PDE dependency on team is not only for 'isBinaryPluginProject' - there is also a repository provider we register. Since team is loaded simply due to its presence in the dependency list, we would have to elliminate any need for team classes to get rid of it. Since we cannot, the only solution would be a lightweight filter. In 2.2, we can take a look at PDE UI as a whole and see if we can further partition it into smaller plug-ins. PDE has a wide range of artifacts (editors, views, launchers, wizards etc.) and a careful partition may reduce startup costs in some scenarios.
The previous comment was based on the (false) assumption that plug-ins are loaded based on the dependency list. In fact, plug-ins are loaded as a result of class loading, which means that all that is needed is to not make references to team classes in the filter. We reworked the filter to perform the equivalent of the lightweight filter logic (project properties test only). We don't even reference PDE Core classes.
