Community
Participate
Working Groups
Using 3.1I20040814 A 3.0 plugin that references IConsoleHyperlink won't build (might not run, I'm not sure) because : 2 The type org.eclipse.ui.console.IHyperlink cannot be resolved. It is indirectly referenced from required .class files The problem is that IConsoleHyperlink implements IHyperlink which is defined in the org.eclipse.console.ui plugin. This is a new plugin for 3.1, so my current plugin doesn't depend on it. org.eclipse.debug.ui may need to re- export org.eclipse.console.ui to maintain compatibility (or some kind of compatibility shim may be needed).
The console plug-in is not new in 3.1 - it exists in 3.0. However, we will need to re-export it to make it backwards compatible with the new console implementation.
Fixed by re-exporting org.eclipse.ui.console.
Please verify, Kevin.
verified (Sorry Ed, thanks for the report)
I got around to trying 3.1I20040814 with the old plug-in and it works just fine at run time. I had been assuming it would fail at runtime but that wasn't the case. I thought org.eclipse.console.ui was new but that wasn't right either. For something like this which works at runtime but fails at compile time in the new version, is that considered an API break? I'm not sure. The reason I ask is that I hate re-exporting plugins if it's not absolutely necessary. Remember all that trouble with 3.0 compatability caused by all the reexports that 2.1 was doing? In this particular case, by making my plugin dependent on org.eclipse.console.ui I can have it work at compile time as well as run time in 3.0 and 3.1 without you having to reexport. So that might be a better solution than reexporting. Reopening for your consideration now that I understand what's going on. Sorry about the false assumptions.
CC Darin for comment #5
For M2, I have reverted the change. CC'ing Jim for comment.
Darin/Kevin, Could you give me a synopsis of the changes you were attempting to make?
In 3.1, we are extending the generic console (org.eclipse.ui.console) with function that previously existed only in the debug platform (org.eclipse.debug.ui). In this case, we pushed the hyperlink functionality down into the console plugin. Thus, org.eclipse.debug.ui.console.IConsoleHyperlink used to extend nothing, but now extends an interface from the console plug-in, org.eclispe.ui.console.IHyperlink. Thus, when compiling, the console plug-in now needs to be on the buildpath if you previuosly referenced IConsoleHyperlink.
First off, let me concur with Ed's remark in comment #5 that re-exporting API is a bad idea, and should only be done if unless absolutely necessary. I don't believe this kind of change breaks binary compatibilty. Ed's comment #5 confirms this is the case. What I don't understand is how this change could break source compatibility. Suppose the 3.0 version of your plug-in A is in the workspace in source form. Plug-in A requires o.e.debug.ui plug-in. And plug-in o.e.debug.ui plug-in requires o.e.ui.console plug-in. This was true in 3.0, and is still true in 3.1. Regardless of where o.e.debug.ui and o.e.ui.console are (in workspace or outside), and regarless of their version (3.0 or 3.1), PDE should be able to compute a build classpath for plug-in A that includes both plug-ins. Why is this not happening?
Mistakenly, we changed FileLink to implement IHyperlink. I reverted to IConsoleHyperlink since FileLink is an API class. However, this does not fix the compilation error problem. I will move this bug to PDE for investigation.
Created attachment 14750 [details] zip of project demonstrating problem
Moving to PDE. The attchment in comment#12 is a plug-in that pre-reqs debug.ui (and others). It creates an IConsoleHyperlink, and tries to add it to an org.eclipse.debug.ui.console.IConsole. This creates a compilation error: "The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.ui.console.IHyperlink." However, we do not think there should be a compilation error.
(NOTE, you should use the latest code in HEAD for org.eclipse.debug.ui, or the M2 build).
This is the same issue as bug 61602. Please refer to that bug report to see why these things are happening. I'm not sure what to do about this problem. If we put everything on the classpath, too many types would be available in code assist. If we remain strict on what goes on the classpath, you get errors like that at development time, but not at runtime.
Do you mean that if plugin A depends on plugin B, and B depends on C, that A has to know about C and explicitly depend on it as well? And that if B changes to depend on D that A has to be changed to also depend on D? That can't be right; it would break the whole idea of loose coupling.
Certainly not what I meant. Let me elaborate... Your plugin X uses the type IConsoleHyperlink from debug.ui and so it must declare it as a dependency and it does. When computing the classpath of X, PDE puts the following: 1. All the JARs from X's direct dependencies as they appear in the plugin.xml/manifest.mf. 2. All the reexported dependencies of plugins in 1. Since org.eclipse.ui.console is not reexported by debug.ui, then PDE does not put console.jar on X's classpath. Now at development time, when code is plugin X is being compiled, the reference to type IConsoleHyperlink is encountered. the compiler looks for it and finds it in dtui.jar, which is on X's classpath. All good. Note that IConsoleHyperlink implements IHyperlink. So the compiler now needs to find IHyperlink. Since that type is not on X's classpath as per points 1 and 2 above, you get the compiler error that you see. This problem does not occur at runtime, because the classloader of plugin org.eclipse.debug.ui is the classloader that tries to load IHyperlink and it will of course succeed in finding it because org.eclipse.ui.console is a direct dependency of org.eclipse.debug.ui. So as it stands, at development time, we cannot simulate exactly what happens at runtime. One hack would be to "unnecessarily" re-export org.eclipse.ui.console. Another one would be for your plugin to explicitly require org.eclipse.ui.console. Neither hack is desirable. One suggestion in the past was to put all the JARs from the entire depedency tree (reexported or not) on X's classpath. This will certainly get rid of this particular error. However, all these types will become available to you in your code assist, so you will start using those types thinking they are all available to you at runtime, which may not be the case. Enter a bunch of runtime classloading errors. What we need is a delicate balance: All the JARs should be on the classpath so that we don't get false compiler erros like this one. Yet, we only want classes from sources 1 and 2 (listed above) to be available in the code assist. Unless JDT/Core comes up with a mechanism to enable this scenario, I am afraid there is not much PDE can do, and we will keep having this conversation over and over again.
Ok, so just to make sure I understand, you're saying comment #16 is not correct at RUN time but it is currently correct at DEVELOPMENT time, right?
It is certainly not true at runtime. It "may" be true at development time depending on what types you use from debug.ui. If you use types like IConsoleHyperlink whose superclass comes from a different non-reexported plugin, then yes. The PDE/UI plugin depends on debug.ui on the other hand, but needs to know nothing about debug.ui's pre-reqs because it does not use such types.
*** Bug 46255 has been marked as a duplicate of this bug. ***
*** Bug 79966 has been marked as a duplicate of this bug. ***
*** Bug 82522 has been marked as a duplicate of this bug. ***
cc the JDT guys as we would need some new form of support from them to avoid such scenarios.
Access restrictions look something you could investigate using there. The offending JAR could be offered with proper access restriction (exclude all from it) so that any attempt to directly refer to it would be immediately flagged.
brilliant! thanks :-)
Philippe, access restrictions certainly solve the busted type hierarchy and false compiler errors issues. Also, when I try to access these restricted types from my plugin, the types do get flagged when I save (warning, by default - which is a pretty soft severity level in this case). However, this is not sufficient because the restricted types are readily available to me as options in my code assist. This opens the door to many potential classloading errors at runtime, if, for example, the severity level is reduced by the user to IGNORE. Ideally, we want the restricted types to not even appear in the code assist as to not invite them to do something they shouldn't be doing. Has such a request been made against JDT yet?
*** Bug 87661 has been marked as a duplicate of this bug. ***
*** Bug 90234 has been marked as a duplicate of this bug. ***
*** Bug 92117 has been marked as a duplicate of this bug. ***
*** Bug 93539 has been marked as a duplicate of this bug. ***
What about multiple versions of the same bundle? Here is what I mean. My bundle requires bundle "otherBundle" which in turn requires specific version "1.2.3" of bundle "libX". "otherBundle" does not reexport libX. My bundle requires "libX" too, but it needs version "2.3.4 or better" which, of course, is not 100% compatible with "1.2.3". I do not see how "flat" class path with access rules can deal with such setup -- either my bundle will be compiled against wrong version of libX or otherBundle will be used with wrong version of libX for things like codeassist. There are couple of variations on this theme. First, my bundle can include libX's jar (i.e. Bundle-ClassPath: libX.jar). Second, different versions of libX bundles can be named differently (org.apache.commons.logging vs. org.apache.jakarta_commons_logging).
*** Bug 124295 has been marked as a duplicate of this bug. ***
*** Bug 119203 has been marked as a duplicate of this bug. ***
*** Bug 91869 has been marked as a duplicate of this bug. ***
*** Bug 133321 has been marked as a duplicate of this bug. ***
> Since org.eclipse.ui.console is not reexported by debug.ui, then PDE does not > put console.jar on X's classpath. This seems to be the basic problem. debug.ui should have its own classpath which does have console.jar on it. Does the compiler only compile using a single classpath? In the case where it is looking for IHyperlink, could it not use IConsoleHyperlink as a stepping stone to some other classpath that would contain IHyperlink?
The problem is that sometimes a stepping stone in the hierarchy is missing from the workspace (ie. no plugin project in the workspace directly references it). This results in a "busted" hierarchy and causing the compiler to complain.
> The problem is that sometimes a stepping stone in the hierarchy is missing from > the workspace (ie. no plugin project in the workspace directly references it). > This results in a "busted" hierarchy and causing the compiler to complain. Are you saying that importing debug.ui as a binary project fixes the problem?
I would expect it to fix the problem, yes.
(In reply to comment #40) > I would expect it to fix the problem, yes. > ... unless you hit bug 142023
> I would expect it to fix the problem, yes. In that case, can the PDE create "hidden binary projects" with their correct classpaths to fix the problem?
There is another minor problem that this bug's solution might address. Let's say I'm trying to find references to some platform API method, but I only want to search my *own* code. I just tried this by restricting the search view to a working set containing a couple of *my* project. However, all of my own projects include the JARs of every dependent plug-in. So, I got tons of search hits to calls to this platform API from the platform itself, which was not my intention. If PDE creates hidden/filtered projects for each dependent bundle, the JARs would be associated with those projects, whose JARs wouldn't pollute my own projects. If I were developing for a non-PDE target (basic java app), I might create a couple of library-only Java Projects, and then add project dependencies, rather than add the same JARs into each of my projects. BTW, I'm aware of the workarounds to the problem I've described here, which include modifying or creating search-specific workingsets.
Randy, the search hit issue you're referring to is unrelated but captured in bug 78416 As for this bug, a solution involving creating binary projects won't scale. We will end up with potentially hundreds of binary projects. Hidden or not, they're in your workspace. We are continuing to investigate feasible ways to address this issue that would involve augmenting the classpath with JARs without giving you more than what you really have access to in your content assit.
I didn't realize a hidden project with one JAR in would be that much more costly than the same JAR appearing in many projects referencing it. A hidden project solution would not necessarily have to be 1 project per plug-in. Each hidden project could contain sets of plug-ins using some yet-to-be-discovered graph analysis of the dependencies of the workspace plug-ins.
I tried the solution implied in comment #40, for my problem, originally described in bug 92117. And, it did not help. Same error: "The type org.eclipse.debug.core.ILaunch cannot be resolved. It is indirectly referenced from required .class files" (I tried both debug.core and debug.ui and it did not help). So ... I wonder if that's a different problem? Perhaps depending on the exact order projects are imported into the workspace, or something? (I only mention that, since some people on the project seem not to have the problem, but others do).
> So ... I wonder if that's a different problem? Perhaps depending on the exact > order projects are imported into the workspace, or something? I definitely saw ordering issues. For example, when I open a .class file that is in multiple projects, Eclipse seems to pick one, and then if that project can't see classpaths required by that .class file, things are all messed up. How Eclipse chooses to which project that .class belongs is a mystery to me.
I have been having this problem as well, and I found this bug report. However, I've read it a few times and I am embarrassed to admit I can't tell how this was resolved. The bug has been silent for four months, so I gather there was a satisfactory conclusion, but from reading this I can't tell how I'm supposed to fix this. The workaround, of course, is to explicitly depend on all packages that "should" be classed as implicit dependencies, but surely there is a better way. Can someone please clarify this for me?
*** Bug 172679 has been marked as a duplicate of this bug. ***
I will rename the bug report to correctly reflect the actual situation. I have tried to explain the problem to the best of my abilities in comment 17 and comment 19. The classpath is correct, but the type hierarchy is not complete so some of the jdt functionalities don't work properly as a result. To summarize, we have two unpleasant options: 1. Import the entire universe (ie. all plug-ins) into the workspace. 2. PDE would recursively add JARs which are not supposed to be directly on a plug-in's classpath so that it maintains the completeness of the type hierarchy. I am hoping we don't have to resort to this option since it may open a big can of worms (e.g. content assist becoming too generous, plug-ins referencing code they do not have access to at runtime, etc.) As for comment 32, the multiple version issue is unrelated to this problem.. In any event, since you can specify what versions you want to be wired to, PDE will hook you up correctly.
- I open a .class file. - The associated JAR appears in multiple Java Projects - One of these projects is randomly chosen, and that .class is given the classpath of the randomly chosen project. I don't see how the classpath is correct. The classpath might be correct for the plug-in, but each plugin dependency JAR inside that project should have a different classpath, based on that dependent plug-in, not the plug-in that is using it. Even the union of the classpath of all the Projects containing the associated JAR is not sufficient. The JAR needs to be in its own project with its own classpath that reflects what its plugin can see. I think there is a 3rd option. Create a single hidden project which contains all referenced JARs (and the JARs they reference). "Real projects" depend on that hidden project using access rules which reflect what the project's plug-ins can see from this global set of all available dependencies.
This problem continues to affect plug-in developers and breaks some nice features in the PDE tooling. In one of my plug-ins I ask the PDE to find unused dependencies, and then to remove them. But as soon as I recompile I get invalid compiler errors stating that an indirectly referenced .class cannot be seen. It's the same problem as always: class dependencies C -> B* -> A* (*B and A are Types from external libraries) B appears in the classpath of multiple projects, but one project is chosen at random, and that project does not have visibility to see A (because that project references X and not B). The Workaround: Import the plug-in containing B as a binary project, which will have visibility to A. JDT will now resolve type B to that project, and then can see A as well. Possible PDE solution #1: Add *all* jars to the plug-in dependencies, even for those plug-ins that are not exported. Then, use access ruled to re-hide the Jars/packages/types that should not be visible to the code in the project. But, will this work, or will the binary types in one JAR be subject to the same access rules as the project's source? If so, could this be changed in JDT? Possible PDE solution #2: There is a known workaround above. The PDE could automatically employ this workaround and import the binary projects for the user, preferably only as needed. Possible PDE and JDT solution: Same as PDE solution #2, but the binary projects are hidden from the user, maybe even created in the metaarea instead of the workspace root. Or, something less than a project is used. Something like a dependency graph of "classpath nodes" instead of a flat list of libararies. Possible JDT solution/band-aid: When the compiler is looking for type A from B, it tries all classpaths which have B, and not simply the first one that it finds. I'm not sure if helps in all cases.
(In reply to comment #52) > In one of my plug-ins I ask the PDE to find unused > dependencies, and then to remove them. But as soon as I recompile I get invalid > compiler errors stating that an indirectly referenced .class cannot be seen. This sounds like the problem being discussed in 208844. For problems dealing with unused dependency calculations, please comment in that bug so we can try to keep things straight :) After finding that some instanceof of and some other simple calculations were not efficient when scaling, I find it hard to believe adding all the jars in a target platform to a classpath would be a good idea. When your target platform has over 1000 bundles, and some bundles have 10 jar associated with it, each classpath could become astronomically huge! I would tend to lean toward one of the other options just because this one sounds ugly performance wise.
*** Bug 155450 has been marked as a duplicate of this bug. ***
Reducing to major as the SDK has shipped many times with this issue.
> This sounds like the problem being discussed in 208844. For problems dealing > with unused dependency calculations, please comment in that bug so we can try > to keep things straight :) There may be other bugs in the dependency calculations, but in my scenario it was doing the right thing, and compilation failed afterwards because of this issue. There are plenty of other functions failing too all as a result of this bug, *even* when your workspace doesn't have compile errors in it: - F3 to open on selection fails when the class can be opened using Open Type - CTRL+T fails to show hierarchy when the class can be opened using Open Type - content assist in the debug variables view fails to show proposals - execution/inspect/display of valid code fails in the debug variables view - (I suspect) javadoc view fails to show javadoc for selected method, etc., etc. And these problems came after introducing false dependencies to my plug-ins, which by itself is a real problem. The introduction of unnecessary dependencies and the sheer number of affected downstream features in eclipse is enough to make this critical, IMO.
(In reply to comment #56) > > This sounds like the problem being discussed in 208844. For problems dealing > > with unused dependency calculations, please comment in that bug so we can try > > to keep things straight :) > > There may be other bugs in the dependency calculations, but in my scenario it > was doing the right thing, and compilation failed afterwards because of this > issue. There are plenty of other functions failing too all as a result of this > bug, *even* when your workspace doesn't have compile errors in it: > > - F3 to open on selection fails when the class can be opened using Open Type > - CTRL+T fails to show hierarchy when the class can be opened using Open Type > - content assist in the debug variables view fails to show proposals > - execution/inspect/display of valid code fails in the debug variables view > - (I suspect) javadoc view fails to show javadoc for selected method, etc., > etc. > > And these problems came after introducing false dependencies to my plug-ins, > which by itself is a real problem. > > The introduction of unnecessary dependencies and the sheer number of affected > downstream features in eclipse is enough to make this critical, IMO. > While I have not looked at the details of what's causing this, it seems that it's possible to know that we are in this situation with a given file, and if that's the case, perhaps we can give some indication to the user as to what's going on and suggestions of how to fix it. Right now what happens is not very helpful.
This bug has been open since 2004. Are we ever going to get to it? Should it be marked as helpwanted?
Help from Wassim for sure <g> I suspect this scenario could be improved using forbidden access restrictions (i.e. add more to the buildpath to satisfy JDT type resolution, but prevent access from user code). I had the impression these sorts of issues had been all resolved when we introduced access restrictions.
(In reply to comment #59) > Help from Wassim for sure <g> > Just when I thought I was out, they pull me back in :) http://www.youtube.com/watch?v=FKR3QU3dB0M I will take a look at this problem for 3.5 and see if this issue can go away using the latest JDT technology. Worst thing in the world would be to solve the problem at the expense of seeing more stuff in the code assist than they should.
Fixing bug 194777 would at least flag that a bundle is missing.
More symptoms (I'm 80% certain): In the editor for a "problematic" Class: - Invisible breakpoints: Breakpoints can be toggled, but their existence is not reflected in the editor's "gutter". You have to open the breakpoints view to confirm that you actually created a breakpoint. - Toggle Breakpoint on a method fails (with a beep). I thought it would go to the first real line of code and put the breakpoint there for you. (Note: I think a "problematic" class is one that appears as a binary dependency of two+ projects, and has "dependencies" on other Types that are not in the dependencies of one or more of those projects.)
*** Bug 264116 has been marked as a duplicate of this bug. ***
*** Bug 264115 has been marked as a duplicate of this bug. ***
*** Bug 222296 has been marked as a duplicate of this bug. ***
Removing 3.5 milestone. This problem could be addressed by adding all required plug-ins to the plug-in classpath container (not just plug-ins that are visible), and adding access rules such that clients do not see code completion in the non-visible plug-ins. However, after consulting with the JDT Core team, there is concern that such a solution would have performance impacts on search and type hierachy generation, as the search scope for operations becomes larger. If the user doesn't scope the search, there will be many more potential matches in the required plug-ins. I would prefer to see this problem tacked early in a release, rather than the end of a release.
I've run into a situation similar to this issue when moving from 3.4 to 3.5. I've got a large OSGi-based system, and some problems popped up in 3.5 that weren't present in 3.4. The real-world situation is as follows: * Bundle A imports org.osgi.service.component * Bundle A does NOT import org.osgi.framework * Class in bundle A calls ComponentContext.locateService(String name) * Class in bundle A does NOT call ComponentContext.locateService(String name, ServiceReference ref) This worked fine in Eclipse 3.4. In 3.5, however, the call to ComponentContext.locateService(String name) gives me the error: "The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files" I dug into this a bit deeper and found some stuff. There seems to be a case when a method exists that is overloaded in the following manner: * method1(AvailableType param) * method1(AvailableType param, UnavailableType param2) Assuming AvailableType is visible to my bundle, but UnavailableType isn't, calls to the first method will fail in Eclipse 3.5 but succeed in Eclipse 3.4. Another scenario: * method2(int param) * method2(int param, UnavailableType param2) A call to "method(123)" will work in both 3.5 and 3.4 And finally: * method3(Object param) * method3(Object param, UnavailableType param2) A call to "method3(anyObject)" will fail in both 3.4 and 3.5 (with a same "indirectly referenced from required .class files" message) I'm attaching an archive containing three bundle projects that demonstrate these things.
Created attachment 137730 [details] Contains three bundles that demonstrate the scenarios outlined in my previous comment
(In reply to comment #68) > Created an attachment (id=137730) [details] > Contains three bundles that demonstrate the scenarios outlined in my previous > comment That's a great example showing your problem. But if your problem is between 3 projects all loaded as source, I'm not sure it's the same problem. That's good news for you, since you should be able to file a separate bugzilla and get it resolved sooner, especially since there seems to be a regression from 3.4. It sounds like the bug you've found is related, in that it may make the symptoms of this bug occur more frequently.
> I've run into a situation similar to this issue when moving from 3.4 to 3.5. > I've got a large OSGi-based system, and some problems popped up in 3.5 that > weren't present in 3.4. The real-world situation is as follows: I'm curious, did you also change (perhaps accidentally) from a JRE 1.4 to JRE 1.5 at the same time? > * method1(AvailableType param) > * method1(AvailableType param, UnavailableType param2) Because in "Java 5", you can declare: * method1(AvailableType param, UnavailableType ... param2) which could be why the JDT is suddenly more aggressive when it comes to bindings your method calls.
(In reply to comment #69) > (In reply to comment #68) > > Created an attachment (id=137730) [details] [details] > > Contains three bundles that demonstrate the scenarios outlined in my previous > > comment > > That's a great example showing your problem. But if your problem is between 3 > projects all loaded as source, I'm not sure it's the same problem. That's good > news for you, since you should be able to file a separate bugzilla and get it > resolved sooner, especially since there seems to be a regression from 3.4. > > It sounds like the bug you've found is related, in that it may make the > symptoms of this bug occur more frequently. > Thanks Randy. Any idea what product I should file this bug under?(In reply to comment #70) > > I've run into a situation similar to this issue when moving from 3.4 to 3.5. > > I've got a large OSGi-based system, and some problems popped up in 3.5 that > > weren't present in 3.4. The real-world situation is as follows: > > I'm curious, did you also change (perhaps accidentally) from a JRE 1.4 to JRE > 1.5 at the same time? > > > * method1(AvailableType param) > > * method1(AvailableType param, UnavailableType param2) > > Because in "Java 5", you can declare: > > * method1(AvailableType param, UnavailableType ... param2) > > which could be why the JDT is suddenly more aggressive when it comes to > bindings your method calls. > (In reply to comment #70) > > I've run into a situation similar to this issue when moving from 3.4 to 3.5. > > I've got a large OSGi-based system, and some problems popped up in 3.5 that > > weren't present in 3.4. The real-world situation is as follows: > > I'm curious, did you also change (perhaps accidentally) from a JRE 1.4 to JRE > 1.5 at the same time? > > > * method1(AvailableType param) > > * method1(AvailableType param, UnavailableType param2) > > Because in "Java 5", you can declare: > > * method1(AvailableType param, UnavailableType ... param2) > > which could be why the JDT is suddenly more aggressive when it comes to > bindings your method calls. > Nope, we've been using 1.5 for the life of the project. I also tested my example in Eclipse 3.5 with compliance level set to 1.4 and it's still broken. I'll open another report; should I open it under the PDE project? Thanks, Jeremy
(In reply to comment #71) > Nope, we've been using 1.5 for the life of the project. I also tested my > example in Eclipse 3.5 with compliance level set to 1.4 and it's still broken. > I'll open another report; should I open it under the PDE project? Please open the bug under JDT. Since the build path created by PDE is the same in 3.4/3.5, I think JDT/Core (compiler) needs to investigate.
Jeremy - I believe your issue is covered by bug 275471 Please try the latest 3.5 build to see if your problem is 'fixed'. If its not fixed then open a bug against jdt/core - but fixes for java 1.5 problems cause the compiler to resolve type references sooner than we did in the past. FYI - from a compiler standpoint, declaring 2 methods such as : locateService(String name) locateService(String name, ServiceReference ref) When ServiceReference is not available to ALL users causes build failures. The compiler does not consider argument count before resolving each parameter type. So... name your methods with unique selectors! ;)
>Jeremy - I believe your issue is covered by bug 275471 Mmmh, he claims to see the problem using Build ID: I20090528-2000, see the new bug 278745 he filed for this issue.
Is there any progress on this? The PDE is pretty much broken without a fix for this. Any enhancements being done for "[target]" functionality have less value if developers must import target bundles into their workspace.
(In reply to comment #75) > Is there any progress on this? No, unfortunately there were not enough resources to work on this during the 3.7 cycle.
*** Bug 373187 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
