Home » Archived » Buckminster » Missing dependency when updating using p2 update site is not automatically installed
Missing dependency when updating using p2 update site is not automatically installed [message #547045] |
Thu, 15 July 2010 08:20 |
Eclipse User |
|
|
|
Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl
Hello,
For my EMF project, I have a dependency on
org.eclipse.gmf.runtime.emf.core, for XMI serialization. I added it as
'Required Plug-in'. Then I created a p2 update site. This works.
However, when I try to install the feature containing that plug-in using
Headless Buckminster, I get:
buckminster -L DEBUG --displaystacktrace -data workspace install
<path>/site.p2/ nl.tue.cif.metamodels.feature
install '<path>/site.p2/' 'nl.tue.cif.metamodels.feature'
org.eclipse.core.runtime.CoreException: Cannot complete the install
because one or more required items could not be found.
at
org.eclipse.buckminster.installer.Install.planAndExecute(Install.java:102)
at org.eclipse.buckminster.installer.Install.run(Install.java:164)
at
org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(AbstractCommand.java:194)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:317)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:136)
at
org.eclipse.buckminster.cmdline.Headless.start(Headless.java:156)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
Contains: Software being installed: nl.tue.cif.metamodels.feature
Feature 1.0.0 (nl.tue.cif.metamodels.feature.feature.group 1.0.0)
Contains: Missing requirement: Ariadne Model 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel 1.0.0) requires 'bundle
org.eclipse.gmf.runtime.emf.core 1.4.0' but it could not be found
Contains: Cannot satisfy dependency:
Contains: From: Ariadne Edit Support 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel.edit 1.0.0)
Contains: To: bundle it.cnr.ariadne.v1x0x0.metamodel 0.0.0
Contains: Cannot satisfy dependency:
Contains: From: Ariadne Editor 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel.editor 1.0.0)
Contains: To: bundle it.cnr.ariadne.v1x0x0.metamodel.edit 0.0.0
Contains: Cannot satisfy dependency:
Contains: From: nl.tue.cif.metamodels.feature Feature 1.0.0
(nl.tue.cif.metamodels.feature.feature.group 1.0.0)
Contains: To: it.cnr.ariadne.v1x0x0.metamodel.editor [1.0.0]
Cannot complete the install because one or more required items could not
be found.
[0]Software being installed: nl.tue.cif.metamodels.feature Feature 1.0.0
(nl.tue.cif.metamodels.feature.feature.group 1.0.0)
[0]Missing requirement: Ariadne Model 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel 1.0.0) requires 'bundle
org.eclipse.gmf.runtime.emf.core 1.4.0' but it could not be found
[0]Cannot satisfy dependency:
[0.2]From: Ariadne Edit Support 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel.edit 1.0.0)
[0.2]To: bundle it.cnr.ariadne.v1x0x0.metamodel 0.0.0
[0]Cannot satisfy dependency:
[0.2]From: Ariadne Editor 1.0.0 (it.cnr.ariadne.v1x0x0.metamodel.editor
1.0.0)
[0.2]To: bundle it.cnr.ariadne.v1x0x0.metamodel.edit 0.0.0
[0]Cannot satisfy dependency:
[0.2]From: nl.tue.cif.metamodels.feature Feature 1.0.0
(nl.tue.cif.metamodels.feature.feature.group 1.0.0)
[0.2]To: it.cnr.ariadne.v1x0x0.metamodel.editor [1.0.0]
I would have expected that installing the feature that contains the
plug-in would also automatically install any of its dependencies. Why is
this not the case?
Thanks,
Dennis
|
|
| |
Re: Missing dependency when updating using p2 update site is not automatically installed [message #547248 is a reply to message #547189] |
Fri, 16 July 2010 06:29 |
Eclipse User |
|
|
|
Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl
Miles, thanks for the response.
I removed the version constraint, and created an 'Update Site Project'
in the Eclipse IDE, and added the same feature I used for my Buckminster
update site. I created a p2 update site from the Eclipse IDE, by right
clicking on site.xml and choosing 'PDE Tools' -> 'Build Site'.
I tried installing using that p2 update site, using Headless
Buckminster, into a Buckminster that has nothing but
Buckminster/PDE/Subversive. I got this:
$ <path to buckminster>/buckminster --displaystacktrace -L DEBUG -data
<path to workspace>/workspace.test.tmp install <path to local p2 update
site> nl.tue.cif.metamodels.feature
install '<path to local p2 update site>' 'nl.tue.cif.metamodels.feature'
org.eclipse.core.runtime.CoreException: Cannot complete the install
because one or more required items could not be found.
at
org.eclipse.buckminster.installer.Install.planAndExecute(Install.java:102)
at org.eclipse.buckminster.installer.Install.run(Install.java:164)
at
org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(AbstractCommand.java:194)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:317)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:136)
at
org.eclipse.buckminster.cmdline.Headless.start(Headless.java:156)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
Contains: Software being installed: nl.tue.cif.metamodels.feature
Feature 1.0.0 (nl.tue.cif.metamodels.feature.feature.group 1.0.0)
Contains: Missing requirement: Ariadne Model 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel 1.0.0) requires 'bundle
org.eclipse.gmf.runtime.emf.core 0.0.0' but it could not be found
Contains: Cannot satisfy dependency:
Contains: From: Ariadne Edit Support 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel.edit 1.0.0)
Contains: To: bundle it.cnr.ariadne.v1x0x0.metamodel 0.0.0
Contains: Cannot satisfy dependency:
Contains: From: Ariadne Editor 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel.editor 1.0.0)
Contains: To: bundle it.cnr.ariadne.v1x0x0.metamodel.edit 0.0.0
Contains: Cannot satisfy dependency:
Contains: From: nl.tue.cif.metamodels.feature Feature 1.0.0
(nl.tue.cif.metamodels.feature.feature.group 1.0.0)
Contains: To: it.cnr.ariadne.v1x0x0.metamodel.editor [1.0.0]
Cannot complete the install because one or more required items could not
be found.
[0]Software being installed: nl.tue.cif.metamodels.feature Feature 1.0.0
(nl.tue.cif.metamodels.feature.feature.group 1.0.0)
[0]Missing requirement: Ariadne Model 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel 1.0.0) requires 'bundle
org.eclipse.gmf.runtime.emf.core 0.0.0' but it could not be found
[0]Cannot satisfy dependency:
[0.2]From: Ariadne Edit Support 1.0.0
(it.cnr.ariadne.v1x0x0.metamodel.edit 1.0.0)
[0.2]To: bundle it.cnr.ariadne.v1x0x0.metamodel 0.0.0
[0]Cannot satisfy dependency:
[0.2]From: Ariadne Editor 1.0.0 (it.cnr.ariadne.v1x0x0.metamodel.editor
1.0.0)
[0.2]To: bundle it.cnr.ariadne.v1x0x0.metamodel.edit 0.0.0
[0]Cannot satisfy dependency:
[0.2]From: nl.tue.cif.metamodels.feature Feature 1.0.0
(nl.tue.cif.metamodels.feature.feature.group 1.0.0)
[0.2]To: it.cnr.ariadne.v1x0x0.metamodel.editor [1.0.0]
This looks pretty much the same as it did before, only now it lists
0.0.0 as version for the org.eclipse.gmf.runtime.emf.core dependency.
I think maybe my manifest is not ok. It looks like this:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %pluginName
Bundle-SymbolicName: it.cnr.ariadne.v1x0x0.metamodel;singleton:=true
Bundle-Version: 1.0.0
Bundle-ClassPath: .
Bundle-Vendor: %providerName
Bundle-Localization: plugin
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Export-Package: it.cnr.ariadne.v1x0x0.metamodel.ariadne,
it.cnr.ariadne.v1x0x0.metamodel.ariadne.impl,
it.cnr.ariadne.v1x0x0.metamodel.ariadne.util
Require-Bundle: org.eclipse.core.runtime,
org.eclipse.emf.ecore;visibility:=reexport,
org.eclipse.gmf.runtime.emf.core
Bundle-ActivationPolicy: lazy
In particular, do I need a 'reexport' for the
org.eclipse.gmf.runtime.emf.core bundle? What does reexport do exactly?
This is the corresponding plugin.xml:
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
<extension point="org.eclipse.emf.ecore.generated_package">
<package
uri="http://trac.parades.rm.cnr.it/ariadne/ariadne-1.0.0"
class="it.cnr.ariadne.v1x0x0.metamodel.ariadne.AriadnePackage"
genModel="model/ariadne.genmodel"/>
</extension>
<!-- Extension parser added to force xmi:id in serialization. -->
<extension point="org.eclipse.emf.ecore.extension_parser">
<parser
type="ariadne"
class="org.eclipse.gmf.runtime.emf.core.resources.GMFResourceFactory">
</parser>
</extension>
</plugin>
Dennis
Miles Parker wrote:
> Eclipse User wrote on Thu, 15 July 2010 04:20
>> Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl
>>
>> For my EMF project, I have a dependency on
>> org.eclipse.gmf.runtime.emf.core, for XMI serialization. I added it as
>> 'Required Plug-in'. Then I created a p2 update site. This works.
>> However, when I try to install the feature containing that plug-in
>> using Headless Buckminster, I get:
>
>
> Dennis,
>
> Are you sure the versioning is correct? You might try removing the
> version constraint and see if that fixes things. Also, doe the manual
> PDE p2 repos build work?
>
> -Miles
|
|
| |
Re: Missing dependency when updating using p2 update site is not automatically installed [message #547272 is a reply to message #547270] |
Fri, 16 July 2010 07:26 |
Eclipse User |
|
|
|
Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl
Thanks Hendrik. I don't need to re-export then.
However, my original problem still exists. The dependency is not
automatically installed. I would expect a dependency to the Eclipse p2
update site, from where it could automatically install any missing
dependencies.
Any idea why missing dependencies are not automatically installed?
Dennis
Henrik Lindberg wrote:
> Hi,
> On 7/16/10 8:29 AM, Dennis Hendriks wrote:
>> In particular, do I need a 'reexport' for the
>> org.eclipse.gmf.runtime.emf.core bundle? What does reexport do exactly?
>>
>
> The 'reexport' mechanism makes something that was imported by a bundle
> available to those that depend on the bundle without having to declare
> an import.
>
> This is typically useful when the only reason for importing them in a
> dependent bundle is to use functionality that exposes something that
> otherwise would not be used.
>
> A uses 'org.x.supercollections'
> B depends on A and only uses 'org.x.supercollections' because it has to
> when using A. If 'org.x.supercollections' is reexported from A, B does
> not have to depend on anything but A to be able to see this package.
>
> If you have these wrong, you would not be able to build. So, assuming
> your stuff builds, it does not matter if it got a package because it
> depends on something that reexported it, or on the bundle that exported
> it originally.
>
> Hope that helps.
> Regards
> - henrik
|
|
|
Re: Missing dependency when updating using p2 update site is not automatically installed [message #547284 is a reply to message #547272] |
Fri, 16 July 2010 08:00 |
Henrik Lindberg Messages: 2509 Registered: July 2009 |
Senior Member |
|
|
The director needs to be told which repositories to use when resolving.
Either tell it directly by listing several repositories, or use b3
aggregator to set up composite, or aggregated/mirrored repository.
Does that info help?
- henrik
Dennis Hendriks <dhendriksREMOVE_THIS@tueREMOVE.THIS.nl> wrote:
> Thanks Hendrik. I don't need to re-export then.
>
> However, my original problem still exists. The dependency is not
> automatically installed. I would expect a dependency to the Eclipse p2
> update site, from where it could automatically install any missing
> dependencies.
>
> Any idea why missing dependencies are not automatically installed?
>
> Dennis
>
>
> Henrik Lindberg wrote:
>> Hi,
>> On 7/16/10 8:29 AM, Dennis Hendriks wrote:
>>> In particular, do I need a 'reexport' for the
>>> org.eclipse.gmf.runtime.emf.core bundle? What does reexport do
> > > exactly?
>>>
>>> The 'reexport' mechanism makes something that was imported by a
> > > bundle > available to those that depend on the bundle without
> > > having to declare > an import.
>>> This is typically useful when the only reason for importing them in
> > > a > dependent bundle is to use functionality that exposes
> > > something that > otherwise would not be used.
>>> A uses 'org.x.supercollections'
>> B depends on A and only uses 'org.x.supercollections' because it has
> > to > when using A. If 'org.x.supercollections' is reexported from A,
> > B does > not have to depend on anything but A to be able to see this
> > package.
>>> If you have these wrong, you would not be able to build. So,
> > > assuming > your stuff builds, it does not matter if it got a
> > > package because it > depends on something that reexported it, or
> > > on the bundle that exported > it originally.
>>> Hope that helps.
>> Regards
>> - henrik
--
- henrik
|
|
|
Re: Missing dependency when updating using p2 update site is not automatically installed [message #547286 is a reply to message #547272] |
Fri, 16 July 2010 08:05 |
|
Hi Dennis,
Perhaps you assume that implicit dependencies will get published to your site? They won't. In order to publish a bundle,
you must publish a feature that explicitly includes that bundle (or a feature that in turn includes it). It's not enough
to list it as a requirement. The reason for this is that if all implicit requirements were traversed and published, the
created repository would contain large parts of the platform.
- thomas
On 07/16/2010 09:26 AM, Dennis Hendriks wrote:
> Thanks Hendrik. I don't need to re-export then.
>
> However, my original problem still exists. The dependency is not
> automatically installed. I would expect a dependency to the Eclipse p2
> update site, from where it could automatically install any missing
> dependencies.
>
> Any idea why missing dependencies are not automatically installed?
>
> Dennis
>
>
> Henrik Lindberg wrote:
>> Hi,
>> On 7/16/10 8:29 AM, Dennis Hendriks wrote:
>>> In particular, do I need a 'reexport' for the
>>> org.eclipse.gmf.runtime.emf.core bundle? What does reexport do exactly?
>>>
>>
>> The 'reexport' mechanism makes something that was imported by a bundle
>> available to those that depend on the bundle without having to declare
>> an import.
>>
>> This is typically useful when the only reason for importing them in a
>> dependent bundle is to use functionality that exposes something that
>> otherwise would not be used.
>>
>> A uses 'org.x.supercollections'
>> B depends on A and only uses 'org.x.supercollections' because it has
>> to when using A. If 'org.x.supercollections' is reexported from A, B
>> does not have to depend on anything but A to be able to see this package.
>>
>> If you have these wrong, you would not be able to build. So, assuming
>> your stuff builds, it does not matter if it got a package because it
>> depends on something that reexported it, or on the bundle that
>> exported it originally.
>>
>> Hope that helps.
>> Regards
>> - henrik
|
|
|
Re: Missing dependency when updating using p2 update site is not automatically installed [message #547298 is a reply to message #547286] |
Fri, 16 July 2010 09:03 |
Eclipse User |
|
|
|
Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl
Comments below.
Thomas Hallgren wrote:
> Hi Dennis,
>
> Perhaps you assume that implicit dependencies will get published to your
> site? They won't. In order to publish a bundle, you must publish a
> feature that explicitly includes that bundle (or a feature that in turn
> includes it). It's not enough to list it as a requirement. The reason
> for this is that if all implicit requirements were traversed and
> published, the created repository would contain large parts of the
> platform.
>
> - thomas
>
I didn't expect them to get published to my site. I expected them to be
listed as required, and a reference to the Eclipse update site to be
contained in my update site, so that it could automatically download
them from there.
After all, Buckminster is aware of where the dependencies come form, as
the rmap specifies where they should come from, the cquery was used to
resolve them, they were put in the target platform.
Is it not possible to have references to other update sites for the
dependencies of you features/plug-ins that are not in your own update site?
Dennis
> On 07/16/2010 09:26 AM, Dennis Hendriks wrote:
>> Thanks Hendrik. I don't need to re-export then.
>>
>> However, my original problem still exists. The dependency is not
>> automatically installed. I would expect a dependency to the Eclipse p2
>> update site, from where it could automatically install any missing
>> dependencies.
>>
>> Any idea why missing dependencies are not automatically installed?
>>
>> Dennis
>>
>>
>> Henrik Lindberg wrote:
>>> Hi,
>>> On 7/16/10 8:29 AM, Dennis Hendriks wrote:
>>>> In particular, do I need a 'reexport' for the
>>>> org.eclipse.gmf.runtime.emf.core bundle? What does reexport do exactly?
>>>>
>>>
>>> The 'reexport' mechanism makes something that was imported by a bundle
>>> available to those that depend on the bundle without having to declare
>>> an import.
>>>
>>> This is typically useful when the only reason for importing them in a
>>> dependent bundle is to use functionality that exposes something that
>>> otherwise would not be used.
>>>
>>> A uses 'org.x.supercollections'
>>> B depends on A and only uses 'org.x.supercollections' because it has
>>> to when using A. If 'org.x.supercollections' is reexported from A, B
>>> does not have to depend on anything but A to be able to see this
>>> package.
>>>
>>> If you have these wrong, you would not be able to build. So, assuming
>>> your stuff builds, it does not matter if it got a package because it
>>> depends on something that reexported it, or on the bundle that
>>> exported it originally.
>>>
>>> Hope that helps.
>>> Regards
>>> - henrik
>
|
|
|
Re: Missing dependency when updating using p2 update site is not automatically installed [message #547299 is a reply to message #547284] |
Fri, 16 July 2010 09:05 |
Eclipse User |
|
|
|
Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl
Comments below.
Henrik Lindberg wrote:
> The director needs to be told which repositories to use when resolving.
> Either tell it directly by listing several repositories, or use b3
> aggregator to set up composite, or aggregated/mirrored repository.
>
> Does that info help?
I didn't use the director, I used the Headless Buckminster's 'install'
command, which accepts exactly one update site and one feature name.
I suppose I could try to use the director instead, and list the Eclipse
Helios update site as a second repository, and see if that works.
Thanks,
Dennis
> - henrik
> Dennis Hendriks <dhendriksREMOVE_THIS@tueREMOVE.THIS.nl> wrote:
>> Thanks Hendrik. I don't need to re-export then.
>>
>> However, my original problem still exists. The dependency is not
>> automatically installed. I would expect a dependency to the Eclipse p2
>> update site, from where it could automatically install any missing
>> dependencies.
>>
>> Any idea why missing dependencies are not automatically installed?
>>
>> Dennis
>>
>>
>> Henrik Lindberg wrote:
>>> Hi,
>>> On 7/16/10 8:29 AM, Dennis Hendriks wrote:
>>>> In particular, do I need a 'reexport' for the
>>>> org.eclipse.gmf.runtime.emf.core bundle? What does reexport do
>>>> exactly?
>>>>
>>>> The 'reexport' mechanism makes something that was imported by a
>>>> bundle > available to those that depend on the bundle without
>>>> having to declare > an import.
>>>> This is typically useful when the only reason for importing them in
>>>> a > dependent bundle is to use functionality that exposes
>>>> something that > otherwise would not be used.
>>>> A uses 'org.x.supercollections'
>>> B depends on A and only uses 'org.x.supercollections' because it has
>>> to > when using A. If 'org.x.supercollections' is reexported from A,
>>> B does > not have to depend on anything but A to be able to see this
>>> package.
>>>> If you have these wrong, you would not be able to build. So,
>>>> assuming > your stuff builds, it does not matter if it got a
>>>> package because it > depends on something that reexported it, or
>>>> on the bundle that exported > it originally.
>>>> Hope that helps.
>>> Regards
>>> - henrik
>
>
|
|
|
Re: Missing dependency when updating using p2 update site is not automatically installed [message #547315 is a reply to message #547298] |
Fri, 16 July 2010 10:01 |
|
Hi Dennis,
The knowledge of a components origin isn't used during publishing since there's no way of telling if such an origin will
be available to the consumer of the created repository. It's not uncommon for instance, to use in-house mirrors as
sources to make the builds more stable.
If you want, you can specify sites that will be automatically available in the users installer. You do this by adding
the URL's of such sites in the feature.xml that you use to define your repository. Here's an example:
<url>
<discovery label="Eclipse Updates" url="http://download.eclipse.org/eclipse/updates/3.6"/>
</url>
This update site will be added as a reference in the resulting p2 repository and thus, it will be made available to the
installer. The wizard will then use this update site during install in addition to any other sites. A headless install
using the p2 director or buckminster install will not automatically use this though, so I'm not sure how helpful this is
to you.
- thomas
On 07/16/2010 11:03 AM, Dennis Hendriks wrote:
> Comments below.
>
> Thomas Hallgren wrote:
>> Hi Dennis,
>>
>> Perhaps you assume that implicit dependencies will get published to
>> your site? They won't. In order to publish a bundle, you must publish
>> a feature that explicitly includes that bundle (or a feature that in
>> turn includes it). It's not enough to list it as a requirement. The
>> reason for this is that if all implicit requirements were traversed
>> and published, the created repository would contain large parts of the
>> platform.
>>
>> - thomas
>>
>
>
> I didn't expect them to get published to my site. I expected them to be
> listed as required, and a reference to the Eclipse update site to be
> contained in my update site, so that it could automatically download
> them from there.
>
> After all, Buckminster is aware of where the dependencies come form, as
> the rmap specifies where they should come from, the cquery was used to
> resolve them, they were put in the target platform.
>
> Is it not possible to have references to other update sites for the
> dependencies of you features/plug-ins that are not in your own update site?
>
> Dennis
>
>
>> On 07/16/2010 09:26 AM, Dennis Hendriks wrote:
>>> Thanks Hendrik. I don't need to re-export then.
>>>
>>> However, my original problem still exists. The dependency is not
>>> automatically installed. I would expect a dependency to the Eclipse p2
>>> update site, from where it could automatically install any missing
>>> dependencies.
>>>
>>> Any idea why missing dependencies are not automatically installed?
>>>
>>> Dennis
>>>
>>>
>>> Henrik Lindberg wrote:
>>>> Hi,
>>>> On 7/16/10 8:29 AM, Dennis Hendriks wrote:
>>>>> In particular, do I need a 'reexport' for the
>>>>> org.eclipse.gmf.runtime.emf.core bundle? What does reexport do
>>>>> exactly?
>>>>>
>>>>
>>>> The 'reexport' mechanism makes something that was imported by a bundle
>>>> available to those that depend on the bundle without having to declare
>>>> an import.
>>>>
>>>> This is typically useful when the only reason for importing them in a
>>>> dependent bundle is to use functionality that exposes something that
>>>> otherwise would not be used.
>>>>
>>>> A uses 'org.x.supercollections'
>>>> B depends on A and only uses 'org.x.supercollections' because it has
>>>> to when using A. If 'org.x.supercollections' is reexported from A, B
>>>> does not have to depend on anything but A to be able to see this
>>>> package.
>>>>
>>>> If you have these wrong, you would not be able to build. So, assuming
>>>> your stuff builds, it does not matter if it got a package because it
>>>> depends on something that reexported it, or on the bundle that
>>>> exported it originally.
>>>>
>>>> Hope that helps.
>>>> Regards
>>>> - henrik
>>
|
|
|
Re: Missing dependency when updating using p2 update site is not automatically installed [message #547337 is a reply to message #547315] |
Fri, 16 July 2010 10:54 |
Eclipse User |
|
|
|
Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl
I guess I'll try to install using the p2 director with an additional
update site as parameter, for the headless version.
If I install in the Eclipse UI/IDE, would the dependencies then be
automatically installed, or not? Would the <discovery...> help there?
Dennis
Thomas Hallgren wrote:
> Hi Dennis,
>
> The knowledge of a components origin isn't used during publishing since
> there's no way of telling if such an origin will be available to the
> consumer of the created repository. It's not uncommon for instance, to
> use in-house mirrors as sources to make the builds more stable.
>
> If you want, you can specify sites that will be automatically available
> in the users installer. You do this by adding the URL's of such sites in
> the feature.xml that you use to define your repository. Here's an example:
>
> <url>
> <discovery label="Eclipse Updates"
> url="http://download.eclipse.org/eclipse/updates/3.6"/>
> </url>
>
> This update site will be added as a reference in the resulting p2
> repository and thus, it will be made available to the installer. The
> wizard will then use this update site during install in addition to any
> other sites. A headless install using the p2 director or buckminster
> install will not automatically use this though, so I'm not sure how
> helpful this is to you.
>
> - thomas
>
> On 07/16/2010 11:03 AM, Dennis Hendriks wrote:
>> Comments below.
>>
>> Thomas Hallgren wrote:
>>> Hi Dennis,
>>>
>>> Perhaps you assume that implicit dependencies will get published to
>>> your site? They won't. In order to publish a bundle, you must publish
>>> a feature that explicitly includes that bundle (or a feature that in
>>> turn includes it). It's not enough to list it as a requirement. The
>>> reason for this is that if all implicit requirements were traversed
>>> and published, the created repository would contain large parts of the
>>> platform.
>>>
>>> - thomas
>>>
>>
>>
>> I didn't expect them to get published to my site. I expected them to be
>> listed as required, and a reference to the Eclipse update site to be
>> contained in my update site, so that it could automatically download
>> them from there.
>>
>> After all, Buckminster is aware of where the dependencies come form, as
>> the rmap specifies where they should come from, the cquery was used to
>> resolve them, they were put in the target platform.
>>
>> Is it not possible to have references to other update sites for the
>> dependencies of you features/plug-ins that are not in your own update
>> site?
>>
>> Dennis
>>
>>
>>> On 07/16/2010 09:26 AM, Dennis Hendriks wrote:
>>>> Thanks Hendrik. I don't need to re-export then.
>>>>
>>>> However, my original problem still exists. The dependency is not
>>>> automatically installed. I would expect a dependency to the Eclipse p2
>>>> update site, from where it could automatically install any missing
>>>> dependencies.
>>>>
>>>> Any idea why missing dependencies are not automatically installed?
>>>>
>>>> Dennis
>>>>
>>>>
>>>> Henrik Lindberg wrote:
>>>>> Hi,
>>>>> On 7/16/10 8:29 AM, Dennis Hendriks wrote:
>>>>>> In particular, do I need a 'reexport' for the
>>>>>> org.eclipse.gmf.runtime.emf.core bundle? What does reexport do
>>>>>> exactly?
>>>>>>
>>>>>
>>>>> The 'reexport' mechanism makes something that was imported by a bundle
>>>>> available to those that depend on the bundle without having to declare
>>>>> an import.
>>>>>
>>>>> This is typically useful when the only reason for importing them in a
>>>>> dependent bundle is to use functionality that exposes something that
>>>>> otherwise would not be used.
>>>>>
>>>>> A uses 'org.x.supercollections'
>>>>> B depends on A and only uses 'org.x.supercollections' because it has
>>>>> to when using A. If 'org.x.supercollections' is reexported from A, B
>>>>> does not have to depend on anything but A to be able to see this
>>>>> package.
>>>>>
>>>>> If you have these wrong, you would not be able to build. So, assuming
>>>>> your stuff builds, it does not matter if it got a package because it
>>>>> depends on something that reexported it, or on the bundle that
>>>>> exported it originally.
>>>>>
>>>>> Hope that helps.
>>>>> Regards
>>>>> - henrik
>>>
>
|
|
| |
Re: Missing dependency when updating using p2 update site is not automatically installed [message #547354 is a reply to message #547299] |
Fri, 16 July 2010 12:35 |
Eclipse User |
|
|
|
Originally posted by: dhendriksREMOVE_THIS.tueREMOVE.THIS.nl
Hello,
> I suppose I could try to use the director instead, and list the
> Eclipse Helios update site as a second repository, and see if that
> works.
This indeed worked. Thanks!
Although when I first tried it, the director just returned to the
prompt. It didn't output anything, it didn't do anything. I had to
prefix the path to the local p2 update site with 'file:' in order for it
to work. It is kind of annoying that it didn't give any output or error.
It cost me some time to figure out that it needed the 'file:' prefix...
Dennis
Dennis Hendriks wrote:
> Comments below.
>
> Henrik Lindberg wrote:
>> The director needs to be told which repositories to use when resolving.
>> Either tell it directly by listing several repositories, or use b3
>> aggregator to set up composite, or aggregated/mirrored repository.
>>
>> Does that info help?
>
>
> I didn't use the director, I used the Headless Buckminster's 'install'
> command, which accepts exactly one update site and one feature name.
>
> I suppose I could try to use the director instead, and list the Eclipse
> Helios update site as a second repository, and see if that works.
>
> Thanks,
> Dennis
>
>
>
>> - henrik
>> Dennis Hendriks <dhendriksREMOVE_THIS@tueREMOVE.THIS.nl> wrote:
>>> Thanks Hendrik. I don't need to re-export then.
>>>
>>> However, my original problem still exists. The dependency is not
>>> automatically installed. I would expect a dependency to the Eclipse p2
>>> update site, from where it could automatically install any missing
>>> dependencies.
>>>
>>> Any idea why missing dependencies are not automatically installed?
>>>
>>> Dennis
>>>
>>>
>>> Henrik Lindberg wrote:
>>>> Hi,
>>>> On 7/16/10 8:29 AM, Dennis Hendriks wrote:
>>>>> In particular, do I need a 'reexport' for the
>>>>> org.eclipse.gmf.runtime.emf.core bundle? What does reexport do
>>>>> exactly?
>>>>>
>>>>> The 'reexport' mechanism makes something that was imported by a
>>>>> bundle > available to those that depend on the bundle without
>>>>> having to declare > an import.
>>>>> This is typically useful when the only reason for importing them in
>>>>> a > dependent bundle is to use functionality that exposes
>>>>> something that > otherwise would not be used.
>>>>> A uses 'org.x.supercollections'
>>>> B depends on A and only uses 'org.x.supercollections' because it has
>>>> to > when using A. If 'org.x.supercollections' is reexported from A,
>>>> B does > not have to depend on anything but A to be able to see this
>>>> package.
>>>>> If you have these wrong, you would not be able to build. So,
>>>>> assuming > your stuff builds, it does not matter if it got a
>>>>> package because it > depends on something that reexported it, or
>>>>> on the bundle that exported > it originally.
>>>>> Hope that helps.
>>>> Regards
>>>> - henrik
>>
>>
|
|
|
Goto Forum:
Current Time: Thu Sep 26 10:08:55 GMT 2024
Powered by FUDForum. Page generated in 0.04373 seconds
|