Community
Participate
Working Groups
I20070503-1400 I know - user error ;-) But I often run into this: I start with the latest build do some stuff and launch a target out of my dev workspace. Then I decide to update my dev workspace by importing all unshared binary plug-ins. This fails totally as most plug-ins cannot be imported because their JARs or libs are in used and locked by the FS. The result is a workspace with tons of errors.
One has to ask why you are importing the binary plugins in the first place? Create and manage targets using the Target Definition files. That is what they are for. They are cool. They are powerful. They rock.
1. because I want a self-contained workspace 2. because I want to avoid all the well know (build path) problems with the setup you recommend
...and because it is the default for importing plug-in projects ;-)
First, I am not trying to tell you to change. More looking at seeing if you are using this approach because a) you always have b) cause it gives you some capability or c) because you are working around some issues. Seems like it may be b and c. In the case of c) I'm not sure what build path issues you are talking about. I know that there are Java search issues. I'd like to see those fixed for real rather than forcing people to work around the problems. For my own education, can you briefly describe the build path issues that are solved by having the bundles imported into your workspace as binary projects?
re comment 3, that begs the question as to why plugins are being imported at all ;-)
>For my own education, can you briefly describe the build path issues that are >solved by having the bundles imported into your workspace as binary projects? See bug 73957 with all its dups.
Thanks for your patience and the info. I remember that problem. Honestly I think it is an issue at the JDT level and the fact that having the plugins in your workspace makes a difference is actually a bug! Anyway, that is off topic for this bug. Thanks again.
Argh! Just run into this again. Reparing the workspace took about an hour as PDE showed strange errors on the MANIFEST.MF like: Unsatisfied version constraint even though the plug-ins were clearly there (some even in source). Opening and closing the projects, restarting etc. didn't help either. Even cleaning all projects didn't convince PDE to remove all errors and warnings. So - while deleting a project from my hard disk shows me a prompt where I even have to select a radio button that it gets physically deleted, I don't get a warning for an action that competely ruins my workspace.
FYI: the warnings/errors that clean couldn't remove were mostly missing class refs in plugin.xml. How To Fix The Errors: 1. delete all binary plug-ins which is a pain as - there is no non-binary filter - per default project's aren't physically deleted (have to check that radio button for each deletion) 2. Clean All 3. use PDE import to use all required plug-ins 4. Build All
Brian, I think the easiest and most sensible thing to do here is to check to see if there are any active PDE launches active. LaunchListener keeps track of all of them. If we have > 0 launches active, show a warning about that prior to doing any import work.
Daniel, which plug-ins are you seeing problems with? I had 3 instances of RC1 running and tried to import all the plug-ins into my workspace. I did not see any errors and can't find any evident problems.
1. start fresh workspace 2. on the PDE 'Target Platform' page disable all plug-ins 3. import all plug-ins (as binary plug-ins which is the default) NOTE: I have JDT and Platform Text in source and everything else that's needed in binary plug-ins. You can try that setup. The problem is that importing all required plug-ins doesn't import everything that's needed to launch the Eclipse application :-( 4. create a new 'Eclipse Application' launch config and start it 5. repeat step 3 (say 'Yes To All' when ask to replace) ==> - you get ton's of .log entries - projects are corrupt (e.g. no more source of SWT classes) - exit the target from step 4. Try to launch ==> error For more fun, as step 0 replace some of the plug-ins with the source from the CVS repository (e.g. jdt module and platform-text module) and exclude those when doing step 3. ==> you get crazy error messages on the source plug-ins.
Created attachment 68520 [details] The .log
Another ugly side effect of the corrupt projects is that I can no longer use "Existing Unshared" as the project info is gone and hence some of the imported project not being detected as unshared plug-in projects.
I'm increasing this one as it just corrupted my workspace again. PDE must either warn or make sure it correctly imports. Currently it corrupts my workspace without notifying. This could even be considered a critical bug as data gets lost.
This morning I had a great idea on a fix for this bug. After the user clicks OK to import some plug-ins, we can check to see if any runtime workbenches are running. When we come up to a name conflict where we have to overwrite the project, we will display the current prompt. If the user selects yes and a runtime workbench is running we read the Manifest to find the Bundle-ClassPath value and if it is a jar, try to delete it. If the delete is unsuccessful, that means the file is locked and there is no way PDE will be able to import the plug-in into that project. If it is successful, we delete the rest of the project and import the plug-in. With this information, PDE can skip over projects with locked files and still keep their data intact. If we keep track of all the projects which were locked, we can display them to the user at the end of the operation in one concise list. This should cause the user no more button clicks other than a list of all the projects which were not replaced. Also, doing these checks only if there is a runtime workbench running, if there is a naming conflict, and if the project is a binary plug-in we should be able to keep our current performance during normal operation.
Sounds like a great idea.
Darin, can we fix this for 3.4 along the lines of what Brian suggests in comment 16? That would be great.
I have actually already started work on this and was half way done when I got preempted by other tasks. This will definitely make it in 3.4 without a problem.
this is marked as a bugday so if you have some partial solution and don't have time to work on this bug I can take it.
Hey Bartosz, unfortunately whatever patch I have would probably not apply very well. I don't think I got very far, only hacking away to read the Manifest and try to delete a jar. If you run into problems or want someone to bounce ideas off of, let me know.
I don't know if I can manage till the end of M3
In 3.4M3 this bug seems to not be a problem anymore (tested with procedure from #comment 12). can anybody confirm ? my Eclipse version: Version: 3.4.0 Build id: I20071101-2000 (tested both Windows and Linux) Although I can't find the source code change in pde sources that fixes(?) this bug
targetting to M4 to include in testing run
>Although I can't find the source code change in pde sources that fixes(?) this >bug Because it is *not* fixed. I can easily reproduce this using I20071113-0800. 1. start new workspace 2. disable all external plug-ins 3. import *jdt.ui and *ui.ide* with all its required plug-ins 4. launch target Eclipse app 5. import *jdt.ui and *ide.app* with all its required plug-ins 6. exit target 7. launch ==> does not work anymore (java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter) If you do this in a workspace with lots of other (especially source plug-ins) you are doomed.
Yes you're right :|. It seems I was looking only on the .log effect. I am working on a fix right now.
Created attachment 83240 [details] first patch this patch is a simple safety check. probably is good to present here list of the plugins that are potentially locked by running launch configurations. next step is to allow user to proceed import, and in the import check if there is a chance to import specific plugin into workspace (i want to provide this function in the next version of this patch). by now I compare plugins to import with plugins from running lauch configurations using its symbolic names. is this a good approach ?
Created attachment 83241 [details] mylyn/context/zip
Created attachment 83439 [details] second version this code still needs some polishing (strings externalization). user communication (displaing plugins that cannot be imported) not included. although safe check during the project removal is implemented as Brian suggested.
Created attachment 83440 [details] mylyn/context/zip
Bartosz, nice job. I like how you checked the running launch configurations to see if there were any conflicts before warning the user. I think that will lead to a nicer user experience. I applied the patch with a few minor changes. The first was that I modified the function that looked for conflicts in running launch configurations. Since you did nothing with the value of the Map, I instead made the object a HashSet. Also, once a match was found, I returned. The second was I modified the saveDelete check. By using PDE models to find the files, we avoid JDT exceptions, don't have to worry about any libraries the user might have added to the classpath, and use less lines of code. It should do the same job, I just like to use PDE code when we can so we rely on other components less :) Thanks for the hard work. This turned out very well!
verified in I20071211-0010
My initial problem is solved - thanks a lot! There are some remaining issues though: - NPE (bug 212744) - dialog wording (bug 212745) - PDE import shows error dialog and logs error when app is running (bug 212755) - show list of affected plug-ins (bug 212758) - detection of running plug-ins not accurate (bug 212763) I think the NPE and the dialog wording should be fixed for M4.
