Home » Archived » Buckminster » Is there an error in the Buckybook or in Buckminster?
|
| Re: Is there an error in the Buckybook or in Buckminster? [message #511004 is a reply to message #510986] |
Fri, 29 January 2010 13:56   |
|
On 01/29/2010 02:01 PM, John wrote:
> Hi!
>
>
> In the Buckybook p. 30 example 4.4 there's and example of using redirect:
>
> <redirect href="http://www.myorg.org/maps/ourmap.rmap"
> failOnError="false" />
>
> If I use the failOnError attribute, I get the following error:
>
> ERROR [0001] : org.xml.sax.SAXParseException: cvc-complex-type.3.2.2:
> Attribute 'failOnError' is not allowed to appear in element 'redirect'.:
> file:/C:/ccview
> s/build/VOB/build/script/assemble-delivery-disk.rmap at line: 23 column: 66
>
> Is the error in the Buckybook or in Buckminster?
>
A matter of opinion I guess :-)
failOnError is not currently implemented on redirects. A redirect is final and the resolution has no way of finding it's
way back. So in that sense, the documentation is incorrect. This could be improved of course, but until that happens,
the documentation should be corrected.
Can you please file a bugzilla on this?
Thanks,
Thomas Hallgren
|
|
|
| Re: Is there an error in the Buckybook or in Buckminster? [message #511023 is a reply to message #511004] |
Fri, 29 January 2010 15:06 |
 John
Messages: 107
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas!
Thanks for the reply, but what you and the Buckybook says, contradicts my experince.
A redirect doesn't seem to be final and I would really be sad if it is, because I can really use the way it actually works.
In the Buckybook it says on p. 30:
"You can only have one redirect, and it must appear last."
According to my experience, it's possible to have a redirect before several locators and components are resolved correctly. In the following example resolution was made correctly from either the redirected rmap or the locators.
<searchPath name="PSD-CVS">
<provider
readerType="cvs"
componentTypes="eclipse.feature,osgi.bundle"
mutable="true"
source="true">
<uri format="{1},{0}">
<bc:propertyRef key="buckminster.component" />
<bc:propertyRef key="my.company.cd.build.cvs.pserver.source" />
</uri>
</provider>
</searchPath>
<redirect pattern="^my\.company\.cd\.psd\.delivery" href="file:buildpsd-disk.rmap" />
<locator searchPathRef="PSD-CVS" pattern="^my\.company\..*" />
<locator searchPathRef="PSD-CVS" pattern="^org\.eclipse\.ui\.forms\.nl" />
<locator searchPathRef="PSD-CVS" pattern="^CoreProperties" />
Currently I also have an rmap, which have three redirects without patterns following a locator. Again, I experience that components are correctly resolved from the different locations appointed by the locator and the redirected rmaps. Here's the example:
<searchPath name="ASSEMBLY-DISK">
<provider
readerType="url.catalog"
componentTypes="osgi.bundle,eclipse.feature,buckminster"
source="true">
<uri format="file:{0}/{1}">
<bc:propertyRef key="my.company.bd.build.disk.source.dir" />
<bc:propertyRef key="buckminster.component" />
</uri>
</provider>
</searchPath>
<locator searchPathRef="ASSEMBLY-DISK" pattern="^my\.company\.bd\.delivery\..*" />
<redirect href="file:psd-ncl-site.rmap" />
<redirect href="file:psd-site.rmap" />
<redirect href="file:core-site.rmap" />
Obviously I wanted to follow the documentation and ensure the first redirects doesn't fail, but apparently this isn't necessary.
Please don't break this behavior. I need it. 
Thanks.
/John
|
|
|
| Re: Is there an error in the Buckybook or in Buckminster? [message #511033 is a reply to message #511023] |
Fri, 29 January 2010 15:33 |
|
Hi John,
I think we mean different things. See inline comments:
On 01/29/2010 04:06 PM, John wrote:
> Hi Thomas!
>
>
> Thanks for the reply, but what you and the Buckybook says, contradicts
> my experince.
> A redirect doesn't seem to be final and I would really be sad if it is,
> because I can really use the way it actually works.
>
> In the Buckybook it says on p. 30:
>
> "You can only have one redirect, and it must appear last."
>
Yes, this is wrong. You can have as many redirects as you like. You can however only have one redirect that doesn't use
a pattern.
> According to my experience, it's possible to have a redirect before
> several locators and components are resolved correctly. In the following
> example resolution was made correctly from either the redirected rmap or
> the locators.
>
> <searchPath name="PSD-CVS">
> <provider readerType="cvs"
> componentTypes="eclipse.feature,osgi.bundle"
> mutable="true"
> source="true">
> <uri format="{1},{0}">
> <bc:propertyRef key="buckminster.component" />
> <bc:propertyRef key="my.company.cd.build.cvs.pserver.source" />
> </uri>
> </provider>
> </searchPath> <redirect pattern="^my\.company\.cd\.psd\.delivery"
> href="file:buildpsd-disk.rmap" />
> <locator searchPathRef="PSD-CVS" pattern="^my\.company\..*" />
> <locator searchPathRef="PSD-CVS" pattern="^org\.eclipse\.ui\.forms\.nl" />
> <locator searchPathRef="PSD-CVS" pattern="^CoreProperties" />
>
So far so good. This works.
>
> Currently I also have an rmap, which have three redirects without
> patterns following a locator. Again, I experience that components are
> correctly resolved from the different locations appointed by the locator
> and the redirected rmaps. Here's the example:
>
> <searchPath name="ASSEMBLY-DISK">
> <provider
> readerType="url.catalog"
> componentTypes="osgi.bundle,eclipse.feature,buckminster"
> source="true">
> <uri format="file:{0}/{1}">
> <bc:propertyRef key="my.company.bd.build.disk.source.dir" />
> <bc:propertyRef key="buckminster.component" />
> </uri>
> </provider>
> </searchPath>
> <locator searchPathRef="ASSEMBLY-DISK"
> pattern="^my\.company\.bd\.delivery\..*" />
>
> <redirect href="file:psd-ncl-site.rmap" />
> <redirect href="file:psd-site.rmap" />
> <redirect href="file:core-site.rmap" />
>
I can't see how the second redirect would ever get called here. The first one will be selected. If it fails, the
resolution fails. The other two redirects are dead code.
> Obviously I wanted to follow the documentation and ensure the first
> redirects doesn't fail, but apparently this isn't necessary.
>
> Please don't break this behavior. I need it. :)
>
You can always end the first redirect with a redirect to the second. And let the second continue with the third.
- thomas
|
|
| |
| Re: Is there an error in the Buckybook or in Buckminster? [message #511056 is a reply to message #511033] |
Fri, 29 January 2010 16:26 |
John
Messages: 107
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas!
Thanks for the response.
See my comments below.
| Thomas Hallgren wrote on Fri, 29 January 2010 10:33 | > Currently I also have an rmap, which have three redirects without
> patterns following a locator. Again, I experience that components are
> correctly resolved from the different locations appointed by the locator
> and the redirected rmaps. Here's the example:
>
> <searchPath name="ASSEMBLY-DISK">
> <provider
> readerType="url.catalog"
> componentTypes="osgi.bundle,eclipse.feature,buckminster"
> source="true">
> <uri format="file:{0}/{1}">
> <bc:propertyRef key="my.company.bd.build.disk.source.dir" />
> <bc:propertyRef key="buckminster.component" />
> </uri>
> </provider>
> </searchPath>
> <locator searchPathRef="ASSEMBLY-DISK"
> pattern="^my\.company\.bd\.delivery\..*" />
>
> <redirect href="file:psd-ncl-site.rmap" />
> <redirect href="file:psd-site.rmap" />
> <redirect href="file:core-site.rmap" />
>
I can't see how the second redirect would ever get called here. The first one will be selected. If it fails, the
resolution fails. The other two redirects are dead code.
|
I looked at it again and you're right. The first redirect points to an rmap, that ends with a redirect just as you suggest below. Sorry for the confusion.
| Thomas Hallgren wrote on Fri, 29 January 2010 10:33 |
> Obviously I wanted to follow the documentation and ensure the first
> redirects doesn't fail, but apparently this isn't necessary.
>
> Please don't break this behavior. I need it.
>
You can always end the first redirect with a redirect to the second. And let the second continue with the third.
- thomas
|
Unfortunately I don't see how this can fulfill my need.
We have an application, which consists of a core, which is built seperately. Then we have an application (in the future many apps), which is dependent on the core. So far so good.
However, below this we have a lot of products built independently, and they only depend on their application and the core. So for each product I can do as you suggest and use redirects to an rmap for the app, which then redirects to an rmap for core.
But in thwe end I need to assemble my RCP product, which needs all the product units, all the application units and the core unit. I really don't want to duplicate all the update site locations and all the patterns for each unit, so I was hoping I could just re-use the rmaps for each unit, since they got all I need.
Is there a way to accomplish this?
/John.
|
|
| |
| Re: Is there an error in the Buckybook or in Buckminster? [message #511113 is a reply to message #511056] |
Fri, 29 January 2010 21:46 |
|
On 01/29/2010 05:26 PM, John wrote:
> Hi Thomas!
> But in thwe end I need to assemble my RCP product, which needs all the
> product units, all the application units and the core unit. I really
> don't want to duplicate all the update site locations and all the
> patterns for each unit, so I was hoping I could just re-use the rmaps
> for each unit, since they got all I need.
>
> Is there a way to accomplish this?
>
Do you want to build everything from source at all times or would you prefer to publish the bundles to a p2 repository
and then populate a target platform from there?
- thomas
|
|
| |
| Re: Is there an error in the Buckybook or in Buckminster? [message #511129 is a reply to message #511120] |
Sat, 30 January 2010 03:26 |
|
Hi John,
An RMAP provider that points to a p2 repository (an update site) is very fast and efficient. So why not have an RMAP
searchPath that just includes all update sites? It seems to me as the extra redirection through an RMAP is redundant.
But perhaps I'm missing the point.
Regards,
Thomas Hallgren
On 01/30/2010 01:08 AM, John wrote:
> Hi Thomas!
>
>
> Each unit (defined by a feature) will be built from source idependently
> and published on it's own update site.
>
> Dependencies on other units are resolved againts these update sites
> using redirects to rmaps for each unit, which in turn uses locators to
> resolve against the units update site.
>
> Finally, we want to assemble a product. The product file includes the
> relevant features for each unit. It currently uses an rmap, which I
> hoped could also redirect to the same rmaps with locators to the units
> individual update sites, without having to duplicate the patterns needed
> for each unit.
>
> Can this be done, or do I really need to duplicate the units patterns in
> the products rmap?
>
> Thanks.
>
>
> /John
|
|
|
| Re: Is there an error in the Buckybook or in Buckminster? [message #511193 is a reply to message #511129] |
Sat, 30 January 2010 22:08 |
John
Messages: 107
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas!
Well, it's a matter of keeping things simple and to use some sense of encapsulation.
We aim at doing parallel development with each unit being developed independently and only having a contract based dependency to other units. Each unit is know by it's defining feature.
Let's say we have two units A and B.
A's feature can be: my.company.x.y.a.feature. Plugins in A may follow the general pattern my.company.x.y.a.*.., but there nay also be other conventions like org.eclipse.ui.forms.nl, which is a fragment to an Eclipse plugin.
B's feature can be my.company.m.n.b.feature. Plugins in A may follow the general pattern my.company.m.n.b.*.., but there may also be variations here.
Now, I don't really want to expose the internal naming conventions of the units if I can avoid it.
So the rmap to buld A lists all the internally known patterns in locators to build it from source. In addition I can make an rmap with pattern based locators to get it from an update site.
To build B from source I would make a similar rmap with the internally known patterns in locators to build it from source and a redirect to the site based rmap for A, without using a pattern to avoid knowing which naming standard is used in A (this is specially relevant for plugins in A that are not supposed to be known externally).
In addition I can again make an rmap with pattern based locators to get B from an update site and a redirect to the site based rmap for A, without using a pattern.
Now, to assemble my product, I just want to reuse the site rmaps for all the units that make up the product and I don't want to duplicate the knowledge of each units internal naming standard if I can avoid it. Both from an encapsulation perspective, but also because this rmap may be owned by a completely different part of our organization. So if A suddenly decides to introduce a new plugin not matching the currently used patterns, I would like to avoid having to update all the dependents rmaps.
If I only have chain of units I could use the "bottom" site rmp for this, but as it is our dependency structure between units is a tree, so I will need to list at least the pattens for all the leaves in the products rmap. E.g. C -> B -> A and D -> B -> A will require me to know the patterns for C and D. In the future the number of leaves will scale to 50-100.
Hopefully this illustrates what I attempt to achieve, but unfortunately I get the impression, that I can't do this.
Thanks.
/John.
|
|
|
| Re: Is there an error in the Buckybook or in Buckminster? [message #511195 is a reply to message #511193] |
Sat, 30 January 2010 22:34 |
|
Hi John,
I can understand the need for federated rmaps and your example would make perfect sense if you wanted to build
everything from source. But it sounds as you want to establish some level of isolation between different teams which
makes me wonder if the federated RMAP approach is the best way to go.
The complex scenario that you describe sounds similar to how we build the Eclipse release train. We decided early on
that the common 'product' of all involved producers, is a p2 update site. That way, it's very easy for others to consume
the product, regardless of how it's built. And every team that is involved creates p2 update sites anyway.
If every team produces a p2 repository, you don't even need to assemble them. Instead you create a composite repository
which essentially just references the other repositories (with no copying involved). You then consider that composite
the final product, at least during all stages of development and testing. Nested federation can be accomplished since a
composite repository can contain references to other composites.
I'm not at all sure that this would fit in your environment but I thought I'd mention it as an alternative. It's been
working well for us over some time.
Regards,
Thomas Hallgren
On 01/30/2010 11:08 PM, John wrote:
> Hi Thomas!
>
>
> Well, it's a matter of keeping things simple and to use some sense of
> encapsulation.
>
> We aim at doing parallel development with each unit being developed
> independently and only having a contract based dependency to other
> units. Each unit is know by it's defining feature.
>
> Let's say we have two units A and B.
>
> A's feature can be: my.company.x.y.a.feature. Plugins in A may follow
> the general pattern my.company.x.y.a.*.., but there nay also be other
> conventions like org.eclipse.ui.forms.nl, which is a fragment to an
> Eclipse plugin.
>
> B's feature can be my.company.m.n.b.feature. Plugins in A may follow the
> general pattern my.company.m.n.b.*.., but there may also be variations
> here.
>
> Now, I don't really want to expose the internal naming conventions of
> the units if I can avoid it.
>
> So the rmap to buld A lists all the internally known patterns in
> locators to build it from source. In addition I can make an rmap with
> pattern based locators to get it from an update site.
>
> To build B from source I would make a similar rmap with the internally
> known patterns in locators to build it from source and a redirect to the
> site based rmap for A, without using a pattern to avoid knowing which
> naming standard is used in A (this is specially relevant for plugins in
> A that are not supposed to be known externally).
>
> In addition I can again make an rmap with pattern based locators to get
> B from an update site and a redirect to the site based rmap for A,
> without using a pattern.
>
> Now, to assemble my product, I just want to reuse the site rmaps for all
> the units that make up the product and I don't want to duplicate the
> knowledge of each units internal naming standard if I can avoid it. Both
> from an encapsulation perspective, but also because this rmap may be
> owned by a completely different part of our organization. So if A
> suddenly decides to introduce a new plugin not matching the currently
> used patterns, I would like to avoid having to update all the dependents
> rmaps.
>
> If I only have chain of units I could use the "bottom" site rmp for
> this, but as it is our dependency structure between units is a tree, so
> I will need to list at least the pattens for all the leaves in the
> products rmap. E.g. C -> B -> A and D -> B -> A will require me to know
> the patterns for C and D. In the future the number of leaves will scale
> to 50-100.
>
> Hopefully this illustrates what I attempt to achieve, but unfortunately
> I get the impression, that I can't do this.
>
> Thanks.
>
> /John.
|
|
| |
| Re: Is there an error in the Buckybook or in Buckminster? [message #511654 is a reply to message #511643] |
Tue, 02 February 2010 12:49 |
|
On 02/02/2010 12:26 PM, John wrote:
> Hi Thomas!
>
>
> I have been having the same thoughts myself.
> We've introduced Buckminster late in our project and it has worked well
> for us when building everything from one source location.
> Now that we want to split it into units we can also build them
> independently using federated rmaps for this purpose.
> For assembling the product we have just assumed we could continue using
> the same strategy, but I think it makes sense to make a composite rmap.
>
> I've been reading the "Shipping" section in the Buckybook and
> unfortunately it's more what than how.
> It's not easy to use it as a guideline for which approach to take, when
> you're not familiar with all the approaches.
> However, I think it makes sense to try using the Buckminster Aggregator
> support.
> Is this also the approach you'll recommend?
>
Yes.
> ...
>
> Now when building the repository I get the following error:
>
> ...
> Contains: Software being installed:
> all.contributed.content.feature.group 1.0.0
> Contains: Missing requirement: Install/Update UI 3.2.100.v20080318
> (org.eclipse.update.ui 3.2.100.v20080318) requires 'package
> javax.xml.parsers 0.0.0' but it could not be found
> Contains: Cannot satisfy dependency:
> Contains: From: all.contributed.content.feature.group 1.0.0
> Contains: To: my.company.rcp_extra.feature.feature.group [1.0.0]
> Contains: Cannot satisfy dependency:
> Contains: From: Feature Feature 1.0.0
> (my.company.rcp_extra.feature.feature.group 1.0.0)
> Contains: To: org.eclipse.update.ui [3.2.100.v20080318]
>
The aggregator generates a top level feature 'all.contributed.content.feature.group' that in turn, includes all features
to aggregate. It passes this feature to p2 and asks it to come up with a plan. The planner fails and the messages above
can be interpreted by following each branch from the top feature. So there are two distinct problems:
Install/Update UI 3.2.100.v20080318 (org.eclipse.update.ui 3.2.100.v20080318) requires 'package javax.xml.parsers 0.0.0'
but it could not be found
and
From: Feature Feature 1.0.0 (my.company.rcp_extra.feature.feature.group 1.0.0) To: org.eclipse.update.ui [3.2.100.v20080318]
In this case, the second problem is a consequence of the first. So your interpretation is correct. It really cannot find
the package 'javax.xml.parsers' and that is the one and only problem. The version '0.0.0' is actually not a version at
all. It's an indication that the requirement has no version constraint.
> In the update site http://mysiteserver/core-site/dev I have a pluging
> my.company.bd.core.
> It contains the file rt.jar in which the package javax.xml.parsers exists.
> This works fine when building the usual way, so what is the problem here
> when trying to build an aggregated site?
>
My guess is that when you build the usual way, the requirement is resolved against the Java runtime library and that the
bundle in question has no export declared for the 'java.xml.parsers' package. It might also be related to lack of
execution environment in the bundle manifest. If I recall correctly, the javax.xml.parsers package was introduced as a
runtime package in Java 1.5.
Regards,
Thomas Hallgren
|
|
| |
| Re: Is there an error in the Buckybook or in Buckminster? [message #511714 is a reply to message #511670] |
Tue, 02 February 2010 15:59 |
|
On 02/02/2010 02:47 PM, John wrote:
> Hi Thomas!
>
> My mistake. I overlooked that rt.jar of course is part of the runtime
> environment. It's not an embedded jar in the plugin my.company.bd.core,
> so this one is probably not part of the problem.
>
> Thomas Hallgren wrote on Tue, 02 February 2010 07:49
>> My guess is that when you build the usual way, the requirement is
>> resolved against the Java runtime library and that the bundle in
>> question has no export declared for the 'java.xml.parsers' package. It
>> might also be related to lack of execution environment in the bundle
>> manifest. If I recall correctly, the javax.xml.parsers package was
>> introduced as a runtime package in Java 1.5.
>
>
> I'm not sure how to understand what you say here.
That makes two of us :-)
> The feature
> com.nordea.rcp_extra.feature can't declare an export or execution
> environment - correct? It only contains org.eclipse and org.apache
> plugins. Do you mean that org.eclipse.update.ui doesn't declare an
> export or execution environment? Since I haven't specified any runtime
> in the aggregator model, I assume I'm running with the default JDK 1.6
> my Eclipse is using?
>
I made some research.
When you publish a product (i.e. an RCP app, an Eclipse IDE, etc.) the publisher will ensure that the repository will
contain an installable unit that represents the required java runtime. Such an IU must be present in at least one of the
repositories that you use as source for your aggregation. The repository doesn't have to be mirrored though, using it as
a 'validation repository' will do fine.
If you care to look into the repository, you should find an entry similar to this:
<unit id='a.jre.javase' version='1.6.0' singleton='false'>
<provides size='159'>
<provided namespace='org.eclipse.equinox.p2.iu' name='a.jre.javase' version='1.6.0'/>
<provided namespace='java.package' name='javax.accessibility' version='0.0.0'/>
<provided namespace='java.package' name='javax.activation' version='0.0.0'/>
<provided namespace='java.package' name='javax.activity' version='0.0.0'/>
<provided namespace='java.package' name='javax.annotation' version='0.0.0'/>
... A long list of packages
Regards,
Thomas Hallgren
|
|
|
| Re: Is there an error in the Buckybook or in Buckminster? [message #511882 is a reply to message #511714] |
Wed, 03 February 2010 10:30 |
John
Messages: 107
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas!
Thanks for the response, but I'm still confused.
| Thomas Hallgren wrote on Tue, 02 February 2010 10:59 | I made some research.
When you publish a product (i.e. an RCP app, an Eclipse IDE, etc.) the publisher will ensure that the repository will
contain an installable unit that represents the required java runtime.
|
Do you mean that I publish a product? I don't [edit - hmmm... I can actually see some org.eclipse plugins on one of my update sites. I'm not sure why they are there. I'll look into that, but I would still like to know if my understanding of validation is completely off]. I have right now three update sites with features and plugins. The product is not in any way on an update site. So I still don't understand why any validation needs to be done for aggregating these three update sites.
But I can see from the documentation that validation and aggregation is closely connected. I initially understood validation as validation of the model, but didn't imagine it to be a transitive verification of existence of all dependencies.
Why is validation and aggregation so closely connected? If I don't want to make a completely self contained aggregated update site, I find it reasonable of the consumer of the aggregated update site, to provide the missing dependencies in some other way when using my update site.
Just like when I created my three update sites. All necessary dependencies were in place in order to create them, but the transitive dependencies are not published on these update sites. So it must be reasonable to expect, that since it was possible to create the update sites, it's also possible to get their dependencies from somewhere else and that it's not necessary to validate that just to create the aggregated update site.
The consumer of the aggregated update site will then be in the same situation as when using the three update sites directly. The transitive dependencies must be provided in some other way.
So is there some point I'm missing here? I understand the motivation described in the introduction of the document, but is it really necessary to make transitive validation a prerequisite for making an aggregated update site? Couldn't it be possible to just disable validation and still have aggregation?
| Thomas Hallgren wrote on Tue, 02 February 2010 10:59 | Such an IU must be present in at least one of the
repositories that you use as source for your aggregation. The repository doesn't have to be mirrored though, using it as
a 'validation repository' will do fine.
If you care to look into the repository, you should find an entry similar to this:
<unit id='a.jre.javase' version='1.6.0' singleton='false'>
<provides size='159'>
<provided namespace='org.eclipse.equinox.p2.iu' name='a.jre.javase' version='1.6.0'/>
<provided namespace='java.package' name='javax.accessibility' version='0.0.0'/>
<provided namespace='java.package' name='javax.activation' version='0.0.0'/>
<provided namespace='java.package' name='javax.activity' version='0.0.0'/>
<provided namespace='java.package' name='javax.annotation' version='0.0.0'/>
... A long list of packages
Regards,
Thomas Hallgren
|
Ok, in case I really have to validate I decided to try it out. First I was a bit uncertain on how to include validation of packages in a jre. Is there a p2 update site with jre jars somewhere?
But I added a Validation Repository to my model and found that it has a Nature property that isn't described in the document. In the Properties view I can select the edit field for both Enabled and Location. But when I try to edit Nature, the Error Log view pops up with the error below. Do I miss something in my installation?
I hope you can help me with getting this validation to work.
Thanks.
/John
eclipse.buildId=I20090611-1540
java.version=1.6.0_07
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=da_DK
Framework arguments: -product org.eclipse.epp.package.rcp.product clean
Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.rcp.product clean
Error
Wed Feb 03 11:17:38 CET 2010
Unhandled event loop exception
java.lang.ClassCastException: org.eclipse.buckminster.aggregator.impl.MetadataRepositoryRe ferenceImpl cannot be cast to org.eclipse.buckminster.aggregator.MappedRepository
at org.eclipse.buckminster.aggregator.provider.MetadataReposito ryReferenceItemProvider$2.getChoiceOfValues(MetadataReposito ryReferenceItemProvider.java:403)
at org.eclipse.emf.edit.ui.provider.PropertyDescriptor.createPr opertyEditor(PropertyDescriptor.java:428)
at org.eclipse.ui.views.properties.PropertySheetEntry.getEditor (PropertySheetEntry.java:378)
at org.eclipse.ui.views.properties.PropertySheetViewer.activate CellEditor(PropertySheetViewer.java:163)
at org.eclipse.ui.views.properties.PropertySheetViewer.handleSe lect(PropertySheetViewer.java:727)
at org.eclipse.ui.views.properties.PropertySheetViewer.access$8 (PropertySheetViewer.java:707)
at org.eclipse.ui.views.properties.PropertySheetViewer$6.mouseD own(PropertySheetViewer.java:816)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:179)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3880)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3473)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2405)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 21)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
at org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:493)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:194)
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(EclipseS tarter.java:368)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
[Updated on: Wed, 03 February 2010 10:41] Report message to a moderator |
|
|
| Re: Is there an error in the Buckybook or in Buckminster? [message #511892 is a reply to message #511882] |
Wed, 03 February 2010 05:58 |
|
On 02/03/2010 11:30 AM, John wrote:
> Hi Thomas!
>
>
> Thanks for the response, but I'm still confused.
>
> Thomas Hallgren wrote on Tue, 02 February 2010 10:59
>> I made some research.
>>
>> When you publish a product (i.e. an RCP app, an Eclipse IDE, etc.) the
>> publisher will ensure that the repository will contain an installable
>> unit that represents the required java runtime.
>
>
> Do you mean that I publish a product?
No, I mean that this only happens when you do.
> I don't. I have right now three
> update sites with features and plugins. The product is not in any way on
> an update site. So I still don't understand why any validation needs to
> be done for aggregating these three update sites.
>
The reason is that a repository that isn't validated is likely to cause problems for the end user when he tries to
install from it.
> But I can see from the documentation that validation and aggregation is
> closely connected. I initially understood validation as validation of
> the model, but didn't imagine it to be a transitive verification of
> existence of all dependencies.
>
> Why is validation and aggregation so closely connected? If I don't want
> to make a completely self contained aggregated update site, I find it
> reasonable of the consumer of the aggregated update site, to provide the
> missing dependencies in some other way when using my update site.
>
Yes. That makes sense. And that is why we provide 'validation repositories'. They are not part of the aggregated result
but they do participate in the validation. You should provide the same validation repositories when you perform the
aggregation that you then expect the end user to include when he installs from your 'non self contained' update site.
HTH,
Thomas Hallgren
|
|
| |
| Re: Is there an error in the Buckybook or in Buckminster? [message #511934 is a reply to message #511923] |
Wed, 03 February 2010 13:23 |
|
Hi John,
On 02/03/2010 01:42 PM, John wrote:
> Hi Thomas!
>
>
> Thanks. It sounds to me like aggregation could be done without
> validation, it's just not implemented that way. Could it be a feature
> request or do you not like the idea?
>
I could certainly be a feature request. The reason it's not done that way now is that we use the p2 planner, not just to
validate, but also to figure out what exactly needs to be aggregated from a set of given features. I.e. the planner is
responsible for computing the transitive closure. This cannot be done if no plan can be produced. In case you want to
aggregate everything from a repository, computing what needs to be aggregated is of course not necessary.
Please enter the feature request as a bugzilla on EMFT/b3 as we plan to make b3 the new home for the aggregator.
> Do you have any response to the second part of my post regarding
> problems with editing properties for a Validation Repository?
>
That sounds like a bug in the aggregator.
> How do I specify a jre as a Validation Repository? When I have built my
> update sites I have had one dependency on a target platform, that
> Buckminster accepts. It's of course organized with features and plugins
> folders, but there is no artifacts.jar and content.jar. I have set this
> as a Validation Repository, but still have the other problem with the
> jre dependency.
>
You can use Galileo or Helios as validation repository. They both include a jre. The Eclipse platform would work too
(i.e. http://download.eclipse.org/eclipse/updates/3.5).
> I was running with Buckminster installed from Galileo -
> http://download.eclipse.org/releases/galileo and Accregator installed
> from Buckminster -
> http://download.eclipse.org/tools/buckminster/updates-3.5, when I got
> the error mentioned.
>
> I have now uninstalled everything and installed all of Buckminster
> including aggregator from Buckminster -
> http://download.eclipse.org/tools/buckminster/updates-3.5
>
> I still have the same problem and now several more erros are appearing.
> When I install there doesn't seem to be any missing dependencies mentioned.
>
If it's installed succesfully, there shouldn't be anything missing. So please file a bugzilla with the errors attached.
Regards,
Thomas Hallgren
|
|
| |
| Re: Is there an error in the Buckybook or in Buckminster? [message #512515 is a reply to message #512510] |
Fri, 05 February 2010 06:00 |
|
Hi John,
One way to find out where the dependency comes from is to run the CQUERY in your IDE with 'Continue on error' checked
and then save the BOM (BillOfMaterials) when it completes. You can then open that BOM with our dependency viewer. The
unresolved node will be clearly marked in red so it's easy to find the components that depends on it.
Regards,
Thomas Hallgren
On 02/05/2010 11:45 AM, John wrote:
> Hi Thomas!
>
>
> Thanks for all the help. The aggregated site now builds without errors.
> I currently have it copying everything to disk so I can study the result.
> It looks correct as it seems like I have all our features and plugins
> from the three update sites in my aggregated repository on disk.
>
> The model is here:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <aggregator:Aggregator xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:aggregator="http://www.eclipse.org/buckminster/2009/aggregator"
> description="The aggregated update site for NBD" label="NBD"
> buildRoot="/temp/bmaggregator/build">
> <configurations/>
> <contributions label="NBD">
> <repositories location="http://mysiteserver/core-site/dev">
> <metadataRepository
> href="p2:http://mysiteserver/core-site/dev#//@metadataRepository"/>
> </repositories>
> <repositories location="http://mysiteserver/psd-site/dev">
> <metadataRepository
> href="p2:http://mysiteserver/psd-site/dev#//@metadataRepository"/>
> </repositories>
> <repositories location="http://mysiteserver/psd-ncl-site/dev">
> <metadataRepository
> href=" p2:http://mysiteserver/psd-ncl-site/dev#//@metadataRepositor y"/>
> </repositories>
> </contributions>
> <validationRepositories
> location="file:///C:/ccviews/psd_dev_1_2_30/NTP_NCD/src/RCP/RCP-RUN">
> <metadataRepository
> href=" p2:file:///C:/ccviews/psd_dev_1_2_30/NTP_NCD/src/RCP/RCP-RUN #//@metadataRepository"/>
>
> </validationRepositories>
> <validationRepositories
> location="http://download.eclipse.org/releases/galileo">
> <metadataRepository
> href=" p2:http://download.eclipse.org/releases/galileo#//@metadataR epository"/>
>
> </validationRepositories>
> </aggregator:Aggregator>
>
> As you can see I have one contribution with the three update sites.
> Then I have the validation repository
> C:/ccviews/psd_dev_1_2_30/NTP_NCD/src/RCP/RCP-RUN.
> This is a downloaded RCP 3.4, which is currently our target platform.
>
> Finally I have the validation repository
> http://download.eclipse.org/releases/galileo
> in order to validate JRE dependencies. I don't know if anything is
> validated against this as well,
> since all dependencies can be validated without error, but at least I
> know it's not directly needed from our code.
> This because I know I can build our product against the three update
> sites and using our 3.4 target platform.
>
> When I now try to build our product against this aggregated update site,
> I end up with the following error:
>
> ERROR [0000] : No suitable provider for component
> org.eclipse.rcp:eclipse.feature/[3.5.1.R35x_v20090811-9SA0Fx
> VFqE70OL1ARMrfcO6e7BA6,3.5.1.R35x_v20090811-9SA0FxVFqE70OL1A RMrfcO6e7BA6]
> was found in resourceMap
> file:/C:/ccviews/psd_build_main_latest/NTP_NCD/build/script/
> assemble-delivery-disk.rmap
> ERROR [0000] : No suitable provider for component
> org.eclipse.rcp:eclipse.feature/[3.5.1.R35x_v20090811-9SA0Fx
> VFqE70OL1ARMrfcO6e7BA6,3.5.1.R35x_v20090811-9SA0FxVFqE70OL1A RMrfcO6e7BA6]
> was found in searchPath ASSEMBLY-SITE
> ERROR [0000] : Rejecting provider
> eclipse.import( file:///C:/Project/PSD/workspaces/bmaggregator/my.company.ag gregator/temp/bmaggregator/build/final?importType=binary):
>
> No component match was found
>
> Where does this dependency to a 3.5.1 feature come from?
> Is this introduced in the aggregated repository due to the validation
> against the Galileo update site?
>
> Thanks.
>
>
> /John
|
|
| | |
| Re: Is there an error in the Buckybook or in Buckminster? [message #515086 is a reply to message #515020] |
Wed, 17 February 2010 16:41 |
|
Hi John,
Can you please file a bugzilla for this issue on emft/b3/aggregator.
Thanks,
Thomas Hallgren
On 02/17/2010 03:05 PM, John wrote:
> Hi!
>
> As mentioned I was unable to resolve against my aggregated site if I set
> Mirror Artifacts = false for the three mapped repositories involved.
>
> At first I was hunting down "the usual suspect" - the company proxy, but
> I soon discovered that it wasn't the reason. My test case from home also
> worked at work.
>
> Then I tried having the three sites on my disk and aggregate them
> without mirroring, and it still didn't work.
>
> The only difference I could tell between this and my test case was, that
> I had decided to fill in Category Prefix for the mapped repositories
> involved. So I put in a different value for the three sites and suddenly
> it worked. Also when aggregating against the sites on our server.
>
> So for some reason it's required to have a value in Category Prefix for
> a mapped repository when using Mirror Artifacts = false. If Mirror
> Artifacts = true, there's no need to have a value in Category Prefix.
>
> /John
|
|
| | | |
Goto Forum:
Current Time: Wed Feb 05 16:52:42 GMT 2025
Powered by FUDForum. Page generated in 0.06795 seconds |
] 
Search
Help
Register
Login
Home
