[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [buckminster-dev] Strange resolver behaviour when resolving PDE plugins - using "native" target platform
|
Hi Mikhail,
What platform are you using? Is it an Eclipse 3.3.x or 3.4.x? And what
is the version on your org.eclipse.buckminster.core.feature?
Regards,
Thomas Hallgren
Mikhail Kadan wrote:
Hi.
Found another strange issue.
In my target platform I have two versions of "org.eclipse.emf.common":
1) 2.3.0
2) 2.3.2
Issue #1: When I try to resolve "org.eclipse.emf.common" w/o version
specification, Buckminster gives me "2.3.0" version. Strange, cause it
has to give me the latest version, am I right?
Issue #2: When I try to resolve "org.eclipse.emf.common" with version
specification set to "[2.3.1,3.0.0)", Buckminster returns an error.
Log says:
...
org.eclipse.emf.common:osgi.bundle/[2.3.1,3.0.0)#OSGi: Using resolver rmap
org.eclipse.emf.common:osgi.bundle/[2.3.1,3.0.0)#OSGi: Version
2.3.0.v200709252135 rejected: not designated by [2.3.1,3.0.0)
org.eclipse.emf.common:osgi.bundle/[2.3.1,3.0.0)#OSGi: Rejecting
provider eclipse.platform(plugin/${buckminster.component}): No
component match was found
org.eclipse.emf.common:osgi.bundle/[2.3.1,3.0.0)#OSGi: Using resource
map file:/C:/Work/workspaces/xdoc/bm/xdoc.rmap
org.eclipse.emf.common:osgi.bundle/[2.3.1,3.0.0)#OSGi: No searchPath
was found with a matching pattern
org.eclipse.emf.common:osgi.bundle/[2.3.1,3.0.0)#OSGi: Using resolver
cloudsmith
...
So, based on this two issues, I think Buckminster ignores my second
plugin. I guess Buckminster's "eclipse.platform" support only one
version of plugin, and he takes the first one in lexicographical order?
What can be done to fix this issue? Or I just have to remove old
plugins from my target platform? :-)
Thanks.
ps I've used "Refresh Meta-data" button from Buckminster preferences,
but it didn't help too :'(
2008/5/26, Thomas Hallgren <thomas@xxxxxxx <mailto:thomas@xxxxxxx>>:
Hi Mikhail,
Mikhail Kadan wrote:
So I can made a conclusion, that Buckminster also searches his
"native" target platform (target platform which was used to
start Eclipse), and if it finds a match here, which has bigger
version than others, it will try to materialize this plugin
from "native" platform.
Yes, your conclusion is correct.
How can I set Buckminster not to look in his "native" target
platform for plugins?
You declare an advisory node in the component query where you omit
the target platform from the resolution scope (see the "Resolution
Scope" pane under the "Advisor node" tab in the CQUERY editor.
ps By the way, can anyone provide example how
"eclipse.platform" reader works? I've tried such RMAP but
couldn't get it to work:
The "eclipse.platform" reader type is for internal use only. You
should not use it in an RMAP.
Regards,
Thomas Hallgren
_______________________________________________
buckminster-dev mailing list
buckminster-dev@xxxxxxxxxxx <mailto:buckminster-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/buckminster-dev
------------------------------------------------------------------------
_______________________________________________
buckminster-dev mailing list
buckminster-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/buckminster-dev