Community
Participate
Working Groups
At the moment the has to enter * in the product editor to perform a regular expression matching at the beginning. This is different compared to the MANIFEST.MF dependencies and the feature based products. We should fix that.
Created attachment 245311 [details] Without wildcard
Created attachment 245312 [details] With wildcard
YEs, the inconsistent wildcard support in the dialogs is frustrating. As the dialogs are used in many editors it would be great to have this improved.
I just added a first proposal for this bug here: https://git.eclipse.org/r/#/c/31468/ But I during my research I spottet also other places, where the PluginSelectionDialog should be used instead of the ElementListSelectionDialog for selecting Plug-ins. For instance in the PluginConfigurationSection and the SplashLocationSection. I´ll have a look at those issues tomorrow.
(In reply to Simon Scholz from comment #4) > I just added a first proposal for this bug here: > https://git.eclipse.org/r/#/c/31468/ Works fine for me and the change looks also great. Thanks Simon.
+1 to https://git.eclipse.org/r/#/c/31468/ Will be good to fix the same issue in Splash and Config tab of product editor ( as mentioned in comment #4 )
As you can see here https://git.eclipse.org/r/#/c/31468/ I also added the PluginSelectionDialog to the PluginConfigurationSection and to the SplashLocationSection. In addition to that I also saw that the TargetDefinitionContentPage also uses the ElementListSelectionDialog instead of the PluginSelectionDialog. Therefore I also removed the ElementListSelectionDialog and implemented a solution with the PluginSelectionDialog. Because of my changes the org.eclipse.pde.internal.ui.wizards.target.TargetDefinitionContentPage.getValidBundles() method is not used any more, but as it is declared as protected other derived classes may use this method. Or can I expect that other derived classes do not exist as the package is "internal"?
WORKSFORME is a status used to describe that the problem cannot be reproduced by the developer. Once Curtis or Vikas apply you patch, the put this bug to FIXED.
(In reply to Simon Scholz from comment #7) > As you can see here https://git.eclipse.org/r/#/c/31468/ I also added the > PluginSelectionDialog to the PluginConfigurationSection and to the > SplashLocationSection. > > In addition to that I also saw that the TargetDefinitionContentPage also > uses the ElementListSelectionDialog instead of the PluginSelectionDialog. > Therefore I also removed the ElementListSelectionDialog and implemented a > solution with the PluginSelectionDialog. I gave this a quick test, saw that it only affects the implicit dependencies page. The wildcard support is better. The label provider is a little odd. Even though the list is restricted to what is in your target platform (and implicit dependencies only is an id, not version), the PluginSelectionDialog displays icons indicating workspace vs external as well as the version number. Also, the initial list is blank, which can be disconcerting, especially if your target has very few plug-ins. I am still ok with the change. > > Because of my changes the > org.eclipse.pde.internal.ui.wizards.target.TargetDefinitionContentPage. > getValidBundles() method is not used any more, but as it is declared as > protected other derived classes may use this method. Or can I expect that > other derived classes do not exist as the package is "internal"? This is a good things to check. In this case getValidBundles() can be removed.
Initial list being blank makes it consistent with manifest editor. If we are to have an initial list, we can probably track it using another work item - which can probably solve it for all cases. However, the presence of version number now instead of no version number is a change that can affect the product editor. Would a user want <plugins> <plugin id="com.google.guava" version="15.0.0.v201403281430"/> </plugins> instead of <plugins> <plugin id="com.google.guava"/> </plugins> What if an user created a product configuration file, added dependency and then changed the plugin version by updating or something? Is that a realistic scenario?
(In reply to Vikas Chandra from comment #10) > However, the presence of version number now instead of no version number is > a change that can affect the product editor. I like that the version is added, that is consistent with the feature handling in the product editor (and the MANIFEST.MF dependency handling). If you add feature in the product, a version number is also added.
(In reply to Vikas Chandra from comment #10) > What if an user created a product configuration file, added dependency and > then changed the plugin version by updating or something? Is that a > realistic scenario? There are times a user will want a specific version of a plug-in, but often it is easier to not have a version and simply use the highest available. It depends on how detailed the user wants their dependencies to be. While it won't block users (you can edit the version in the properties), I do recommend we avoid changing the behaviour. The dialog should not save the version information. It would be nice if we provided some better tooling to help users add a version number should they want one (an option to always include version info when adding, or a button to set versions to the what is available in the target, or a suggestion based on available plug-ins in the properties dialog). This is outside the scope of this bug though.
>>often it is easier to not have a version and simply use the highest available Can we have this behavior along with "Automatic wildcard support". ?
Moving to 4.5 M3 as we don't want to change the behavior of giving version numbers to the plugin added ( although we do want wildcard support for product editors etc). This will involve changing the patch attached.
(In reply to Vikas Chandra from comment #13) > >>often it is easier to not have a version and simply use the highest available > > Can we have this behavior along with "Automatic wildcard support". ? When taking the result from the dialog, simply strip the version information before storing it in the product model. We were storing the plug-in information before without version.
Simon, any plan to update the patch?
Sorry for the delay Vikas, I just updated the PluginSection class, so that 0.0.0 is used as version in order to match with the former behavior. Are you ok with Patch 10?
Thanks Simon I will review it and put it in early 4.5M3
+1 to patch 10 of https://git.eclipse.org/r/#/c/31468/ Couple of things are slightly odd but they happen "outside" the scope of this bug. 1) In a new dialog, the new dialog is empty ( same behavior in MANIFEST editor) . Putting * doesn't work. It doesn't work for MANIFEST editor as well - add dependency as well. 2) There are 9-10 instance of "0.0.0" in pde.ui plugin
I just opened a bug for the second issue Vikas. https://bugs.eclipse.org/bugs/show_bug.cgi?id=444808 Unfortunately I am not able to assign this Bug to me.
Thanks Simon ! Rebased https://git.eclipse.org/r/#/c/31468/ and commited Patch 11 via http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=de241bf1c4bf907e0b513cf4e45b406dea080eac
Verified in Version: Mars (4.5) Build id: N20141003-2000
I think that should be added to the PDE N&N, lots of our users have complained about that in the past.
I added the WildcardItemsFilter protected inner class in order to support wildcards filtering for selection dialogs. I have done this in order to also support wildcards in the FilteredPluginArtifactsSelectionDialog, which also uses an ItemFilter. See this patch: https://git.eclipse.org/r/#/c/35698/
(In reply to Simon Scholz from comment #24) > I added the WildcardItemsFilter protected inner class in order to support > wildcards filtering for selection dialogs. > I have done this in order to also support wildcards in the > FilteredPluginArtifactsSelectionDialog, which also uses an ItemFilter. > > See this patch: https://git.eclipse.org/r/#/c/35698/ Thanks, merged with https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d04a5dfd9d252e9202b435f22b5f69d805358150
I also added wildcard support for the FilteredPluginArtifactsSelectionDialog. See: https://git.eclipse.org/r/#/c/35799/ Thanks to Markus Keller for spotting this dialog, where the wildcard support was still missing.
(In reply to Lars Vogel from comment #25) > Thanks, merged with > https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=d04a5dfd9d252e9202b435f22b5f69d805358150 This is wrong for too many reasons. Reverted in master. The name WildcardItemsFilter doesn't convey that this is about implicit prefix matching. Each and every call to "matches(..)" checks the pattern again. That's is inefficient and unnecessary. Why using & instead of && ? WildcardItemsFilter is API, but the documentation doesn't match the implementation. Why are there checks for "?" and "."? The change to AbstractContentProvider is wrong. I'm also not convinced this is of enough general interest to be API at all. A project lead should be informed if you add new API. And the commit should link to a bug in the affected bundle's component. Definitely not something to add to a PDE bug that has already been closed in the last milestone. (In reply to Simon Scholz from comment #26) > I also added wildcard support for the FilteredPluginArtifactsSelectionDialog. That belongs to bug 449348.
The reason only why I added the WildcardItemsFilter was that I do not want to have duplicate code for the PluginSelectionDialog and the FilteredPluginArtifactsSelectionDialog. Therefore I copied the implementation of the matches method in the PluginSelectionDialog into an abstract class. Sorry that I did not yet checked the inefficiency of the implementation, which is currently used in the PluginSelectionDialog. I think this inefficiency should be fixed within an other Bug.
> (In reply to Simon Scholz from comment #26) > > I also added wildcard support for the FilteredPluginArtifactsSelectionDialog. > That belongs to bug 449348. I now changed the commit message of my patch: https://git.eclipse.org/r/#/c/35799/
