Community
Participate
Working Groups
20021105: From a private mail: in our lab we update our workspace always to the very latest. This is a almost daily operation, so it would be good if this involves as less clicking as possible and can be done with a work flow as simple as possible. With the current solution (if I understood it right), we have to first open the preference page, set the 'Target Platform' to the latest build, then open the importer, browse for the same location and import. A warning on the importer is of course nice, but forcing me to press cancel and go back to the preference page is definitely frustrating. So what I think is the best solution is to either offer a check box on the first import page 'Update target platform location' which would allow me to avoid the preference page step or, after I pressed 'Import' to bring a dialog asking me if I would like to update, otherwise no source will be attached. As I wrote before, I can't see why you would import new plug-ins and set no source attachment (or use source attachments of a different platform directory) if there is obviously source available at the location of the plug-in import. I agree with you, don't do this behind the scenes, the user must be aware of settings changed. I would be very happy (and I think others in Zurich agree with me) if updating to a new build could be a simple 'use importer' work flow, and wouldn't force me to open the preference page. See also mail daniel meggert: I'd like to add my comments on this: I think the 80% case when people import from install A is that they want to get the source from/relative to install A. I think it should be an advanced feature to import from install path A and get source from another install. Possible nice behaviors for me would be: - I get warned if source install/location differs from my import location and can then either continue/cancel or set the source location Note: the importer should be smart and suggest/guess the new source location (from my import location) - the importer lets me select to use the source location preference or let the importer derive it from my current import location I know that other operations might depend on the source location preference but as Martin said the most common PDE operation that we use is importing a build.
We will look at this and provide a solution. As a side note, we would really like if you could give classpath container- based selfhosting a test drive. We feel that binary projects are necessary evil and would like to reduce their usage as much as possible.
Could you provide the steps how to setup classpath container-based setup instead of binary projects and - once setup - the steps to switch to a newer build?
We don't have enough confidence in classpath container-based self-hosting (there are some glitches we observed in JDT), so we didn't make it official. However, it already works pretty good. The steps are simple: all you need is to turn the classpath container selfhosting in PDE->Build Path Control preference page and recompute classpath for your source projects. The crux of the support is that PDE computes the classpath as: source folders + Plug-ins container + JRE_LIB Source folders are the same as today, as is JRE_LIB. The difference is that all the required plug-in mapping is replaced with one container that dynamically computes the actual entries depending on your workspace. For each plug-in reference, if the plug-in can be found in the workspace, a project reference is created. Otherwise, external JARs for the plug-in are returned. These entries are computed on the fly, so the only thing you need to do to switch to a new build is to change your target platform to point at a different build. If you are already on the 'right' build and just keep pointing at the same workspace (and hence you keep the default target platform option), you should be fine by just starting the platform. The key is in the delayed computation of the classpath entries - there is no stale/out of date information to repair. Using one classpath container in place of all the dependent plug-in entries provide for a stable classpath that can be shared in the repository. However, the fact that you didn't import dependent plug-ins as binary projects makes it harder to browse, search and otherwise manipulate these plug-ins. You should open PDE 'Plug-ins' view for this. It will allow you to: 1) Browse external plug-ins 2) Open external plug-in files (in read-only mode) 3) Copy external plug-in files using clipboard and drag'n'drop operations 4) Add/remove external plug-ins to/from Java Search In M3, you will also be able to perform 'Plug-in Search' that allows you to search for plug-in, fragment and extension point declarations and references across the PDE scope (workspace + external plug-ins). Final note: usage of classpath container-based selfhosting does not prevent you from using binary projects. PDE will automatically switch from external to workspace classpath entires (without any action on your part) when you import binary projects. The novelty is in that you do not NEED to do it in order to selfhost. You can reserve it for some special cases. Note 2: M3 also contains support for source attachements for dynamic classpath entries. Since real classpath entries are automatically computed by PDE, they are transient and source attachements are kept outside (in PDE metadata). This will allow you to make source attacements for the rare cases where automatic source association failed (e.g. Xerces).
then lets add another scenario: what are the steps to switch a project from binary to source or the other way around.
In container selfhosting, binary projects are typically not needed, so the initial scenario would be that only the source projects are in the workspace. To switch from using external plug-in to the source version of it, it is enough to extract the project from the repository. PDE will detect the change and notify JDT to ask for the classpath again (PDE computes dependent projects and knows what projects are affected by that step). To switch back, all that is needed is to remove the source project from the workspace. PDE will switch to using the external version. This makes one of the strongest appeals of the container-based selfhosting - automatic control of the classpath.
I tried the following with 2.1_M3 build: 0. Started fresh workspace (clicked on eclipse.exe) 1. Checked out org.eclipse.jdt.ui, org.eclipse.search, org.eclipse.compare 2. Set PDE preference to use classpath container 3. Selected plugin.xml in org.eclipse.search.ui 4. Selected "Update Classpath..." from its context menu 5. Pressed "Select All" 6. Pressed "Finished" ==> it started adding thousands of errors (autobuild on) Mote: - There was a "Required plug-in entries" entry on each projects build path but it was empty when I pressed "Edit". - nothing in .log - no Build path Problem in the task list Did I miss some steps to make my source compile?
You probably forgot to enable all the external plug-ins, so PDE cannot find anything to resolve plug-in imports. Enable external plug-ins in 'Target Platform' preference page.
Yes I forgot it. Maybe a hint upon enabling the classpath container based self-hosting would help since it's a requirement. I'll give it another try.
Here's my impression after setting up the workspace: I liked to be able to quickly switch from one drop to another by setting the target platform application location. I encountered 2 problems though: - I did not expect to press the "Reload" button after setting another location - the workspace was not rebuilt even though I had auto-build on I don't like classpath container based workspace setup because: - I loose the context i.e. I see lots of JARs but don't know where they come from - as you already pointed out, searching is harder. Just today I had to search for an action ID in my workspace (setup with binary projects): a simple text search over *.xml and *.java did the trick. With the classpath container setup I would have to start two searches and could not look at all results at once. - browsing via Package Explorer is harder if JARs are not filtered away because after expanding a project you get a huge list of JARs. - recognizing a JAR is hard because its most significant information (its name) is most of the time outside the view. Though this is also true for the rt.jar it is not a big deal because it is prefixed with "JRE_LIB" (in most peoples workspace setup). - I can no longer browse resources of external plug-ins (e.g. plugin.xml files, icons, templates, etc.) For now I prefer my existing setup with binary projects over the classpath container based setup.
Thank you for your feedback. I will try to address some of the concerns here: 1) The 'Reload' issue - it is a task flaw due to the cost of the 'Reload' operation. We will look at it and see how to make it more obvious. 2) Context loss - I don't know if we can address that - the JARs are coming from your target application (outside). 3) We can improve searching problem by working with other teams to expand the scope to the external plug-ins as well 4) Browsing via Package Explorer: true but it is easy to filter 5) recognizing a JAR: this is a Package Explorer issue (maybe something that can be tweaked from the drop-down view, like limiting the size of the path prefix, or replacing it with [external] token so that the name is visible 6) THIS IS IMPORTANT: You can still browse the external plug-ins. Just open the "Plug-ins" view provided by PDE and stack it with the navigator. You can browse layout, open files, copy and/or drag objects from it. Finally, I understand that for Eclipse developers with 60 or so plug-ins, the price of importing them all as binary projects is acceptible. Teams that work on Eclipse-based products (some of which have as many as 1000 plug-ins), absolutely cannot. For them, working with plug-ins in external form is everyday reality. Even if you feel classpath containers are not for you, give it couple more spins (try the Plug-ins view, for example) just to allow us to address some of the issues you will encountered (and you already raised some very valid ones).
>1) The 'Reload' issue - it is a task flaw due to the cost of the 'Reload' >operation. We will look at it and see how to make it more obvious. I think the reload button makes sense but reload should be done automatically if the user explicitly selects a new location via "Browse". Furthermore the button could give a hint in which situations a reload is needed (e.g. if I change the string then its a must and allowing the user to apply the setting makes no sense - at least in my case could enter a non-existing location, apply and confirm the preference page and got no feedback). >2) Context loss - I don't know if we can address that - the JARs are coming >from your target application (outside). What about the new link support? Unfortunately links are not allowed for projects (IProject) but maybe the contents of the binary projects could be replaced with links which could be easier updated to a new drop? >3) We can improve searching problem by working with other teams to expand the >scope to the external plug-ins as well There is not yet enough support from core to deal with non-workspace stuff, for example the search infrastructure is marker driven which can only be attached to resources. I guess this could be an option for 3.0 where we might change Search to be independent of markers. >4) Browsing via Package Explorer: true but it is easy to filter Yes, but if I filter I totally loose context (see 2): When I switch from one type to another (via editor) then the browsing perspective or the package explorer (assuming the backlinking is enabled) selects the first available parent of the type. Now, if I use binary projects and filter the JARs then it selects at least the correct project and I know where the type comes from. Doing the same with classpath container setup it will *randomly* select one of my source projects. >5) recognizing a JAR: this is a Package Explorer issue (maybe something >that can be tweaked from the drop-down view, like limiting the size of the >path prefix, or replacing it with [external] token so that the name is >visible Sure JAR name rendering could be changed in the label provider to something like: jdtui.jar - d:\eclipse_I20021119\plugins\org.eclipse.jdt.ui >6) THIS IS IMPORTANT: You can still browse the external plug-ins. Just open >the "Plug-ins" view provided by PDE and stack it with the navigator. You can >browse layout, open files, copy and/or drag objects from it. I admit I didn't try this view. But did just now. It solves my concerns partially. It would help if I could enable the linking as well i.e. if I open a type it selects the corresponding element (or parent) in the view. The problem I see, is that I now have to switch between Package Explorer and Plug-ins view (Plug-ins view does not allow me to drill into source projects while the Package Explorer neither shows resource projects nor external plug-ins). I guess the best would be platform support for an extensible navigator (most likely 3.0 ;-). >Finally, I understand that for Eclipse developers with 60 or so plug-ins, >the price of importing them all as binary projects is acceptable. Teams that >work on Eclipse-based products (some of which have as many as 1000 plug-ins), >absolutely cannot. For them, working with plug-ins in external form is >everyday reality. I totally agree and I confess to have less than 60 plug-ins in my workspace. For workspace with hundreds of plug-ins the import approach is not feasible. >Even if you feel classpath containers are not for you, give it couple more >spins (try the Plug-ins view, for example) just to allow us to address >some of the issues you will encountered (and you already raised some very >valid ones). I'll do that. Other observations: - I can filter away binary projects *without* filtering the JARs (I might want to see my rt.jar but not the binary stuff) - just curious: what happens if I checkout a project with classpath container based setup/.classpath file into a workspace where this option is not enabled? - JDT UI should improve the rendering of JARs contained in a classpath container: it should show the container as a node in the tree
We addressed the original problem by adding the 'Change...' button in line with the checkbox in the import wizard page. The main workflow should now be to keep the default checkbox checked and change the target platform using the 'change...' button. You should only uncheck the checkbox and select alternative location if you are importing unrelated plug-ins that are not a full drop (because this flow does not include registry resolution step, which means that all the plug-ins are shown as choices without any constraint checking). What we did is simply brought the target platform page closer to you so. Under the covers, we are creating a PreferenceDialog and adding just one page node (just one you need to modify). I am resolving this defect as fixed (the code is in and you will see it in the next integration build). I opened 27472 to preserve the discussion about classpath containers.
