Community
Participate
Working Groups
Build: 20020530 The plugin import wizard prompts the user with the following question when two versions of org.apache.xerces exist in the plugins directory. Project "org.apache.xerces" already exists. Is it OK to replace it? If you click Yes and let the import finish, you get only one version of xerces. Perhaps the plugin import tool should make project names like org.apache.xerces_4.0.3 for the plugins. As a test, unzip the attached zip (3.2.1 version of xerces) into your plugins directory, and run the plugin import wizard.
Created attachment 1148 [details] Xerces_3.2.1.zip
*** Bug 18522 has been marked as a duplicate of this bug. ***
Will not be addressed in 2.1
This problem will become more prominent when we start shipping multiple versions of the same plug-in in the SDK, e.g. org.junit (not yet for 3.3). I also ran into this problem with plug-ins that I updated via update manager (which leaves the old version around).
This is a good one to reopen.
This one is certainly doable now that we support multiple versions of the same plug-in. We could do the WinZip behavior: offer to overwrite or create a project by a different name and let the user input the new name.
post 3.3, right? Note: we already have this as a documented limitation in the readme.
yes, post-3.3. Now is not time to address a bug numbered "18500" ;)
*** Bug 190909 has been marked as a duplicate of this bug. ***
marking bugday for the brave... attaching a context for the brave... This would earn extra bonus points as it's a very low bug number :)
Created attachment 82628 [details] mylyn/context/zip
we should get this one done for 3.4
By now there are 5 options in override dialog. We can change meaning of the No and No for all, to show change name dialog for the plugins but it may confuse users. Adding two more ... well this will be way to much for such a simple task. And I've newer work on so old bug :) If you don't have a better candidate I can solve it :D
The solution I think is really simple and deals with creating projects for plugins in a special way if they have multiples... ie., org.apache.commons.collections_3.1.0, org.apache.commons.collections_3.2.0, versus just org.apache.commons.collections... ie., id_version I'll have to look into this a bit more but I think that should be sufficient.
Created attachment 88541 [details] very simple patch new format for imported plug-ins projects' names *id_version*
Created attachment 88542 [details] mylyn/context/zip
I'll look at this soon, thanks for looking into it Bartek.
Thanks for the patch Bartosz. You just fixed the oldest PDE bug on record! I added just a little bit of logic to look for an existing plug-in in the workspace with the same id and version. If such a plug-in project exists, we then return that name instead of the <id>_<version> so we prevent having two plug-ins with the same id and version. It might have taken 5 and a half years, but some things are worth the wait ;-) Thanks Bartosz!
it was a great "adventure" for me to ;) especially the patch was the oldest one I ever had :D
anyway I am working for top contributor for this year ;D
Just for the record, this modification required changes to our JUnit tests. The tests verify the plug-in was imported correctly by checking to see if a project exists with the plug-in id. I changed up the test cases to check to <id>_<version>. I didn't think about this until all the import test cases were broke :)
>very simple patch Unfortunately a bit too simple, see bug 217820 and bug 217824. This causes big trouble. I suggest to reopen and revert for M5 and make a better fix for M6.
Before adding this PDE has to test and if needed update all its tooling like the launcher, hyperlinking to go to required plug-ins, pde container etc.
(In reply to comment #22) > >very simple patch > Unfortunately a bit too simple, yes :| anyway besides of checking the tooling we should think about the import logic (should we leave override behaviour as default ? ) and how to support handling different versions. My idea is to add checkbox like "Allow multiversions" (but it will complicate the ui) which is disabled by default. Let's assume we have plug-in A in two versions 1.0.0 and 1.0.1 When option is enabled in and we import both plug-ins there will be create two project A (v1.0.1) and A_1.0.0 but there is a question what to do when we have A(v1.0.0) in workspace and import again both: should we add A_1.0.1 or update A to 1.0.1 and add new project 1.0.0 ? alternatively we can consider changes in override dialog but I don't think this is good idea
>My idea is to add checkbox like "Allow multiversions" Better: 'Append version to project name'. Out of the box it should import as before. But as long as PDE doesn't support it it shouldn't be offered. For example hyperlinking: if I import A and B from two versions (e.g. 3.2 and 3.3) and B requires A then clicking a required plug-in in B's manifest always goes to the same version of A instead of the correct one. Also, in some scenarios both B's can fit the version constaints and hence PDE would have to show a selection dialog to which B I want to go. And of course there's the launching issue.
pulled out the change, Brian and I are discussing what to do about this in M6. We have a possible solution.
Thanks!
is there anything I can participate in ?
(In reply to comment #26) > pulled out the change, Brian and I are discussing what to do about this in M6. > We have a possible solution. > Pinging zx, sometime we should discuss what could be done here.
This could become more of an issue when we ship version 3 and 4 of org.junit.
I don't think we need another option: it is already possible to select two versions of the same bundle if 'Show latest version of plug-ins only' is unchecked and if I do so, the last one wins (overwrites the first one). The following small change to the initially proposed solution might do the trick: When importing plug-in 'P' check if that bundle is already in the workspace with the same version (without qualifier) - if yes import with same name as in workspace (overwrite existing) - if no import as "P (x.y.z)"
Darin and I came up with an alternate proposal: 1) Remove the current yes/yes to all/no/no to all/cancel prompting. 2) Before starting to import individual bundles, scan the workspace models for bundles with the same symbolic name as a bundle being imported. 3) If there are any bundle name conflicts, open a dialog with a checkbox table. List all bundles with the same name along with their version and project name. 4) The user can deselect bundles they do not want overwritten (a single import could overwrite multiple projects). 5) Delete the selected projects. 6) Import the plug-ins, if there is still a project with the same default name, append the version (without qualifier). If that project exists, make the project name be "<symbolic name> (<version>) #" with increasing values of #. This solution makes the import depend on bundle names rather than project names, which feels more natural as project can be called anything. The user also has a fair amount of control over what they delete.
Ankur, if we go forward with the proposal in comment #32 would you have time to work on this? Though I'm considering finding time to work on it, because it is < 20,000 and over 7 years old!
(In reply to comment #33) > Ankur, if we go forward with the proposal in comment #32 would you have time to > work on this? > > Though I'm considering finding time to work on it, because it is < 20,000 and > over 7 years old! It'll be an honor to fix one of the oldest open PDE bug :-) If Dani is also OK with the proposal, I'll target it for M4.
>4) The user can deselect bundles they do not want overwritten (a single import >could overwrite multiple projects). I always import > 100 bundles. You don't expect me to check each of them manually, do you? ;-) Currently I have to click exactly once. This must stay as is as this the common workflow when importing the binary bundles from a new drop. The suggestion from comment 32 only unnecessarily complicates things. My suggestion would not cause any disruption to the known (and (90%) workflow but would only come into play in case there are >1 version of the same bundle implemented. If I can choose, then better do nothing than what's proposed in comment 32.
The dialog I am proposing would have checkbox selection, (de)select all buttons, and would have everything selected by default. For your case Dani, the only difference would be you pressing OK instead of Yes to All. The dialog would be an improvement on the current system, where you get a dialog with 5 buttons and if you want to avoid overwriting one or more projects you have to go through a series of dialogs until you happen to get the one for the project you care about. This has become more annoying on linux as the Yes button, selected by default, shows up on the far right making the buton order look jumbled. The current system also only works on project name, so to support your proposal we would have to do the same kind of changes that I'm proposing. I'm also concerned that as bundles increase their versions you'll end up with multiple projects for the same singleton bundle.
Comment 32 sounds great! Just 1 caveat and 1 change request: In steps 5 & 6, the implementation should make sure that plug-ins which replace existing plug-ins stay in the same working set as the original plug-ins (steps in bug 256592). I don't like spaces in project names. Could the projects be named as proposed in comment 0, e.g. like this (stuff in [] only to disambiguate): <symbolic name>[_<version without qualifier>[_<unique number>]]
>The dialog I am proposing would have checkbox selection, (de)select all >buttons, and would have everything selected by default. For your case Dani, >the only difference would be you pressing OK instead of Yes to All. If it has '(De-)Select All' and the default is that all are checked then that looks good to me. Given the SDK already has around 200 bundles we should also use a filtered checkbox list. We want to proceed with bug 153429 so I hoped to quickly get a working importer again with what I suggested in comment 31 but if you have resources to provide a new UI then that's also OK, but I don't want to wait too long for that ;-) >I don't like spaces in project names. Could the projects be named as proposed >in comment 0, e.g. like this (stuff in [] only to disambiguate): And I don't like underscores in the name ;-) but I agree that unless there are ambiguities we only want the symbolic name like I proposed in my solution. In case of dis-ambiguities we should simply use the same rendering as PDE uses in the import and target pref page: symblicName (x.y.z.qualifier) where the "(...)" is rendered using qualifier color (see also bug 295827).
There's a difference between rendering on the Target Platform page and choice of project name. For rendering, the gray (x.y.z.qualifier) is a good way to add more information to bundle names. But the project name should be as close as possible to the original bundle name (after all, it is still an *import* operation), so the most obvious choice is the format used in the original jar names (where the version is also appended with an underscore).
>so the >most obvious choice is the format used in the original jar names (where the >version is also appended with an underscore). I disagree that the JAR name is the obvious choice for a project name but I agree that we can't use gray decoration here i.e. the created project name should contain the additional qualifications and should be rendered in normal color.
Alright, space vs underscore aside, it looks like we'll move forward with the new UI. Ankur, maybe you and I can discuss this for a few minutes this week so it gets done sooner rather than later.
Created attachment 153389 [details] UI first cut
The JAR name also has the advantage that it is not translated and hence the behavior is the same on all locales. The UI notation with " (<version>)" is NLS'd (or at least should be, I didn't check).
>The JAR name I can live if we go with the the JAR name but MINUS the ".jar" and as previously said we must only append this if there are conflicts.
I am dropping a check for Execution Environment. Presently, if a plugin (getting imported) has a BREE which is not supported by any of the installed JREs then user is prompted for confirmation (for importing that particular plugin or not). Dropping this check also makes sense because if the BREE is not supported then a) user will get the warning anyway b) next logical step would be to install that EE.
Created attachment 153662 [details] WIP Patch It needs some comments, cleaning and fine tuning. However, play with it and let me know if its not behaving properly.
Here's a quick list of things to fix, I can probably work on some of them if it means getting this in for M4. 1) The dialog opens even when there are no conflicts 2) The check box should be part of the plug-in name column (see Installed JREs pref page) 3) There should be an icon on the first column (you can use the general PDE label provider just like the plugin import detailed page does) 4) The first column should be "Name" or "Plug-in" not symbolic name 5) The first column is too small, you can probably have the columns take equal sizes 6) Select all and deselect all buttons should be underneath, not beside the table. (see the dialog that offers to save multiple dirty editors when closing Eclipse). 7) When people see columns with headers, they generally expect to be able to click on them to sort by that column. 8) All entries in the dialog should be checked by default 9) Filter box should search anywhere in the name (see the plugin import detail page) The filtering/select all behaviour could be an issue. The buttons don't change enablement when everything/nothing is selected. The select all only affects what is visible. I'm not sure if this is actually a problem as it is useful to only change what is visible and other selection dialogs don't worry about disabling select all. We could try moving away from columns which would avoid some of the above issues. That just might make it hard to see the project name.
I think we also need to look at how this dialog handles some unusual cases. Specifically I am concerned that we need to do more of the project clean-up ahead of time rather than just setting overwriteProject to true when importing each plug-in. If we are importing org.eclipse.foo v1.0 and two other copies of org.eclipse.foo exist in the workspace, should we delete both of the existing projects? Darin and I had discussed this a bit when we first talked about having the new dialog, but I don't remember what the conclusion was. In any case the dialog already feels like an improvement over the 5 button prompt.
I know dialog needs a lot of UI correction. I was more concerned about the importing and creating new projects. Since that did not get a mention, I believe its working fine.
>Here's a quick list of things to fix, I can probably work on some of them if it >means getting this in for M4. We need a way in M4 to import two versions of the same bundle.
Created attachment 153741 [details] Updated dialog Patch will follow soon. The projects are now (style) displayed as ProjectName (id - version)
Created attachment 153766 [details] Patch Curtis, let me know your comments.
Fixed up the dialog (altered label provider, composite sizing, message text) and fixed a few bugs in the code (possible NPEs, incorrect project naming). Committed the code to HEAD. There is a change in behaviour with this fix. When the user imports a plug-in with a conflict and chooses not to delete the project, previously we would skip importing that plug-in. After this fix, instead of ignoring, we import the plug-in and give it a different name.
Verified in I20091208-0100
Good work. Thanks!
