Community
Participate
Working Groups
Recommended 3.2 enhancement: Given a compile error that could be resolved by adding a dependency from the current plug-in to another plug-in in the workspace, it would be great to have a quick-fix that would offer to do just that.
I'll think about this ;) The problem is that we will have to analyze specific errors coming from JDT and offer a quickfix. What do you rate the difficulty on this one Wassim :)? Also, what are your thoughts on this one Brian. Is there any code to be pruned from the automated management of deps that we can use for this?
Depends on what kind of compiler error you are talking about. If it is when you have just a classname, then I would say PDE should not provide a quick fix. I think instead we should listen for the JDT to add packages to the source file. PDE should not be responsible for displaying all the relevant matches. Instead, it should listen for when the user selects a match and see what it might be able to add to the Manifest. Anything PDE provides would have to be based on the dependency management. Therefore, all the classes would already by on the buildpath. The other compiler error I could think of is if an imported fully qualified class could not be resolved. The only way this could happen is if the dependency management was not set up right. For PDE to search every plug-in to try to add it to the Manifest would probably be slow. For this reason, I tend to lean towards the statement that any quick fix/searching we do, is based on dependency management. If we do base it dependency management, that leaves us with the only compiler error being the first one mentioned. If that is the case, I think we should be listening to the JDT for additions/marker resolutions instead of providing a quick fix. We should not be in the business of resolving class names and trying to find possible matches. If we can listen to the JDT for this event and get the qualified class name which was just added, we should be able to do some work and be able to add it to the Manifest (if necessary).
*** Bug 194142 has been marked as a duplicate of this bug. ***
resolving it via Import-Package would be pretty easy/fast, since we would just add it and the let the state wire it. Doing it via Require-Bundle would be more work.
I don't think 'automated management of dependencies' should play a role here.
There is already resolution info in the markers. Well, at least in Java editor: public class PDEDependencyResolver implements IQuickAssistProcessor { public boolean hasAssists(IInvocationContext context) { return true; } public IJavaCompletionProposal[] getAssists(IInvocationContext context, IProblemLocation[] locations) { List proposals = new ArrayList(); for( int i = 0; i < locations.length; i++ ) { IProblemLocation location = locations[i]; String[] arguments = location.getProblemArguments(); int id = location.getProblemId(); switch(id) { case IProblem.UndefinedType: case IProblem.UndefinedName: proposals.add(new PDEDependencyProposal(arguments[0], context, 0)); break; case IProblem.IsClassPathCorrect: case IProblem.ImportNotFound: proposals.add(new PDEDependencyProposal(arguments[0], context, 0)); break; } } return (IJavaCompletionProposal[]) proposals.toArray( new IJavaCompletionProposal[proposals.size()] ); } Maybe additional work will be needed for xml editor, but that is less interesting. Note that PDEDependencyProposal will need some UI to allow user to choose required bundles/packages in case of ambiguity (say, you need to resolve "Listener" class). Still, I think it is fairly simple - just show qualified class name and plugin it came from. "Open Type" dialog has this info and maybe it could be somehow reused for this task.
If we try to resolve it with Require-Bundle, I think the 'automated management of dependencies' should play a role. Since multiple bundles can export the same package, we should check the list in the AMOD section first to see if any of the bundles the user has configured satisfy the dependency. If we don't find anything there, then move onto the rest. If the user spent time configuring the list, we should try to use it when appropriate.
off to Adam's land
This will be resolved as part of bug 88204 once a new extension point is provided by JDT. Hurray for JDT! *** This bug has been marked as a duplicate of bug 88204 ***
