Community
Participate
Working Groups
The launch configuration validation returns missing constraint when there are two versions of the same plug-in. Looks like a previous bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=472778) but the patch appears in the source code. I am using version 2018-09(4.9) build I20180906-0745. Steps to reproduce: Install the SDK package. Install new software from Sirius site (http://download.eclipse.org/sirius/updates/releases/6.0.2/photon/) and select Sirius Integration with EEF. In run config, launch with features on Plug-ins tab. Deselect all and select org.eclipse.sirius.runtime.ide.eef. When clicking validate plug-ins, you get lots of missing constraints on org.apache.batik. For example, under org.eclipse.sirius.diagram.ui, missing constraint org.apache.batik.util; bundle-version="[1.6.0,1.8.0). org.apache.batik.util 1.6.0 and 1.10.0 are both present.
This issue is preventing us from moving our application past Oxygen. We would really like to get moved onto SimRel. But we can not debug our application in SimRel due to a failing validation. We can also not build it using export as a product from PDE. I am not sure if we could build using another method, such as Tycho, but we currently use the export as a product wizard from the product configuration editor. The plug-ins that most often appear as dependencies with differing versions are the various org.apache.batik.*.
It would help if you could provide a simple bundle example with a simple launch config showing the problem. Please note that if singleton bundle with different versions is available, the smaller version will not be resolved (I guess) because only higher can be used, and it is not a bug.
(In reply to Andrey Loskutov from comment #2) > It would help if you could provide a simple bundle example with a simple > launch config showing the problem. > > Please note that if singleton bundle with different versions is available, > the smaller version will not be resolved (I guess) because only higher can > be used, and it is not a bug. I added a use case in the original comment. If you need something further, please explain. The batik plugins are not singletons.
A simple example which does not require any additional software to be installed. Like a simple project, a target and a launch file. Something one can try and debug in few seconds, without fiddling with hundreds of indirect dependencies etc.
Created attachment 276849 [details] Simple test case to demonstrate the issue. Install SimRel: eclipse-committers-2018-09-win32-x86_64 Note that the plug-ins folder contains 2 versions of com.google.guava: com.google.guava_15.0.0.v201403281430.jar com.google.guava_21.0.0.v20170206-1425.jar I found that plug-in org.eclipse.buildship.core has a dependency on [15.0.0,16.0.0), while plug-in org.eclipse.m2e.core has a dependency on [21.0,22.0). I built a simple plug-in and product (import the attached test case as an existing project). For the included launch configuration, I specify the two features that have dependencies on different versions of com.google.guava. This launch configuration can be imported from the test case project. I then selected the button on the Plug-ins tab of the run configuration to "Select Required". Now, try to validate the run configuration. The earlier version of com.google.guava is reported as "missing". I realize that this simple case can be "fixed" by adding bother versions of the com.google.guava plug-in from the "Add Plugins..." button, but this solution quickly becomes unmanageable when the list of plug-ins with multiple versions grows large.
*** Bug 548429 has been marked as a duplicate of this bug. ***
Since a new bug, 548429, was closed as a duplicate of this one, can we bump this one and get somebody to look at it. This issue has been complicating our debugging efforts for a long time. Thanks!
I have triaged this to 4.13M1 so that this gets more importance.
Created attachment 279097 [details] Adding all bundles for the same id can cause problems In features like org.eclipse.ecf.filetransfer.httpclient45.feature.
(In reply to Vikas Chandra from comment #9) > Created attachment 279097 [details] > Adding all bundles for the same id can cause problems > > In features like org.eclipse.ecf.filetransfer.httpclient45.feature. Can we detect that distinct bundle versions are actually required (like in the guava example)?
(In reply to Julian Honnen from comment #10) > (In reply to Vikas Chandra from comment #9) > > Created attachment 279097 [details] > > Adding all bundles for the same id can cause problems > > > > In features like org.eclipse.ecf.filetransfer.httpclient45.feature. > > Can we detect that distinct bundle versions are actually required (like in > the guava example)? We have a Set<String> additionalIds = DependencyManager.getDependencies(launchPlugins.toArray(), false, null); which gives the ids. If we could also have got the version, this would have been fixed effectively.
(In reply to Vikas Chandra from comment #11) > If we could also have got the version, this would have > been fixed effectively. I'll try that.
I won't get to it this week.
Hi Julian, Any chances of a fix by 4.13M3 ( end of this week)?
(In reply to Vikas Chandra from comment #14) > Hi Julian, > > Any chances of a fix by 4.13M3 ( end of this week)? No. I played around with the dependency calculation a bit, but didn't get much further. IMO we should replace the getDependencies implementation with a State based one. Essentially we should run the BundleValidationOperation and then add bundles that satisfy its ResolverErrors. Other than that, I found that multiple bundle versionw work fine in a feature-based launch when the features specify the required versions explicitly.
see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=481214#c1 The problem still exists in 4.13
*** Bug 496549 has been marked as a duplicate of this bug. ***
Lowering severity, this is not a blocker.
(In reply to Karsten Thoms from comment #18) > Lowering severity, this is not a blocker. In my opinion, this is a blocker, since there is no workaround to run a JUnit plug-in test with two bundles require e.g. com.google.guava in different versions (or I do not really know a workaround).
It is preventing a specific use case and surely should be solved. It would be a blocker when no workaround is possible. The workaround is to have a clean target platform with a single version of a bundle and depending bundles that use the installed version.
Using a bundle in more than one version is pure OSGi. I don't think, this is a special use case. But however, I agree to you, this should be fixed :)
(In reply to Vikas Chandra from comment #11) > We have a Set<String> additionalIds = > DependencyManager.getDependencies(launchPlugins.toArray(), false, null); > > > which gives the ids. If we could also have got the version, this would have > been fixed effectively. From all I have seen in the code yet, I think this is the solution and I offer to implement it. My first attempt would be use NameVersionDescriptor, just because it seems to be a light weight container-class that matches all needs. But if something else more suitable exists, please let me know. However I wonder if it wouldn't be suitable and convenient to return a Set<IPluginModelBase> (or similar) directly. In most use-cases of the DependencyManager the PluginRegistry is queried any ways for corresponding models and they are already used inside the DependencyManager. So this could avoid copying date back and forth. If there are not objects, I try to implement a solution based on the second approach.
(In reply to Hannes Wellmann from comment #22) Could you please also look into my idea from comment 15? Reimplementing OSGi's dependency resolution will always be lacking in some respect, e.g. with Require-Capability from bug 496549.
(In reply to Julian Honnen from comment #23) > (In reply to Hannes Wellmann from comment #22) > Could you please also look into my idea from comment 15? > Reimplementing OSGi's dependency resolution will always be lacking in some > respect, e.g. with Require-Capability from bug 496549. Yes, I will also consider an implementation based on the osgi.service.resolver.State.
The submitted solution for this bug is not exactly State based, but State.getDependencyClosure() gave me the idea to implement the dependency computation based on an exhaustive Breadth-first search to find the self contained closure of all required wires of the initially given set of plug-in models. This has the following advantages: + the algorithm works on a more abstract level and can thus be simpler + the runtime and its behaviour is better (linear to the number of required wires) compared to before(previously it was iterated over all available bundles per ResolverError). Of course computed Set of required bundles now also considers the version. This is reflected by the fact that instead of a Set of bundle id strings a Set of BundleDescriptions is returned now. I have adapted the callers to this change. In some cases I did not use the returned BundleDescription directly because the caller have their own logic if workspace or external plug-ins should be preferred. These are namely: - ApiBaselineManager - BundleLauncherHelper - TargetContentsGroup This could be improved in follow up changes to be more accurate. Since the (internal) API of DependencyManager was changed any ways, I also clean it up and reworked it to be collection based and strongly typed. Furthermore the returned Set is now a HashSet and therefore not sorted. Callers that require a SortedSet have to sort the result by themself. I think there is no need to slow down the dependency computation in all cases just because some require a sorted result. I have checked the callers and only the ApiBaselineManager could require it. But I'm not sure about that.
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/183468
I like the direction, thanks! I will review and test it next week, but I'd feel more comfortable merging it first thing in 4.22 so we have the full release to find potential regressions.
(In reply to Julian Honnen from comment #27) > I like the direction, thanks! > I will review and test it next week, but I'd feel more comfortable merging > it first thing in 4.22 so we have the full release to find potential > regressions. That's reasonable. I'm on vacation for the first one and a half week of August, so my reply will be delayed. However, in the meantime until the 4.21 release I will just continue with the other depended bugs and create corresponding follow-up changes in gerrit.
Created attachment 287201 [details] Large mixed benchmark test case As requested in Gerrit I add a relatively large mixed benchmark/demo test case.
Gerrit change https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/183468 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=ba86481dbda0a022127b40bb313d603eada6e28b
Thanks a lot, Hannes!
Hannes, can you please verify this fix in an I build
(In reply to Vikas Chandra from comment #32) > Hannes, can you please verify this fix in an I build Unfortunately we have a regression in all platforms. https://download.eclipse.org/eclipse/downloads/drops4/I20210927-1800/testresults/html/org.eclipse.pde.ui.tests_ep422I-unit-cen64-gtk3-java11_linux.gtk.x86_64_11.html org.eclipse.pde.core.tests.internal.DependencyManagerTest testFindRequirementsClosure_RequireBundle2 Failure Target resolution failed: Status ERROR: org.eclipse.pde.core code=0 Problems occurred while resolving the target contents children=[Status ERROR: org.eclipse.pde.core code=0 Problems loading repositories children=[Status ERROR: org.eclipse.pde.core code=0 Problems loading repositories children=[Status ERROR: org.eclipse.equinox.p2.metadata.repository code=1000 No repository found at file:///home/jenkins/agent/workspace/ep422I-unit-cen64-gtk3-java11/workarea/I20210927-1800/eclipse-testing/test-eclipse/eclipse/tests/sites/site.a.b.]]] java.lang.AssertionError: Target resolution failed: Status ERROR: org.eclipse.pde.core code=0 Problems occurred while resolving the target contents children=[Status ERROR: org.eclipse.pde.core code=0 Problems loading repositories children=[Status ERROR: org.eclipse.pde.core code=0 Problems loading repositories children=[Status ERROR: org.eclipse.equinox.p2.metadata.repository code=1000 No repository found at file:///home/jenkins/agent/workspace/ep422I-unit-cen64-gtk3-java11/workarea/I20210927-1800/eclipse-testing/test-eclipse/eclipse/tests/sites/site.a.b.]]] at org.eclipse.pde.core.tests.internal.DependencyManagerTest.createTPState(DependencyManagerTest.java:157) at org.eclipse.pde.core.tests.internal.DependencyManagerTest.testFindRequirementsClosure_RequireBundle2(DependencyManagerTest.java:59)
(In reply to Andrey Loskutov from comment #33) > (In reply to Vikas Chandra from comment #32) > > Hannes, can you please verify this fix in an I build > > Unfortunately we have a regression in all platforms. > > https://download.eclipse.org/eclipse/downloads/drops4/I20210927-1800/ > testresults/html/org.eclipse.pde.ui.tests_ep422I-unit-cen64-gtk3- > java11_linux.gtk.x86_64_11.html > > > org.eclipse.pde.core.tests.internal.DependencyManagerTest > testFindRequirementsClosure_RequireBundle2 Failure Target resolution failed: > Status ERROR: org.eclipse.pde.core code=0 Problems occurred while resolving > the target contents children=[Status ERROR: org.eclipse.pde.core code=0 > Problems loading repositories children=[Status ERROR: org.eclipse.pde.core > code=0 Problems loading repositories children=[Status ERROR: > org.eclipse.equinox.p2.metadata.repository code=1000 No repository found at > file:///home/jenkins/agent/workspace/ep422I-unit-cen64-gtk3-java11/workarea/ > I20210927-1800/eclipse-testing/test-eclipse/eclipse/tests/sites/site.a.b.]]] > > java.lang.AssertionError: Target resolution failed: Status ERROR: > org.eclipse.pde.core code=0 Problems occurred while resolving the target > contents children=[Status ERROR: org.eclipse.pde.core code=0 Problems > loading repositories children=[Status ERROR: org.eclipse.pde.core code=0 > Problems loading repositories children=[Status ERROR: > org.eclipse.equinox.p2.metadata.repository code=1000 No repository found at > file:///home/jenkins/agent/workspace/ep422I-unit-cen64-gtk3-java11/workarea/ > I20210927-1800/eclipse-testing/test-eclipse/eclipse/tests/sites/site.a.b.]]] > at > org.eclipse.pde.core.tests.internal.DependencyManagerTest. > createTPState(DependencyManagerTest.java:157) > at > org.eclipse.pde.core.tests.internal.DependencyManagerTest. > testFindRequirementsClosure_RequireBundle2(DependencyManagerTest.java:59) It looks like the URL is wrong: file:///home/jenkins/agent/workspace/ep422I-unit-cen64-gtk3-java11/workarea/I20210927-1800/eclipse-testing/test-eclipse/eclipse/tests/sites/site.a.b It should end with: org.eclipse.pde.ui.tests/tests/sites/site.a.b My first suspicion is that the I builds use another working-directory than the PDE verification builds?
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/185885
(In reply to Vikas Chandra from comment #32) > Hannes, can you please verify this fix in an I build I have verified that this bug is fixed with version: Version: 2021-12 (4.22) Build id: I20210929-1800 I used the "Large mixed benchmark test case" attached to this bug by myself. With the mentioned version, when I press "Add Required Plug-ins" in the Run/Debug Configuration wizard all required plug-ins are added (except for the org.apache.xerces plug-ins, but it is not resolved in the TP, so I think is a bug there). A subsequent "Validate Plug-ins" confirms this. Because of the mentioned test-failures in I-builds I keep this bug open until the change to fix the tests is submitted.
Gerrit change https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/185885 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=d3af9f82cc9e15ddd4588a6c0eadae70e82c86a2
(In reply to Eclipse Genie from comment #37) > Gerrit change https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/185885 was > merged to [master]. > Commit: > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/ > ?id=d3af9f82cc9e15ddd4588a6c0eadae70e82c86a2 Thanks, that finally fixed the last failing test on Linux Java 11 build. I can't remember to see zero test failures on any of the builds we have for a long time. Hallelujah!
(In reply to Andrey Loskutov from comment #38) > (In reply to Eclipse Genie from comment #37) > > Gerrit change https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/185885 was > > merged to [master]. > > Commit: > > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/ > > ?id=d3af9f82cc9e15ddd4588a6c0eadae70e82c86a2 > > Thanks, that finally fixed the last failing test on Linux Java 11 build. I > can't remember to see zero test failures on any of the builds we have for a > long time. Hallelujah! That's great! As I said in my comment 36 above, I verified the fix of this bug, so I'll change the state to verified fixed.
