Community
Participate
Working Groups
I have a stock Eclispe SDK installed. When I do 'check for updates', it prompts me to install the Object Teams patch for JDT 2.0.0. Why do I want that installed?
This is not intended. I tried to reproduce but after installing Eclipse SDK 3.7 and doing "check for updates" I correctly got: "No updates were found". What would I need to do to reproduce the issue? Background: Object Teams ships a variant of org.eclipse.jdt.core using a patch feature for deployment. This has been discussed in various lists/bugs and we took measures so that this feature should never be installed unintentionally. Of course we'd love more people to try Object Teams :) but we wouldn't ever push it via unintended updates.
Hmm. Let me see if I can figure out how to reproduce this. I know it was done by creating an RCP and then executing a P2 director command to install org.eclipse.jdt.feature.group into it; the subsequent update caused the above.
(In reply to comment #2) > Hmm. > > Let me see if I can figure out how to reproduce this. I know it was done by > creating an RCP and then executing a P2 director command to install > org.eclipse.jdt.feature.group into it; the subsequent update caused the above. I'm confused: are you updating the SDK or an RCP application that you develop using the SDK? In that latter case I'd probably need to know more about the RCP application.
Stephan, Let me see if I can find a way of replicating the issue and attach instructions to here. It may be that the way I'm building it up with P2 is the issue, in which case I'll find a way of repeating my steps so that you have something to go on.
OK, so I can reproduce this as follows: 1) Download the Eclipse Platform SDK from http://download.eclipse.org/eclipse/downloads/drops/R-3.7-201106131736/index.php (I used Win64) 2) Run the install manager and choose Programming Languages -> Eclipse Java Development Tools, install and restart 3) Run 'check for updates' 4) Object Teams patch is suggested This may be because I'm starting from the Platform SDK and then installing components on the top, rather than the Eclipse SDK (which comes with JDT pre-packaged). I'm also fine if this is an edge case behaviour, but I wanted to (a) log this as a bug in case others saw it and (b) to let you know in case you weren't aware. With that in mind, if this is something that you can't fix (and given that most people will probably base their runtime on the Eclipse SDK) then it's fine to mark this as WONTFIX. I'd be interested in knowing what property of the Eclipse SDK makes this not occur though.
(In reply to comment #5) > OK, so I can reproduce this as follows: Thanks, Alex, I can reproduce now. > This may be because I'm starting from the Platform SDK and then installing > components on the top, rather than the Eclipse SDK (which comes with JDT > pre-packaged). Yeah, that seems to make the difference. In fact we iterated through a number of scenarios in order to avoid accidental installation of this patch feature and in bug 330534 the p2 team advised us on how this can be achieved. The scenario in this bug is kind-of border line: on the one hand the patch feature is explicitly presented to the user for selection. OTOH it is more than a normal update because a new feature is being pulled in, so why is this proposed as an update? > I'd be interested in knowing what property of the Eclipse SDK makes this not > occur though. It must have something to do with how the Eclipse SDK profile locks down its content, but frankly I don't fully understand the difference.
Moving to p2 for comments. Please see steps in comment 5 for unintended behavior. Background: There are two versions of org.eclipse.jdt.core: - org.eclipse.jdt.core_3.7.0.v_B61.jar - org.eclipse.jdt.core_3.7.0.v_OTDT_r200_201106070730.jar The version of the OT variant is greater than the original's. The OT variant has a non-greedy dependency on the OT patch feature, to ensure that the bundle cannot be installed without explicitly installing it's containing patch feature (as suggested in bug 330534 comment 8). The unexpected part is: why does check for updates propose to pull in a new (patch) feature based on a non-greedy dependency. For comparison the following scenarii work as expected, i.e., don't propose the patch feature during check for updates: A1) Install Eclipse SDK (as opposed to Platform SDK) Now you already have the JDT A2) Check for updates -> No updates found. B1) Install Platform SDK (or another JDT-less package) B2) Install "Collaboration > Subversive SVN JDT Ignore Extensions" -> this pulls in among others org.eclipse.jdt.core_3.7.0.v_B61.jar but not the JDT feature. B3) Check for updates -> No updates found. Any ideas why the steps in comment 5 produce a different result than the other scenarii? Thanks.
Same here - Eclipse Runtime 3.7 with additional JDT install. The patch was prompted as an update. This, however, shall not be the case - it's not a patch, it's a feature. Please, drop this behaviour - it's not very user firendly to have us need to remember that this "patch" is a feature.
FWIW I discovered how to reproduce this. If JDT is installed as a top-level feature then the patch is automatically prompted upon update. If JDT is installed as a dependency for another feature, then no updates against JDT are performed and as such doesn't prompt you. I solved this by creating a dummy wrapper feature which only depended on JDT and installed that instead. This brings in JDT but doesn't bring in anything else. Of course if you install a newer JDT specifically (eg one with Java7 support) you cone back to this problem again.
I suspect that the problem is caused by incorrect metadata in OT/J. Since, as observed, OT/J is not a patch to JDT but a new feature, it should not expose publish itself as such. Instead it should only have an OT/J feature. Moving to the OT/J team where we can continue looking into a solution for what would be the appropriate metadata.
(In reply to comment #10) > I suspect that the problem is caused by incorrect metadata in OT/J. Since, as > observed, OT/J is not a patch to JDT but a new feature, it should not expose > publish itself as such. Instead it should only have an OT/J feature. Pascal, does p2 have (new) means for replacing an existing bundle with a different version, other than using a patch feature? The meta data has been crafted with the special help of the p2 team (see bug 330534 comment 8). And these settings helped to prevent the accidental selection of the OT/J patch during install. Can you elaborate what kind of meta data you would expect? OTOH, I'm still surprised that an update indeed pulls in a new feature, and be it a patch feature.
OK, I have some news, but first I want to repeat: I think it is undesirable behavior of p2 to propose installing a new patch feature when checking for updates. Installing a patch feature that has not been installed before is more than a normal update (whereas updating an installed patch feature of course qualifies as an update). Next, I'd like to remind you that the OTDT contains indeed a patch feature for replacing the org.eclipse.jdt.core bundle with our own variant. This has been discussed in several top committees in Eclipse land, we have received technical advice in bug 330534 and the Eclipse PMC has approved the situation. That said, I have made yet another round of experiments with our metadata. I can now publish the OTDT in a way that normal installation is unaffected, where check for updates still proposes to install the OT patch feature, BUT shows the following error: The operation cannot be completed. See details. Is this better? I think it makes the tool look bad: proposing a something that isn't applicable anyway, but I'm not sure whom users would blame.
Created attachment 201457 [details] Dialog with proposal and error Here's a screenshot of what you'd get with changed metadata. Ah, if you're curious what's in the details, it actually ends with "not be installed".
And here's the technical background: In indigo our variant of org.eclipse.jdt.core has this requirement in p2.inf: requires.1.namespace=org.eclipse.equinox.p2.iu requires.1.name=org.eclipse.objectteams.otdt.core.patch.feature.group requires.1.range=[2.0.0,3.0.0) requires.1.greedy=false requires.1.optional=false This means: our jdt.core bundle can only be installed if also our patch feature is installed. Saying greedy=false is intended to avoid accidental installation. This works during "install new software" but seems to be ignored during "check for updates". I have no idea why both scenarios have different semantics, i.e., the weaker operation (check for updates) wants to install MORE than the stronger operation (install new). Anyway, as an experiment I twisted the dependencies even more: requires.1.namespace=org.eclipse.equinox.p2.iu requires.1.name=org.eclipse.objectteams.otdt.feature.group requires.1.range=[2.0.0,3.0.0) requires.1.greedy=false requires.1.optional=false Now we have this o.e.o.otdt.feature includes o.e.o.otdt.core.patch.feature includes other bundles o.e.o.otdt.core.patch.feature includes o.e.jdt.core bundle o.e.jdt.core bundle depends non-greedy,non-optional on o.e.o.otdt.feature Is that a better structure? I wouldn't be surprised if other tools will then break when encountering this new cyclic dependency. If anybody wants to try it, I uploaded the following repo: http://build.eclipse.org/tools/objectteams/bug350133 Here's how to test: (a) Install a JDT-less package (e.g., Eclipse for Testers) (b) From indigo repo install "Programming Languages > Eclipse Java Development Tools" (c) Add the above repo bug350133 (d) Check for Updates -> Dialog with error As a cross-check: installing the three features from that repo still works. This is the best I can do currently. Explanations / improvements from p2 welcome. I would really like to avoid the dialog from attachment 201457 [details]! Otherwise I will probably have to take the risk of releasing the new metadata / dependencies and close as fixed.
*** Bug 350093 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > Is that a better structure? I wouldn't be surprised if other tools will > then break when encountering this new cyclic dependency. I found such breakage sooner than I expected: our own build is impossible with these dependencies, because during bootstrapping we need to install just the patch feature into the base, which the new dependencies prohibit. So, please speak up if you think raising the error shown in attachment 201457 [details] is worth the effort of reworking our build. Otherwise I will just forget that experiment and wait for a solution from p2.
(In reply to comment #10) > I suspect that the problem is caused by incorrect metadata in OT/J. Please look at our meta data, and tell us exactly what you "suspect" being wrong. > Since, as > observed, OT/J is not a patch to JDT but a new feature, it should not expose > publish itself as such. The OTDT contains a patch feature and you know what and why this is. > Moving to the OT/J team where we can continue looking into a solution for what > would be the appropriate metadata. I would have been happy to collaborate with you under the Object Teams umbrella, but after explaining all technical background and performing more experiments I've run out of things I can do on my own. Please indeed consider this as a bug against p2: "Check for Updates" should not propose to install any feature that has not been installed before - including patch features. Only p2 can fix this.
I'm seeing the same issue when trying to do a Maven/Tycho build that has to include EMF when executing tests. JDT is (for some reason) pulled in, and the dependency on a missing org.eclipse.objectteams.otdt.core.patch causes the tests to fail.
(In reply to comment #18) > I'm seeing the same issue when trying to do a Maven/Tycho build that has to > include EMF when executing tests. JDT is (for some reason) pulled in, and the > dependency on a missing org.eclipse.objectteams.otdt.core.patch causes the > tests to fail. I'm sorry hear this. Could you please check which exact versions of the org.eclipse.jdt.core bundle are available? To me it looks like someone first picks a version (from several candidates?) and only later detects that that version has an unmet dependency. Thus this bundle shouldn't be picked in the first place. Which part of the tool chain exactly picks the bundle versions?
(In reply to comment #18) > I'm seeing the same issue when trying to do a Maven/Tycho build that has to > include EMF when executing tests. JDT is (for some reason) pulled in, and the > dependency on a missing org.eclipse.objectteams.otdt.core.patch causes the > tests to fail. Please open a bug against Tycho with a reproducible test case.
Since this issue has been brought up again to my attention, Stephan, could you please attach the ODT metadata (content.jar) to this bug report. Thx.
(In reply to comment #21) > Since this issue has been brought up again to my attention, Stephan, could you > please attach the ODT metadata (content.jar) to this bug report. Thx. For Indigo it's here: http://download.eclipse.org/objectteams/updates/ot2.0/content.jar Let me know if you need pointers to the input files from which this was generated (feature.xml, MANIFEST.MF, p2.inf).
Hi, just want to add that I am having the same issue on Juno 4.2. Cheers
(In reply to comment #18) > I'm seeing the same issue when trying to do a Maven/Tycho build that has to > include EMF when executing tests. JDT is (for some reason) pulled in, and > the dependency on a missing org.eclipse.objectteams.otdt.core.patch causes > the tests to fail. I've got a very similar issue: Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.15.0:test (default-test) on project com.redhat.thermostat.eclipse.test: Execution default-test of goal org.eclipse.tycho:tycho-surefire-plugin:0.15.0:test failed: "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from com.redhat.thermostat.eclipse.test 0.4.0.qualifier to bundle com.redhat.thermostat.eclipse 0.4.0.qualifier.", "Unable to satisfy dependency from org.eclipse.jdt.core 3.8.1.v_OTDT_r210_201206090452 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).", "No solution found because the problem is unsatisfiable."] -> [Help 1] I'm using the Eclipse juno update site with Tycho.
Trying to build Activiti Designer from trunk (http://svn.codehaus.org/activiti/projects/designer/trunk/) I run into the same compilation problem: Caused by: java.lang.RuntimeException: "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.activiti.designer.feature.feature.group 5.9.3 to org.eclipse.graphiti.feature.feature.group [0.9.0,0.9.1).", "Unable to satisfy dependency from org.eclipse.jdt.core 3.7.0.v_OTDT_r200_201106070730 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).", "Unable to satisfy dependency from org.eclipse.jdt.core 3.7.1.v_OTDT_r201_201109101025 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).", "Unable to satisfy dependency from org.eclipse.jdt.core 3.7.3.v_OTDT_r202_201202051448 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).", "No solution found because the problem is unsatisfiable."] This problem emerged within the last 3 days.
(In reply to comment #25) > This problem emerged within the last 3 days. Any idea what might have changed? Surely the Indigo repository hasn't, has it?
(In reply to comment #26) > (In reply to comment #25) > > This problem emerged within the last 3 days. > > Any idea what might have changed? > Surely the Indigo repository hasn't, has it? The problem was my Graphiti dependency. The objectteams error went away after I changed the Graphiti URL from http://download.eclipse.org/graphiti/updates/milestones/ to http://download.eclipse.org/graphiti/updates/0.9.0 I should have attacked the first error first.
Since this is still being reported every once in a while, let me try to summarize status and the relation to some other bugs out there: Proposing a patch feature during check for updates has been requested in bug 245299, so apparently that part is by intention. The Object Teams patch feature now has the following description: "This feature is NOT a regular update of the JDT, but REPLACES the org.eclipse.jdt.core plugin by the corresponding version for Object Teams. This change makes the JDT Core capable to handle OT/J code." This should help users understand what's going on, but unfortunately this doesn't help in scenarios where conflicting dependencies are detected, in which case the description will not be shown, only the error message. Problems are known to aggravate when trying to install a patch feature into a shared install, but (a) support for shared installs is being improved and (b) updating a shared install is limited any way. Of course the Object Teams project is doing its best to avoid incompatibilities, so that installing the patch should not cause any harm. Bug 329949 requests to add more metadata for distinguishing different kinds of updates and patches. If the request were granted, p2 could use that data to filter which updates to propose (perhaps based on a preference). An even more fundamental proposal regarding the update UI can be found in bug 316702, which would amount to better informing the user about pending updates so that users can make informed choices. Apparently, neither bug 329949 nor bug 316702 raised a lot of interest, so perhaps users are just content with the status quo despite the occasional hiccups. Should, however, one of these bugs get some attention the Object Teams project will be more than happy to serve as a guinea pig.
(In reply to comment #28) > Since this is still being reported every once in a while, let me try to > summarize status and the relation to some other bugs out there: I think this problem could be solved by tweaking the metadata of the OJDT feature so it does not appear as an update since this is not what you want. Could you please paste here the IU of the problematic feature? Thx.
(In reply to comment #29) > I think this problem could be solved by tweaking the metadata of the OJDT > feature so it does not appear as an update since this is not what you want. > Could you please paste here the IU of the problematic feature? Thx. here you go (from http://download.eclipse.org/objectteams/updates/ot2.1/content.jar): <unit id='org.eclipse.objectteams.otdt.core.patch.feature.jar' version='2.1.0.201206090452'> <properties size='8'> <property name='org.eclipse.equinox.p2.name' value='%featureName'/> <property name='org.eclipse.equinox.p2.description' value='This feature is NOT a regular update of the JDT, but REPLACES the
org.eclipse.jdt.core plugin by the corresponding version for Object Teams.
This change makes the JDT Core capable to handle OT/J code.'/> <property name='org.eclipse.equinox.p2.description.url' value='http://www.eclipse.org/objectteams'/> <property name='org.eclipse.equinox.p2.provider' value='%providerName'/> <property name='org.eclipse.update.feature.plugin' value='org.eclipse.jdt.core'/> <property name='df_LT.featureName' value='Object Teams Patch for JDT/Core'/> <property name='df_LT.providerName' value='Eclipse.org - Object Teams'/> <property name='df_LT.license' value='Eclipse Foundation Software User Agreement blahblah'/> </properties> <provides size='3'> <provided namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.objectteams.otdt.core.patch.feature.jar' version='2.1.0.201206090452'/> <provided namespace='org.eclipse.equinox.p2.eclipse.type' name='feature' version='1.0.0'/> <provided namespace='org.eclipse.update.feature' name='org.eclipse.objectteams.otdt.core.patch' version='2.1.0.201206090452'/> </provides> <filter> (org.eclipse.update.install.features=true) </filter> <artifacts size='1'> <artifact classifier='org.eclipse.update.feature' id='org.eclipse.objectteams.otdt.core.patch' version='2.1.0.201206090452'/> </artifacts> <touchpoint id='org.eclipse.equinox.p2.osgi' version='1.0.0'/> <touchpointData size='1'> <instructions size='1'> <instruction key='zipped'> true </instruction> </instructions> </touchpointData> <licenses size='1'> <license uri='%25licenseURL' url='%25licenseURL'> %license </license> </licenses> <copyright> more blah </copyright> </unit> I guess you're going to suggest that we set the filter to false? If so... - What would be the effect? - Can this be authored from the feature.xml? - Or can I achieve this using the p2 publisher?
Ups, here's another version, with a bit more data, I have no idea, why the other version lacks the patchScope and changes data: <unit id='org.eclipse.objectteams.otdt.core.patch.feature.group' version='2.1.0.201206090439' singleton='false'> <patchScope> <scope> <requires size='1'> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.feature.group' range='0.0.0'/> </requires> </scope> </patchScope> <changes> <change> <from> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.core' range='0.0.0'/> </from> <to> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.core' range='[3.8.1.v_OTDT_r210_201206090439,3.8.1.v_OTDT_r210_201206090439]'/> </to> </change> </changes> <lifeCycle> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.feature.group' range='0.0.0' greedy='false'/> </lifeCycle> <update id='org.eclipse.objectteams.otdt.core.patch.feature.group' range='[0.0.0,2.1.0.201206090439)' severity='0'/> <properties size='9'> <property name='org.eclipse.equinox.p2.type.patch' value='true'/> <property name='org.eclipse.equinox.p2.name' value='%featureName'/> <property name='org.eclipse.equinox.p2.description' value='This feature is NOT a regular update of the JDT, but REPLACES the
org.eclipse.jdt.core plugin by the corresponding version for Object Teams.
This change makes the JDT Core capable to handle OT/J code.'/> <property name='org.eclipse.equinox.p2.description.url' value='http://www.eclipse.org/objectteams'/> <property name='org.eclipse.equinox.p2.provider' value='%providerName'/> <property name='org.eclipse.equinox.p2.type.group' value='true'/> <property name='df_LT.featureName' value='Object Teams Patch for JDT/Core'/> <property name='df_LT.providerName' value='Eclipse.org - Object Teams'/> <property name='df_LT.license' value='blah'/> </properties> <provides size='2'> <provided namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.objectteams.otdt.core.patch.feature.group' version='2.1.0.201206090439'/> <provided namespace='org.eclipse.equinox.p2.localization' name='df_LT' version='1.0.0'/> </provides> <requires size='1'> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.objectteams.otdt.core.patch.feature.jar' range='[2.1.0.201206090439,2.1.0.201206090439]'> <filter> (org.eclipse.update.install.features=true) </filter> </required> </requires> <touchpoint id='null' version='0.0.0'/> <licenses size='1'> <license uri='%25licenseURL' url='%25licenseURL'> %license </license> </licenses> <copyright> blah </copyright> </unit>
Note. The relevant bit of metadata is the one in comment #31. The one in #30 is only responsible for delivering the feature.jar itself. I've looked at the code and the metadata, and here are some observations. First, I think that in the 4.3 stream, OJDT should no longer be proposed as an update because on changes on how p2 look for updates (http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=3bf447faf9eaccac362a219a6e4f804698e81840). Could you please confirm? Second, the reason why ODJT appears as an update of JDT is because of the expr2 in UpdateQuery [1] that will look at the lifecycle requirement to decide if an IU could be an update. One "hack" could consist in removing the lifecycle expression (through manual hacking of the metadata because I don't think that p2.inf supports this), but this would also disable the check that the resolver does to make sure that the patch is installed only if the element being patched is present. Because the code in expr2 has been added a while back with metadata backward compatibility in mind, a more correct solution to this problem would be to introduce a new version of the IUPatch metadata where: - the generated metadata would be changed to have the lifecycle requirement also be added as an OR to the UpdateDescriptor requirement. - the UpdateQuery changed to detect this new version of IUPatch and only consider the update descriptor - make sure that the update descriptor could be changed through p2.inf [1] - http://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.metadata/src/org/eclipse/equinox/internal/p2/metadata/query/UpdateQuery.java
This is happening for me with Juno/SR2 on Linux (32 bit). My system is set up from a base "Java" environment by incorporating plugins using the org.eclipse.equinox.p2.director command line application. I've looked over my installation and the string "objectteams" does not appear in any file nor does it appear as part of the name of any file, so I do not believe that I have "pulled in" the feature. If I run "Check for updates" on a stock Juno SR2 "for Java Developers" release I do not see the update. We do not use "Object Teams" and do not want the update. This problem is extremely annoying, since we have "Automatically check for updates" set and the availability of the bogus update causes a notification on each eclipse start, rendering the automatic updates feature essentially useless unless we accept an unwanted and unverified update that could, potentially, affect anything in the JDT. My recommendation is to move the update to a separate site until it can be made to behave safely.
(In reply to comment #33) Jim, I'm sorry the Object Teams update disrupts your process. Unfortunately, steering the "Check for Updates" feature in the intended way is beyond the might of the Object Teams project. For the juno repository it is too late to change anything, a real huge catastrophe would be needed to mandate a change of that repo after the fact. Loss of life would qualify. For Kepler I'll pursue the hints given by Pascal, hoping we can improve the situation by then. > unless we accept an unwanted and unverified update that could, potentially, > affect anything in the JDT. I'm certainly not able to vouch for 100% safety (neither for JDT nor for Object Teams, that is :) ), but let me mention that the Object Teams project uses all relevant JDT tests to avoid regressions as good as we can. As of Juno that's little short of 50000 tests for your protection. (In reply to comment #32) > Note. The relevant bit of metadata is the one in comment #31. The one in #30 > is only responsible for delivering the feature.jar itself. thanks for clarifying > I've looked at the code and the metadata, and here are some observations. > First, I think that in the 4.3 stream, OJDT should no longer be proposed as > an update because on changes on how p2 look for updates > (http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/ > ?id=3bf447faf9eaccac362a219a6e4f804698e81840). Could you please confirm? Sorry, no. I just tried: 1) unpack eclipse-platform-4.3M5a-linux-gtk.tar.gz 2) install "Eclipse Java Development Tools" from the kepler site 3) restart 4) Check for Updates -> proposes to - update Eclipse Platform - install Object Teams Patch for JDT/Core I assume M5a is recent enough to check your suggestion, right? > Second, the reason why ODJT appears as an update of JDT is because of the > expr2 in UpdateQuery [1] that will look at the lifecycle requirement to > decide if an IU could be an update. One "hack" could consist in removing the > lifecycle expression (through manual hacking of the metadata because I don't > think that p2.inf supports this), but this would also disable the check that > the resolver does to make sure that the patch is installed only if the > element being patched is present. Right, removing that stanza prevents the patch feature from being suggested. But it sounds like a bad idea to make these changes for a public repo. > Because the code in expr2 has been added a while back with metadata backward > compatibility in mind, a more correct solution to this problem would be to > introduce a new version of the IUPatch metadata where: > - the generated metadata would be changed to have the lifecycle requirement > also be added as an OR to the UpdateDescriptor requirement. > - the UpdateQuery changed to detect this new version of IUPatch and only > consider the update descriptor > - make sure that the update descriptor could be changed through p2.inf Are you saying, this strategy would require changes in p2, or could I try this as of now? (how exactly?) Pascal, please recommend how we should proceed, thanks.
Created attachment 233317 [details] Installation details
I don't know if this pertains to this bug, but executing "Check update" on my eclipse 4.3 Kepler which I use for Java development I encountered an update "Object Teams Patch for JDT/Core 2.2.0.201306071800" stating This feature is NOT a regular update of the JDT, but REPLACES the org.eclipse.jdt.core plugin by the corresponding version for Object Teams. This change makes the JDT Core capable to handle OT/J code. Both "NOT a regular update" and "REPLACES" rang my alarm bells and looking for information what this patch is about I found this bug. I have attached my Installation Details so you can judge, if I should have received this update or not.
Object Teams is jumping through several hoops to prevent unintended installation - not because it will harm, but just to give the user full control over what s/he is installing. (And yes, by replacing jdt.core we have a risk of introducing our own bugs into jdt.) Whether or not this update proposal is expected depends on what Eclipse package you originally installed. Starting from a package that already contains JDT I would not expect this proposal. If, OTOH, you started from a C/C++ package for example to which you later added JDT and others, then the above behavior is consistent with what we observed previously. I'm still willing to improve this, but for this I need a little more information from Pascal about ways to tweak p2.
Hi all, I have installed both Eclipse Standard and Eclipse for JEE Devs, Juno version on Fedora 18 64bit, and in both I was presented with the possibility of updating Object Team Patch for JDT/Core. The main problem with it was that almost all perspectives were lost after installing it. Steps to reproduce: 1. Download Eclipse standard or JEE for Dev version 2. Unzip it to /opt/eclipse 3. Open Eclipse 4. Add to Software sites "http://download.eclipse.org/releases/juno/" 5. Install Dynamic Language toolkit - Ruby Eclipse JAva Development Tools Eclipse JAva Web DEveloper Tools Eclipse Web DEveloper Tools PHP Development Tools 6. After Eclipse restarts, check perspectives available 7. Check for updates and it will promt you that "Object Team Patch for JDT/Core" package is available 8. Install it and check perspectives again. 9. No Java EE, Ruby, PyDev or Web perspectives are available 10. Uninstall "Object Team Patch for JDT/Core" 11. Check perspectives again. They're all back and available. If this is the desired functionality, at least add a warning about this to the package description. Thank you.
@Pascal, you seemed to have ideas how Object Teams could tweak the meta data to work around this problem, possibly based on some changes in p2? (In reply to Stephan Herrmann from comment #34) > (In reply to comment #32) > > Because the code in expr2 has been added a while back with metadata backward > > compatibility in mind, a more correct solution to this problem would be to > > introduce a new version of the IUPatch metadata where: > > - the generated metadata would be changed to have the lifecycle requirement > > also be added as an OR to the UpdateDescriptor requirement. > > - the UpdateQuery changed to detect this new version of IUPatch and only > > consider the update descriptor > > - make sure that the update descriptor could be changed through p2.inf > > Are you saying, this strategy would require changes in p2, or could > I try this as of now? (how exactly?) > > Pascal, please recommend how we should proceed, thanks.
for the record, this bug keeps haunting tycho users too. One workaround in tycho is to filter out the patched bundle from the target platform by restricting the version to the original one [1]: <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>target-platform-configuration</artifactId> <version>${tycho-version}</version> <configuration> <filters> <filter> <type>eclipse-plugin</type> <id>org.eclipse.jdt.core</id> <restrictTo> <!-- this is the version for Kepler SR1, have to adapt for other release trains/service releases --> <version>3.9.1.v20130905-0837</version> </restrictTo> </filter> </filters> </configuration> </plugin> [1] http://wiki.eclipse.org/Tycho/Target_Platform#Filtering
*** Bug 404209 has been marked as a duplicate of this bug. ***
I usually build my Eclipse installation by downloading the Eclipse Platform Runtime and by adding just the plugins I need, among which JDT of course. During the last years, I always got the annoying "'Object Teams Patch for JDT/Core' is not applicable to the current configuration and will not be installed." error message when checking for updates, I think it starts to come out after I update to the first SR of the annual Eclipse release. Also, I suspect that this patch may also conflict with the JDT patch provided by the Groovy-Eclipse plugin (which I need). Anyway, the fact is I don't need Object Teams, so I don't want it to be installed or to be proposed by the "Check for updates". Today I tried to examine in depth this issue, also because I had another p2 issue I wanted to solve, and I tried to understand which other plugin I use was requesting the Object Teams patch to be installed and I came to the conclusion that none does. Then I came across this bug report and I understood why this is happening :-) So, please, we're now at Eclipse 4.3 Kepler and this problem still occurs. Isn't there a way to fix it or at least a workaround?
I looked into this and found the fix. As I eluded to earlier, the problem comes from the metadata generated by default. This metadata is meant to cover for cases where the patch is intended to be consumed by the final users (and thus be visible), whereas here the patch is an implementation details of another feature. In the 'org.eclipse.objectteams.otdt.core.patch.feature.group' if you replace <lifeCycle> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.feature.group' range='0.0.0' greedy='false'/> </lifeCycle> by <lifeCycle> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.core' range='0.0.0' greedy='false'/> </lifeCycle> then objectteam will no longer show up as an update in situation where jdt is installed as a root in a product.
(In reply to Pascal Rapicault from comment #43) Good, I'll try to bake this into Luna M7. > In the 'org.eclipse.objectteams.otdt.core.patch.feature.group' if you replace > ... I guess I have to transform the XML or is there a way to author this from, say, p2.inf?
(In reply to Stephan Herrmann from comment #44) > (In reply to Pascal Rapicault from comment #43) > > Good, I'll try to bake this into Luna M7. > > > In the 'org.eclipse.objectteams.otdt.core.patch.feature.group' if you replace > > ... > > I guess I have to transform the XML or is there a way to author this from, > say, p2.inf? Transform the XML. This is not supported in p2.inf.
Recommended change implemented for Object Teams via http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/commit/?id=15dea1e38d483923577514d903266ea7c340fb66 I tested - install package eclipse-testing-luna-m6 - install from the luna repo: Eclipse Java Development Tools - setup to use these two repos: http://download.eclipse.org/eclipse/updates/4.4-I-builds http://build.eclipse.org/tools/objectteams/stagingRepo (the latter holding the latest build of Object Teams with the patch applied) Disable the luna repo (containing previous builds of Object Teams) - check for updates: -> correctly offers the latest I-build of JDT -> does *not* offer anything Object Teams - install from ...objectteams/stagingRepo -> correctly offers to install Object Teams This seems to correctly put the control back to the user. Still need to test updating from one OT version to the next. This will go into luna M7. I suggest that s.o. previously affected by this wait until first aggregation of luna m7 with new build of Object Teams is available and verify that the problem is gone. Thanks Pascal for the insider information regarding p2.
No problem Stephan. Sorry it took so long to get that to you :( Btw, note that this will work with all previous versions of p2.
(In reply to Stephan Herrmann from comment #46) > I suggest that s.o. previously affected by this wait until first aggregation > of luna m7 with new build of Object Teams is available and verify that the > problem is gone. I've contributed a warmup build of Object Teams M7 into simrel, so if any one wants to verify, you may want grab that aggregation and test that Object Teams is no longer suggested as an update. Please let me know your findings. The individual contributed Object Teams repo can also be found at http://download.eclipse.org/objectteams/updates/ot2.3-m7
Retested using luna m7 and all seems well. Closing.
I'm seeing this problem in Kepler. Can the bug be reopened?
My bad, disregard my previous comment. I didn't realize Luna is later than Kepler.
I use Tycho to build my features. I use the epp.package.dsl feature as my dependency because I use Xtext. Tycho tells me while computing the target platform this: Unable to satisfy dependency from org.eclipse.jdt.core 3.10.0.v_OTDT_r230_201406101339 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).; No solution found because the problem is unsatisfiable.] -> [Help 1] I just wanted to use the Xtext and its dependencies and not OTDT java extension. Experimenting on how the epp.package.dsl feature is build up from scratch and removing the OTDT feature from the dependencies feature list is no solution I think. What can I do?
(In reply to Udo Walker from comment #52) > What can I do? see comment 40
Another hint: (In reply to Udo Walker from comment #52) > Unable to satisfy dependency from org.eclipse.jdt.core > 3.10.0.v_OTDT_r230_201406101339 to > org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).; > No solution found because the problem is unsatisfiable.] -> [Help 1] experience tells, that often this is a spurious secondary error. If tycho also reports another resolution error, fixing the primary error also makes the secondary error go away.
The problem is that I did not see the wood for the trees when Tycho had this resolution problem. But I saw the error message mentioned above as the last message in the long list of error messages. I suppose, a better presentation of the original problem would have told me (and probably all others above) that there are other problems, too. For my problem here: 1. I used Jan's mentioned filter. 2. Then I saw my real problem. 3. I fixed my real problem. 4. I removed the filter again 5. Everything works fine now. (In reply to Stephan Herrmann from comment #54) > Another hint: > > (In reply to Udo Walker from comment #52) > > Unable to satisfy dependency from org.eclipse.jdt.core > > 3.10.0.v_OTDT_r230_201406101339 to > > org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).; > > No solution found because the problem is unsatisfiable.] -> [Help 1] > > experience tells, that often this is a spurious secondary error. > If tycho also reports another resolution error, fixing the primary error > also makes the secondary error go away.
I also see this problem with an e4 product that we have builted against Kepler using Maven/Tycho 0.20.0 (this doesn't seem to be an issue with Tycho 0.18.1) [ERROR] Failed to execute goal org.eclipse.tycho:tycho-p2-publisher-plugin:0.20.0:publish-products (default-publish-products) on project product-e4: Execution default-publish-products of goal org.eclipse.tycho:tycho-p2-publisher-plugin:0.20.0:publish-products failed: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from mykepler.platform.ide 1.0.0.qualifier to mykepler.platform.source.feature.group 0.0.0.; Unable to satisfy dependency from org.eclipse.jdt.feature.group 3.9.0.v20130605-2000 to org.eclipse.jdt.core [3.9.0.v20130604-1421].; Unable to satisfy dependency from org.eclipse.jdt.feature.group 3.9.1.v20130911-1000 to org.eclipse.jdt.core [3.9.1.v20130905-0837].; No solution found because the problem is unsatisfiable.] -> [Help 1] So, I applied Jan S's filter from comment #40, with Kepler SR2? org.eclipse.jdt.core version. <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>target-platform-configuration</artifactId> <version>${tycho-version}</version> <filters> <filter> <type>eclipse-plugin</type> <id>org.eclipse.jdt.core</id> <restrictTo> <version>3.9.1.v20130911-1000</version> </restrictTo> </filter> </filters> </configuration> </plugin> Now I get a slew of errors: [ERROR] Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from myproduct.ide.codegen.java 6.2.0.201411220106 to bundle org.eclipse.jdt.core 3.8.3.; Unable to satisfy dependency from myproduct.ide.codegen.jet.java 7.0.0.201411220106 to bundle org.eclipse.jdt.core 3.4.4.; Unable to satisfy dependency from myproduct.ide.codegen.jet.java.ui 8.1.0.201411220106 to bundle org.eclipse.jdt.core 3.6.1.; Unable to satisfy dependency from org.eclipse.ant.launching 1.0.300.v20130514-1341 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.ant.launching 1.0.300.v20140203-1328 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.ant.ui 3.5.400.v20130514-1341 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.ant.ui 3.5.400.v20140203-1328 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen 2.9.0.v20130610-0406 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen 2.9.0.v20130902-0605 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen 2.9.0.v20140203-1126 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen.ecore 2.9.0.v20130610-0406 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen.ecore 2.9.1.v20130902-0605 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen.ecore 2.9.1.v20140203-1126 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.core.manipulation 1.5.0.v20130605-1748 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.debug 3.8.0.v20130514-0841 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.debug.ui 3.6.200.v20130514-0841 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.junit 3.7.200.v20130514-0733 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.junit.core 3.7.200.v20130514-1154 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.launching 3.7.0.v20130515-1451 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.launching 3.7.1.v20131218-1102 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.ui 3.9.0.v20130605-1748 to bundle org.eclipse.jdt.core [3.9.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.ui 3.9.1.v20130820-1427 to bundle org.eclipse.jdt.core [3.9.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.ui 3.9.2.v20131106-1600 to bundle org.eclipse.jdt.core [3.9.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.core 3.9.0.v20130515-1659 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.core 3.9.1.v20130628-1111 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.launching 3.6.100.v20130507-2111 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.launching 3.6.101.v20130807-1445 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.ui 3.8.0.v20130515-1659 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.xtext.xbase 2.4.2.v201306120542 to bundle org.eclipse.jdt.core 3.5.2.; No solution found because the problem is unsatisfiable.] -> [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from myproduct.ide.codegen.java 6.2.0.201411220106 to bundle org.eclipse.jdt.core 3.8.3.; Unable to satisfy dependency from myproduct.ide.codegen.jet.java 7.0.0.201411220106 to bundle org.eclipse.jdt.core 3.4.4.; Unable to satisfy dependency from myproduct.ide.codegen.jet.java.ui 8.1.0.201411220106 to bundle org.eclipse.jdt.core 3.6.1.; Unable to satisfy dependency from org.eclipse.ant.launching 1.0.300.v20130514-1341 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.ant.launching 1.0.300.v20140203-1328 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.ant.ui 3.5.400.v20130514-1341 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.ant.ui 3.5.400.v20140203-1328 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen 2.9.0.v20130610-0406 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen 2.9.0.v20130902-0605 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen 2.9.0.v20140203-1126 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen.ecore 2.9.0.v20130610-0406 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen.ecore 2.9.1.v20130902-0605 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen.ecore 2.9.1.v20140203-1126 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.core.manipulation 1.5.0.v20130605-1748 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.debug 3.8.0.v20130514-0841 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.debug.ui 3.6.200.v20130514-0841 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.junit 3.7.200.v20130514-0733 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.junit.core 3.7.200.v20130514-1154 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.launching 3.7.0.v20130515-1451 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.launching 3.7.1.v20131218-1102 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.ui 3.9.0.v20130605-1748 to bundle org.eclipse.jdt.core [3.9.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.ui 3.9.1.v20130820-1427 to bundle org.eclipse.jdt.core [3.9.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.ui 3.9.2.v20131106-1600 to bundle org.eclipse.jdt.core [3.9.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.core 3.9.0.v20130515-1659 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.core 3.9.1.v20130628-1111 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.launching 3.6.100.v20130507-2111 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.launching 3.6.101.v20130807-1445 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.ui 3.8.0.v20130515-1659 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.xtext.xbase 2.4.2.v201306120542 to bundle org.eclipse.jdt.core 3.5.2.; No solution found because the problem is unsatisfiable.] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from myproduct.ide.codegen.java 6.2.0.201411220106 to bundle org.eclipse.jdt.core 3.8.3.; Unable to satisfy dependency from myproduct.ide.codegen.jet.java 7.0.0.201411220106 to bundle org.eclipse.jdt.core 3.4.4.; Unable to satisfy dependency from myproduct.ide.codegen.jet.java.ui 8.1.0.201411220106 to bundle org.eclipse.jdt.core 3.6.1.; Unable to satisfy dependency from org.eclipse.ant.launching 1.0.300.v20130514-1341 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.ant.launching 1.0.300.v20140203-1328 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.ant.ui 3.5.400.v20130514-1341 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.ant.ui 3.5.400.v20140203-1328 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen 2.9.0.v20130610-0406 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen 2.9.0.v20130902-0605 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen 2.9.0.v20140203-1126 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen.ecore 2.9.0.v20130610-0406 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen.ecore 2.9.1.v20130902-0605 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.emf.codegen.ecore 2.9.1.v20140203-1126 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.core.manipulation 1.5.0.v20130605-1748 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.debug 3.8.0.v20130514-0841 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.debug.ui 3.6.200.v20130514-0841 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.junit 3.7.200.v20130514-0733 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.junit.core 3.7.200.v20130514-1154 to bundle org.eclipse.jdt.core [3.5.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.launching 3.7.0.v20130515-1451 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.launching 3.7.1.v20131218-1102 to bundle org.eclipse.jdt.core [3.8.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.ui 3.9.0.v20130605-1748 to bundle org.eclipse.jdt.core [3.9.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.ui 3.9.1.v20130820-1427 to bundle org.eclipse.jdt.core [3.9.0,4.0.0).; Unable to satisfy dependency from org.eclipse.jdt.ui 3.9.2.v20131106-1600 to bundle org.eclipse.jdt.core [3.9.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.core 3.9.0.v20130515-1659 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.core 3.9.1.v20130628-1111 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.launching 3.6.100.v20130507-2111 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.launching 3.6.101.v20130807-1445 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.pde.ui 3.8.0.v20130515-1659 to bundle org.eclipse.jdt.core [3.2.0,4.0.0).; Unable to satisfy dependency from org.eclipse.xtext.xbase 2.4.2.v201306120542 to bundle org.eclipse.jdt.core 3.5.2.; No solution found because the problem is unsatisfiable.] at org.eclipse.tycho.p2.resolver.AbstractResolutionStrategy.newResolutionException(AbstractResolutionStrategy.java:98) at org.eclipse.tycho.p2.resolver.ProjectorResolutionStrategy.resolve(ProjectorResolutionStrategy.java:88) at org.eclipse.tycho.p2.resolver.AbstractResolutionStrategy.resolve(AbstractResolutionStrategy.java:63) at org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:157) at org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:107) at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.doResolveDependencies(P2TargetPlatformResolver.java:348) at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolveDependencies(P2TargetPlatformResolver.java:321) at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:109) at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:310) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) ... 11 more
> So, I applied Jan S's filter from comment #40, with Kepler SR2? > org.eclipse.jdt.core version. > > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>target-platform-configuration</artifactId> > <version>${tycho-version}</version> > <filters> > <filter> > <type>eclipse-plugin</type> > <id>org.eclipse.jdt.core</id> > <restrictTo> > <version>3.9.1.v20130911-1000</version> > </restrictTo> > </filter> > </filters> > </configuration> > </plugin> That's not an SR2 version. Please try 3.9.2.v20140114-1555 if you build against Kepler SR2.
I did try to filter with org.eclipse.jdt.core 3.9.2.v20140114-1555, but got this error which makes no sensse to me (that was why I switched back to 3.9.1.v20130911-1000, I also tried org.eclipse.jdt.core 3.9.1.v20130905-0837 (SR1?) and the the same error as SR2 version below): [ERROR] Failed to execute goal org.eclipse.tycho:tycho-p2-publisher-plugin:0.20.0:publish-products (default-publish-products) on project product-e4: Execution default-publish-products of goal org.eclipse.tycho:tycho-p2-publisher-plugin:0.20.0:publish-products failed: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from mykepler.e4.platform.ide 1.0.0.qualifier to mykepler.e4.platform.source.feature.group 0.0.0.; Unable to satisfy dependency from org.eclipse.jdt.feature.group 3.9.0.v20130605-2000 to org.eclipse.jdt.core [3.9.0.v20130604-1421].; Unable to satisfy dependency from org.eclipse.jdt.feature.group 3.9.1.v20130911-1000 to org.eclipse.jdt.core [3.9.1.v20130905-0837].; No solution found because the problem is unsatisfiable.] -> [Help 1]
Created attachment 248973 [details] minimal pom Could the missing <configuration> tag in comment 56 be the failure cause? Perhaps a problem with the repo to build against? (BTW, the simrel repo is not primarily intended as a target platform!) Anyway, I'm attaching a minimal pom which for me succeeds to link against original jdt.core from kepler SR2. Tried it with this MANIFEST: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: tycho-test Bundle-SymbolicName: tycho.test Bundle-Version: 1.0.1.qualifier Require-Bundle: org.eclipse.jdt.core;bundle-version="[3.8.0,4.0.0)" Bundle-RequiredExecutionEnvironment: J2SE-1.5 and this build.properties: bin.includes=.
I do have the <configuration> tag in my pom.xml, I missed it in the cut-n-paste in my comment #59. I am able to build from your minimal pom.xml just fine. I my pointing my Eclipse p2 URL to http://download.eclipse.org/releases/kepler/ I downgraded to Tycho 0.19.0 and that was able to build my product, along with Tycho 0.18.1. So maybe something in Tycho 0.20.0 and 0.21.0 that is causing my Maven build issues? (In reply to Stephan Herrmann from comment #59) > Created attachment 248973 [details] > minimal pom > > Could the missing <configuration> tag in comment 56 be the failure cause? > > Perhaps a problem with the repo to build against? > (BTW, the simrel repo is not primarily intended as a target platform!) > > Anyway, I'm attaching a minimal pom which for me succeeds to link against > original jdt.core from kepler SR2.
