Community
Participate
Working Groups
PDE team is currently implementing an experimental alternative to the current models of selfhosting using classpath containers. The desire is to have all the flexibility of the binary projects without the need to actually use them. The usage of classpath containers will solve the problems of classpath stability when external JARs are used to express plug-in dependencies. We already have Plug-ins view that allows users to browse the hierarchy and the files of the external plug-ins. The view also supports clipboard and Drag'n'drop operations. What remains is the ability to search through for the types that are neither in the workspace (part of the Java project) nor are in the external libraries added to the Java project in the workspace. The desired implementation would need not be automatic - an API to add and/or remove the list of external JARs to the model indexer is all that is needed. PDE Plug-ins view shows external plug-ins already, so users would select those they want added to the search path. PDE would take their libraries as defined in the plug-in manifest and add them to the indexer lineup (as per users explicit action). Users could also remove them from the list if needed. It would be useful to provide a matching 'get' API so that PDE can inspect if a certain JAR is already in the indexer for the benefit of its own book-keeping. The list of external JARs would typically be a subset of all the external JARs because not all the external plug-ins would be interesting to users. For example, a frequent scenario is that developers of very large Eclipse products (several hundred plug-ins) work on a small set of plug-ins in the workspace, need to search (and hence index) somewhat larger set of about 30-60 plug-ins, but has no interest in the remaining plug-ins (still hundreds of them) that are only needed to run against. Since PDE may not be loaded when the search is initiated, an initializer similar to variables or classpath containers may be needed to ensure that the selected external JARs are communicated to the indexer. The use of the initializer would solve the persistence problem i.e. the list of external JARs set this way would only be used during the session. We would prefer the initializer because we would have a chance to account for session-to-session changes (for example, if external plug-ins are updated to newer versions, we would like to completely recompute the external JAR paths because they contain version numbers in directory names).
How would you simply achieve my willing to switch another plug-in from binaries to sources, without touching any classpath ?
I guess that's why you'd be using containers. One per plug-in. Now, the part you would loose is the classpath specificities. I guess my plug- in source project would have to provide the classpath to cover all prereq internals so as to allow me to browse prereqs' implementation in context. I don't think I would want this ever, and loosing the in context browsing would be a big step back I presume.
Closing, as per discussion with Dejan, we don't have to do this. The JavaModel needs actual resources underneath.
