Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Buckminster » Bucky + Hudson does not retrieve platform-specific launchers
Bucky + Hudson does not retrieve platform-specific launchers [message #512222] Thu, 04 February 2010 12:49 Go to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi guys,

not sure if this is the right place to ask. I've been following Ralf
Ebert's (awesome! Thanks Elbert!) tutorial to make a headless build of
an eclipse RCP using Hudson and Buckminster. I've managed to export the
RCP correctly using bucky commands from within Eclipse. The problem
comes when I try to build from Hudson.

Bucky imports the target definition correctly from the workspace. My
target definition includes Eclipse Delta Pack to build the product for
multiple platforms.

importtargetdefinition -A
'${WORKSPACE}/com.opencanarias.mset.rosetta.site.feature/OC- Rosetta-TP-Definition.target'

Then the component query is imported:

import '${WORKSPACE}/com.opencanarias.mset.rosetta.site.feature/sit e.cquery'

And here comes the failure. Bucky doesn't seem to be able to resolve
some platform specific fragments. But not all fragments, but only those
Equinox Launcher. What is strange is that it actually resolves other
platform specific fragments, like those from SWT. And what's more
strange, the only Equinox Launcher fragment that's is imported is the
one from win32 (well, our hudson is being executed in a windows 2003
server...). Let me add some debug messages

Here the message for win32 fragment:

org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Using resolver
Local resolver
org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Trying
provider local(materialized)
No materialization found for
org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle
org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Trying
provider local(workspace)
No open workspace project found that corresponds to
org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle
org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Trying
provider local(target)
org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Found match
1.0.200.v20090519
org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Found match
org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle$1.0 .200.v20090519


As you see, it first looks at the target platform, finds a match and
selects it. Now lets look at what happens at, for instance, a macosx
equinox launcher fragment. What is weird about this case is that it
actually finds a match in the target platform, but doesn't select it!

org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using resolver
Local resolver
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
local(materialized)
No materialization found for
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
local(workspace)
No open workspace project found that corresponds to
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
local(target)
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Found match
1.0.0.v20090519
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using resource
map
file:/C:/Hudson/jobs/OC-Rosetta/workspace/com.opencanarias.m set.rosetta.site.feature/site.rmap
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using search path
resources
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
local({0}/{1}/)
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Found match
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using provider
local({0}/{1}/)
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Resolution
attempt ended with exception: Provider
local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
Missing CSpec source required by component type osgi.bundle
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: No provider was
found that could resolve the request
ERROR [0000] : No suitable provider for component
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
resourceMap
file:/C:/Hudson/jobs/OC-Rosetta/workspace/com.opencanarias.m set.rosetta.site.feature/site.rmap
ERROR [0000] : No suitable provider for component
org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
searchPath resources
ERROR [0000] : Resolution attempt ended with exception: Provider
local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
Missing CSpec source required by component type osgi.bundle
ERROR Provider
local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
Missing CSpec source required by component type osgi.bundle

Do you guys have a clue why a match is being found, but not being
selected for the component query resolution?

A bit more insight about our build configuration:

- We have one single feature definition that includes ALL plugins from
our product, but only those that are platform independent.

- Then another feature includes all platform specific fragments (i.e.,
filesystem provider, SWT...). This was needed because otherwise PDE
Export would not include them, and the exported RCP would not work.

- our target platform is all stored in our SVN, so we don't resolve them
from p2 update sites.

One of the things I was stuck was that, while trying the build from
within eclipse and bucky, I had to set some flags (operative system,
window system and architecture) at the feature definition for platform
specific fragments, otherwise I would get an error. Also bucky is
sensitive for things like the language flag, so I removed them all.

I've tried many combinations:
- adding "org.eclipse.equinox.executable" feature, and removing it
- removing delta pack from target platform. That would drop more errors,
since things like SWT fragments won't be resolved.
- adding/removing equinox launcher from the feature that contains all
platform specific fragments/bundles
- modifying the "the product includes native launchers artifacts" flag
in the product definition.
- adding P2 site to the platform definition.

Sorry for the long post. Would like to hear your comments.

Cheers,
Víctor.
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512241 is a reply to message #512222] Thu, 04 February 2010 13:25 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
Hi Víctor,

Víctor Roldán Betancort schrieb:

> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using search path
> resources
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
> local({0}/{1}/)
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Found match
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using provider
> local({0}/{1}/)
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Resolution
> attempt ended with exception: Provider
> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
> Missing CSpec source required by component type osgi.bundle
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: No provider was
> found that could resolve the request
> ERROR [0000] : No suitable provider for component
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
> resourceMap
> file:/C:/Hudson/jobs/OC-Rosetta/workspace/com.opencanarias.m set.rosetta.site.feature/site.rmap
>
> ERROR [0000] : No suitable provider for component
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
> searchPath resources
> ERROR [0000] : Resolution attempt ended with exception: Provider
> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
> Missing CSpec source required by component type osgi.bundle
> ERROR Provider
> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
> Missing CSpec source required by component type osgi.bundle
>

C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equinox.laun cher.cocoa.macosx/
Does this directory exist, and if so, what does it contain?

Best regards,
Johannes
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512244 is a reply to message #512241] Thu, 04 February 2010 08:50 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi Johannes,

thanks for your response. No, that directory does not exist.
However, im not sure if its supposed to exist. That bundle should be
resolved in the locator for the target platform, which is executed before :

org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
local(target)

org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Found match
1.0.0.v20090519

A match is actually found, but for some reason is not resolved.

In the case of the win32 x86, that directory doesn't exist either,
but it is resolved successfully.

I can't really see what's different in one case and the other.

Cheers,
Víctor.

Johannes Utzig escribió:
> Hi Víctor,
>
> Víctor Roldán Betancort schrieb:
>
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using search
>> path resources
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
>> local({0}/{1}/)
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Found match
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using provider
>> local({0}/{1}/)
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Resolution
>> attempt ended with exception: Provider
>> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
>> Missing CSpec source required by component type osgi.bundle
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: No provider was
>> found that could resolve the request
>> ERROR [0000] : No suitable provider for component
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
>> resourceMap
>> file:/C:/Hudson/jobs/OC-Rosetta/workspace/com.opencanarias.m set.rosetta.site.feature/site.rmap
>>
>> ERROR [0000] : No suitable provider for component
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
>> searchPath resources
>> ERROR [0000] : Resolution attempt ended with exception: Provider
>> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
>> Missing CSpec source required by component type osgi.bundle
>> ERROR Provider
>> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
>> Missing CSpec source required by component type osgi.bundle
>>
>
> C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equinox.laun cher.cocoa.macosx/
>
> Does this directory exist, and if so, what does it contain?
>
> Best regards,
> Johannes
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512254 is a reply to message #512222] Thu, 04 February 2010 14:00 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Víctor,
The macosx fragment that is found is immediately rejected because of a filter mismatch. I checked the code and
Buckminster does that without logging it. That's unfortunate and I'll fix that.

The reason you get a filter mismatch is probably that your import is run without wildcard settings for the properties
target.os, target.ws, and target.arch. I.e.

target.os=*
target.ws=*
target.arch=*

Without these settings, the values default to the current platform.

Regards,
Thomas Hallgren

On 02/04/2010 01:49 PM, Víctor Roldán Betancort wrote:
> Hi guys,
>
> not sure if this is the right place to ask. I've been following Ralf
> Ebert's (awesome! Thanks Elbert!) tutorial to make a headless build of
> an eclipse RCP using Hudson and Buckminster. I've managed to export the
> RCP correctly using bucky commands from within Eclipse. The problem
> comes when I try to build from Hudson.
>
> Bucky imports the target definition correctly from the workspace. My
> target definition includes Eclipse Delta Pack to build the product for
> multiple platforms.
>
> importtargetdefinition -A
> '${WORKSPACE}/com.opencanarias.mset.rosetta.site.feature/OC- Rosetta-TP-Definition.target'
>
>
> Then the component query is imported:
>
> import
> '${WORKSPACE}/com.opencanarias.mset.rosetta.site.feature/sit e.cquery'
>
> And here comes the failure. Bucky doesn't seem to be able to resolve
> some platform specific fragments. But not all fragments, but only those
> Equinox Launcher. What is strange is that it actually resolves other
> platform specific fragments, like those from SWT. And what's more
> strange, the only Equinox Launcher fragment that's is imported is the
> one from win32 (well, our hudson is being executed in a windows 2003
> server...). Let me add some debug messages
>
> Here the message for win32 fragment:
>
> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Using resolver
> Local resolver
> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Trying
> provider local(materialized)
> No materialization found for
> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle
> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Trying
> provider local(workspace)
> No open workspace project found that corresponds to
> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle
> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Trying
> provider local(target)
> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Found match
> 1.0.200.v20090519
> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Found match
> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle$1.0 .200.v20090519
>
>
> As you see, it first looks at the target platform, finds a match and
> selects it. Now lets look at what happens at, for instance, a macosx
> equinox launcher fragment. What is weird about this case is that it
> actually finds a match in the target platform, but doesn't select it!
>
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using resolver
> Local resolver
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
> local(materialized)
> No materialization found for
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
> local(workspace)
> No open workspace project found that corresponds to
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
> local(target)
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Found match
> 1.0.0.v20090519
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using resource
> map
> file:/C:/Hudson/jobs/OC-Rosetta/workspace/com.opencanarias.m set.rosetta.site.feature/site.rmap
>
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using search path
> resources
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
> local({0}/{1}/)
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Found match
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using provider
> local({0}/{1}/)
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Resolution
> attempt ended with exception: Provider
> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
> Missing CSpec source required by component type osgi.bundle
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: No provider was
> found that could resolve the request
> ERROR [0000] : No suitable provider for component
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
> resourceMap
> file:/C:/Hudson/jobs/OC-Rosetta/workspace/com.opencanarias.m set.rosetta.site.feature/site.rmap
>
> ERROR [0000] : No suitable provider for component
> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
> searchPath resources
> ERROR [0000] : Resolution attempt ended with exception: Provider
> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
> Missing CSpec source required by component type osgi.bundle
> ERROR Provider
> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
> Missing CSpec source required by component type osgi.bundle
>
> Do you guys have a clue why a match is being found, but not being
> selected for the component query resolution?
>
> A bit more insight about our build configuration:
>
> - We have one single feature definition that includes ALL plugins from
> our product, but only those that are platform independent.
>
> - Then another feature includes all platform specific fragments (i.e.,
> filesystem provider, SWT...). This was needed because otherwise PDE
> Export would not include them, and the exported RCP would not work.
>
> - our target platform is all stored in our SVN, so we don't resolve them
> from p2 update sites.
>
> One of the things I was stuck was that, while trying the build from
> within eclipse and bucky, I had to set some flags (operative system,
> window system and architecture) at the feature definition for platform
> specific fragments, otherwise I would get an error. Also bucky is
> sensitive for things like the language flag, so I removed them all.
>
> I've tried many combinations:
> - adding "org.eclipse.equinox.executable" feature, and removing it
> - removing delta pack from target platform. That would drop more errors,
> since things like SWT fragments won't be resolved.
> - adding/removing equinox launcher from the feature that contains all
> platform specific fragments/bundles
> - modifying the "the product includes native launchers artifacts" flag
> in the product definition.
> - adding P2 site to the platform definition.
>
> Sorry for the long post. Would like to hear your comments.
>
> Cheers,
> Víctor.
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512255 is a reply to message #512244] Thu, 04 February 2010 14:02 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
Hi Víctor,

Did you set properties in your cquery to make it platform agnostic?
<cq:property key="target.arch" value="*"/>
<cq:property key="target.os" value="*"/>
<cq:property key="target.ws" value="*"/>

Or is the Target Platform Environment set to be platform agnostic?
If the fragment is contained and resolved in your target platform, the
RMAP shouldn't be consulted at all unless an advisor node prohibits
resolution against the target platform.


Best regards,
Johannes
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512256 is a reply to message #512254] Thu, 04 February 2010 14:11 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi Thomas,

that you very much, adding that to the component query fixed the problem:

<?xml version="1.0" encoding="UTF-8"?>
<cq:componentQuery xmlns:cq="http://www.eclipse.org/buckminster/CQuery-1.0"
resourceMap="site.rmap">
<cq:rootRequest name="com.opencanarias.mset.rosetta.site.feature"
componentType="eclipse.feature"/>
<cq:property key="target.arch" value="*"/>
<cq:property key="target.os" value="*"/>
<cq:property key="target.ws" value="*"/>

</cq:componentQuery>

Adding a log of component match rejection would help a lot. Thanks!

Now I'm getting this:

ERROR: An internal error occurred during: "Installing".

java.lang.OutOfMemoryError: Java heap space

at
org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAs CharArray(Util.java:415)

at
org.eclipse.jdt.internal.compiler.util.ManifestAnalyzer.anal yzeManifestContents(ManifestAnalyzer.java:42)

at
org.eclipse.jdt.internal.core.ClasspathEntry.getCalledFileNa mes(ClasspathEntry.java:916)

at
org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChained Libraries(ClasspathEntry.java:879)

at
org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChained Libraries(ClasspathEntry.java:866)

at
org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChained Libraries(ClasspathEntry.java:1394)

at
org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(J avaProject.java:2610)

at
org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(J avaProject.java:2679)

at
org.eclipse.jdt.internal.core.ClasspathChange.generateDelta( ClasspathChange.java:218)

at
org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged (DeltaProcessor.java:1916)

at
org.eclipse.jdt.internal.core.DeltaProcessingState.resourceC hanged(DeltaProcessingState.java:470)

at
org.eclipse.core.internal.events.NotificationManager$2.run(N otificationManager.java:291)

at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)

at
org.eclipse.core.internal.events.NotificationManager.notify( NotificationManager.java:285)

at
org.eclipse.core.internal.events.NotificationManager.broadca stChanges(NotificationManager.java:149)

at
org.eclipse.core.internal.resources.Workspace.broadcastPostC hange(Workspace.java:313)

at
org.eclipse.core.internal.resources.Workspace.endOperation(W orkspace.java:1022)

at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run (InternalWorkspaceJob.java:45)

at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

WARN: Problem during meta-data refresh: Java heap space

java.lang.OutOfMemoryError: Java heap space

at java.util.Arrays.copyOf(Unknown Source)

at java.lang.AbstractStringBuilder.expandCapacity(Unknown Source)

at java.lang.AbstractStringBuilder.append(Unknown Source)

at java.lang.StringBuffer.append(Unknown Source)

at
org.eclipse.core.internal.localstore.BucketTree.locationFor( BucketTree.java:128)

at
org.eclipse.core.internal.localstore.BucketTree.loadBucketFo r(BucketTree.java:113)

at
org.eclipse.core.internal.properties.PropertyManager2.getPro perty(PropertyManager2.java:132)

at
org.eclipse.core.internal.resources.Resource.getPersistentPr operty(Resource.java:1067)

at
org.eclipse.buckminster.core.metadata.MetadataSynchronizer$R esetVisitor.visit(MetadataSynchronizer.java:170)

at org.eclipse.core.internal.resources.Resource$2.visit(Resourc e.java:108)

at
org.eclipse.core.internal.resources.Resource$1.visitElement( Resource.java:60)

at
org.eclipse.core.internal.watson.ElementTreeIterator.doItera tion(ElementTreeIterator.java:82)

at
org.eclipse.core.internal.watson.ElementTreeIterator.doItera tion(ElementTreeIterator.java:86)

ERROR: An internal error occurred during: "Flushing content description
cache.".

java.lang.OutOfMemoryError: Java heap space

at
org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelt a(DataDeltaNode.java:50)

at
org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDe lta(NoDataDeltaNode.java:59)

at
org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDe lta(NoDataDeltaNode.java:59)

at
org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDe lta(NoDataDeltaNode.java:59)

at
org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDe lta(NoDataDeltaNode.java:59)

at
org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDe lta(NoDataDeltaNode.java:59)

at
org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDe lta(NoDataDeltaNode.java:59)

at
org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDe lta(NoDataDeltaNode.java:59)
INFO: Import complete.

at
org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDe lta(NoDataDeltaNode.java:59)

at
org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDe lta(NoDataDeltaNode.java:59)

at
org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelt a(DataDeltaNode.java:47)

at
org.eclipse.core.internal.dtree.DeltaDataTree.asBackwardDelt a(DeltaDataTree.java:88)

at
org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDa taTree.java:816)

at
org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDa taTree.java:792)

at
org.eclipse.core.internal.watson.ElementTree.immutable(Eleme ntTree.java:517)Doing
full workspace refresh



at
org.eclipse.core.internal.events.ResourceDeltaFactory.comput eDelta(ResourceDeltaFactory.java:42)

at
org.eclipse.core.internal.events.NotificationManager.getDelt a(NotificationManager.java:231)

at
org.eclipse.core.internal.events.NotificationManager.broadca stChanges(NotificationManager.java:140)

at
org.eclipse.core.internal.resources.Workspace.broadcastPostC hange(Workspace.java:313)

at
org.eclipse.core.internal.resources.Workspace.endOperation(W orkspace.java:1022)

at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run (InternalWorkspaceJob.java:45)

at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

ERROR: An internal error occurred during: "Flushing content description
cache.".

java.lang.OutOfMemoryError: Java heap space

ERROR: An internal error occurred during: "Metadata refresh".

java.lang.OutOfMemoryError: Java heap space

java.lang.OutOfMemoryError: Java heap space

ERROR: An internal error occurred during: "Metadata refresh".

java.lang.OutOfMemoryError: Java heap space

ERROR: Internal Error

java.lang.OutOfMemoryError: Java heap space

ERROR: Error while refreshingworkspace: Java heap space

Waiting for jobs to end

ERROR: An internal error occurred during: "Metadata refresh".

java.lang.OutOfMemoryError: Java heap space

ERROR: Error while saving workspace: Java heap space

java.lang.OutOfMemoryError: Java heap space

ERROR: Project refresh on com.opencanarias.mset.kdm.audit.view failed: null

java.lang.NullPointerException

at
org.eclipse.buckminster.pde.internal.PDETargetPlatform.doWit hActivePlatform(PDETargetPlatform.java:236)

at
org.eclipse.buckminster.pde.internal.PDETargetPlatform.getOS (PDETargetPlatform.java:131)

at
org.eclipse.buckminster.core.RMContext.getGlobalPropertyAddi tions(RMContext.java:231)

at org.eclipse.buckminster.core.RMContext.<init>(RMContext.java:282)

at org.eclipse.buckminster.core.RMContext.<init>(RMContext.java:277)

at
org.eclipse.buckminster.core.resolver.ResolutionContext.<init >(ResolutionContext.java:56)

at
org.eclipse.buckminster.core.resolver.ResolutionContext.<init >(ResolutionContext.java:49)

at
org.eclipse.buckminster.core.metadata.MetadataSynchronizer.r efreshProject(MetadataSynchronizer.java:364)

at
org.eclipse.buckminster.core.metadata.MetadataSynchronizer$M etadataRefreshJob.run(MetadataSynchronizer.java:140)

at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)





However, the job returns as "successful".

Should hudson be executed with more heap space to avoid this? My RCP
application is pretty big.

Thanks for your help again, I've been struggling with the fragment
rejection for days :P

Cheers!
Víctor.

Thomas Hallgren escribió:
> Hi Víctor,
> The macosx fragment that is found is immediately rejected because of a
> filter mismatch. I checked the code and Buckminster does that without
> logging it. That's unfortunate and I'll fix that.
>
> The reason you get a filter mismatch is probably that your import is run
> without wildcard settings for the properties target.os, target.ws, and
> target.arch. I.e.
>
> target.os=*
> target.ws=*
> target.arch=*
>
> Without these settings, the values default to the current platform.
>
> Regards,
> Thomas Hallgren
>
> On 02/04/2010 01:49 PM, Víctor Roldán Betancort wrote:
>> Hi guys,
>>
>> not sure if this is the right place to ask. I've been following Ralf
>> Ebert's (awesome! Thanks Elbert!) tutorial to make a headless build of
>> an eclipse RCP using Hudson and Buckminster. I've managed to export the
>> RCP correctly using bucky commands from within Eclipse. The problem
>> comes when I try to build from Hudson.
>>
>> Bucky imports the target definition correctly from the workspace. My
>> target definition includes Eclipse Delta Pack to build the product for
>> multiple platforms.
>>
>> importtargetdefinition -A
>> '${WORKSPACE}/com.opencanarias.mset.rosetta.site.feature/OC- Rosetta-TP-Definition.target'
>>
>>
>>
>> Then the component query is imported:
>>
>> import
>> '${WORKSPACE}/com.opencanarias.mset.rosetta.site.feature/sit e.cquery'
>>
>> And here comes the failure. Bucky doesn't seem to be able to resolve
>> some platform specific fragments. But not all fragments, but only those
>> Equinox Launcher. What is strange is that it actually resolves other
>> platform specific fragments, like those from SWT. And what's more
>> strange, the only Equinox Launcher fragment that's is imported is the
>> one from win32 (well, our hudson is being executed in a windows 2003
>> server...). Let me add some debug messages
>>
>> Here the message for win32 fragment:
>>
>> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Using resolver
>> Local resolver
>> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Trying
>> provider local(materialized)
>> No materialization found for
>> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle
>> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Trying
>> provider local(workspace)
>> No open workspace project found that corresponds to
>> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle
>> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Trying
>> provider local(target)
>> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Found match
>> 1.0.200.v20090519
>> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle: Found match
>> org.eclipse.equinox.launcher.win32.win32.x86:osgi.bundle$1.0 .200.v20090519
>>
>>
>>
>> As you see, it first looks at the target platform, finds a match and
>> selects it. Now lets look at what happens at, for instance, a macosx
>> equinox launcher fragment. What is weird about this case is that it
>> actually finds a match in the target platform, but doesn't select it!
>>
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using resolver
>> Local resolver
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
>> local(materialized)
>> No materialization found for
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
>> local(workspace)
>> No open workspace project found that corresponds to
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
>> local(target)
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Found match
>> 1.0.0.v20090519
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using resource
>> map
>> file:/C:/Hudson/jobs/OC-Rosetta/workspace/com.opencanarias.m set.rosetta.site.feature/site.rmap
>>
>>
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using search path
>> resources
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Trying provider
>> local({0}/{1}/)
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Found match
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Using provider
>> local({0}/{1}/)
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: Resolution
>> attempt ended with exception: Provider
>> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
>>
>> Missing CSpec source required by component type osgi.bundle
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle: No provider was
>> found that could resolve the request
>> ERROR [0000] : No suitable provider for component
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
>> resourceMap
>> file:/C:/Hudson/jobs/OC-Rosetta/workspace/com.opencanarias.m set.rosetta.site.feature/site.rmap
>>
>>
>> ERROR [0000] : No suitable provider for component
>> org.eclipse.equinox.launcher.cocoa.macosx:osgi.bundle was found in
>> searchPath resources
>> ERROR [0000] : Resolution attempt ended with exception: Provider
>> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
>>
>> Missing CSpec source required by component type osgi.bundle
>> ERROR Provider
>> local(C:/Hudson/jobs/OC-Rosetta/workspace/org.eclipse.equino x.launcher.cocoa.macosx/):
>>
>> Missing CSpec source required by component type osgi.bundle
>>
>> Do you guys have a clue why a match is being found, but not being
>> selected for the component query resolution?
>>
>> A bit more insight about our build configuration:
>>
>> - We have one single feature definition that includes ALL plugins from
>> our product, but only those that are platform independent.
>>
>> - Then another feature includes all platform specific fragments (i.e.,
>> filesystem provider, SWT...). This was needed because otherwise PDE
>> Export would not include them, and the exported RCP would not work.
>>
>> - our target platform is all stored in our SVN, so we don't resolve them
>> from p2 update sites.
>>
>> One of the things I was stuck was that, while trying the build from
>> within eclipse and bucky, I had to set some flags (operative system,
>> window system and architecture) at the feature definition for platform
>> specific fragments, otherwise I would get an error. Also bucky is
>> sensitive for things like the language flag, so I removed them all.
>>
>> I've tried many combinations:
>> - adding "org.eclipse.equinox.executable" feature, and removing it
>> - removing delta pack from target platform. That would drop more errors,
>> since things like SWT fragments won't be resolved.
>> - adding/removing equinox launcher from the feature that contains all
>> platform specific fragments/bundles
>> - modifying the "the product includes native launchers artifacts" flag
>> in the product definition.
>> - adding P2 site to the platform definition.
>>
>> Sorry for the long post. Would like to hear your comments.
>>
>> Cheers,
>> Víctor.
>
>
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512257 is a reply to message #512255] Thu, 04 February 2010 14:16 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi Johannes,

indeed, that was the problem. My component query was not specified as
platform agnostic, an that made all platforms but win32.x86 being rejected.

Thanks for the hint, and for your great support! :D

Cheers,
Víctor.

Johannes Utzig escribió:
> Hi Víctor,
>
> Did you set properties in your cquery to make it platform agnostic?
> <cq:property key="target.arch" value="*"/>
> <cq:property key="target.os" value="*"/>
> <cq:property key="target.ws" value="*"/>
>
> Or is the Target Platform Environment set to be platform agnostic?
> If the fragment is contained and resolved in your target platform, the
> RMAP shouldn't be consulted at all unless an advisor node prohibits
> resolution against the target platform.
>
>
> Best regards,
> Johannes
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512269 is a reply to message #512256] Thu, 04 February 2010 14:23 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
On 02/04/2010 03:11 PM, Víctor Roldán Betancort wrote:
> Adding a log of component match rejection would help a lot. Thanks!
>

Will be available in the next 3.6 build: https://bugs.eclipse.org/bugs/show_bug.cgi?id=301832

>
> However, the job returns as "successful".
>
It really should not. Where do you see this "successful"? In Hudson?

> Should hudson be executed with more heap space to avoid this? My RCP
> application is pretty big.
>
That's the first thing I would try.

> Thanks for your help again, I've been struggling with the fragment
> rejection for days :P
>
We're glad to help :-)

Regards,
Thomas Hallgren
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512272 is a reply to message #512269] Thu, 04 February 2010 09:34 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Thomas,

>> However, the job returns as "successful".
>>
> It really should not. Where do you see this "successful"? In Hudson?

Yep, in Hudson. A bit odd...

>> Should hudson be executed with more heap space to avoid this? My RCP
>> application is pretty big.
>>
> That's the first thing I would try.
>

Alright, will try that :)
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512285 is a reply to message #512256] Thu, 04 February 2010 14:54 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
Hi Víctor,

>
> However, the job returns as "successful".
>
> Should hudson be executed with more heap space to avoid this? My RCP
> application is pretty big.
>

I assume you use the hudson plugin? The 'successful' state is evaluated
based on the return value of the forked eclipse process. I guess in this
case that process terminates with a '0' for some reason...
Like said above, the process is forked, not in the same VM as hudson
itself. You therefore only need to add an increased -Xmx Parameter
either in the job as VM argument, or in the hudson configuration in the
settings of the buckminster installation you're using for the job.
If you do not add an -Xmx parameter anywhere the plugin defaults to 256m
as far as I remember...

Hope that helps and best regards,
Johannes
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512300 is a reply to message #512285] Thu, 04 February 2010 15:27 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi Johannes,

some comments below:

> I assume you use the hudson plugin? The 'successful' state is evaluated
> based on the return value of the forked eclipse process. I guess in this
> case that process terminates with a '0' for some reason...
> Like said above, the process is forked, not in the same VM as hudson
> itself. You therefore only need to add an increased -Xmx Parameter
> either in the job as VM argument, or in the hudson configuration in the
> settings of the buckminster installation you're using for the job.
> If you do not add an -Xmx parameter anywhere the plugin defaults to 256m
> as far as I remember...

Yes, I'm using the Hudson plugin.

I already managed to fix the OutOfMemoryError by increasing Hudson Heap
Space and Buckminster Head space. Not sure if both are necessary,
probably not.

Thanks for the help provided!

Víctor.
Re: Bucky + Hudson does not retrieve platform-specific launchers [message #512302 is a reply to message #512300] Thu, 04 February 2010 15:42 Go to previous message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
Great that you could solve your issues.
Like stated, increasing the hudson memory is not necessary unless it's
really hudson that's running out of memory. From my experience that
usually only happens when it's parsing large Junit Reports and that alike.
The buckminster invokation is (currently) done with a ProcessBuilder so
it's a completly seperated process.
That said, a little bit more memory for Hudson won't hurt anybody of
course :)

Best regards,
Johannes
Previous Topic:Aggregator generated Maven compatible Repository
Next Topic:Running unit tests with buckminster 3.6 against 3.5 platform
Goto Forum:
  


Current Time: Fri Apr 19 20:51:52 GMT 2024

Powered by FUDForum. Page generated in 0.06217 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top