Bug 27472

Description Dejan Glozic 2002-12-01 14:55:27 EST

This a cover defect to allow bug 26040 to be closed:

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.


------- Additional Comment #10 From Dejan Glozic 2002-11-19 13:04 ------- 
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).


------- Additional Comment #11 From Daniel Megert 2002-11-20 03:38 ------- 
>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