[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Newsgroup Home]
|
[news.eclipse.technology.buckminster] Re: Issues with headless metadata refresh
|
Hi Thomas,
See my answers bellow.
Thanks,
Vaidas
Thomas Hallgren wrote:
> Hi Vaidas,
> thoughs and ideas inline.
>
> Vaidas Nargėlas wrote:
>> Hi Thomas,
>>
>> I was doing this to switch workspace to a different target environment
>> (os/ws/arch):
>>
>> 1) I would delete buckminster metadata:
>>
>> ------------------------------
>> <delete>
>> <fileset dir="${workspace.dir}/.metadata/.plugins">
>> <include name="org.eclipse.buckminster.core/**/*"/>
>> <exclude name="org.eclipse.buckminster.core/**/.*"/>
>> <include name="org.eclipse.pde.core"/>
>> </fileset>
>> </delete>
>> ------------------------------
>>
> Not sure why you would need to do this. Switching target platform should
> not require surgical operations on the Buckminster meta-data. I guess
> you've had some problems in the past that you worked around this way?
Artifacts internal.product.root.0 and internal.product.root.1 of
org.eclipse.equinox.executable would not refresh for updated os/ws/arch
unless I delete Buckminster meta-data.
If I try changing os/ws/arch from Eclipse IDE I can not force these
artifacts to correct values even if I refresh meta-data in preference page.
Only closing_IDE+deleting_meta-data_files+starting_IDE helps.
>
>
>> 2) Next I would invoke this buckminster script:
>>
>> ------------------------------
>> setpref targetWS=${target.ws} targetOS=${target.os}
>> targetArch=${target.arch} targetPlatformPath=${target.platform.dir} build
>> perform xxx.yyy.zzz#create.product
>> ------------------------------
>>
>> I worked okay before buckminster 0.3.0. When I switched to
>> buckminster-0.3.0-r07733 this approach does not work in a stable way.
>> Sometimes it passes but sometimes it fails with the message on the
>> console:
>>
>> ------------------------------
>> INFO: perform 'xxx.yyy.zzz#create.product'
>> No component named xxx.yyy.zzz is known to Buckminster
>> ------------------------------
>>
>> After failure I can invoke buckminster command
>> perform xxx.yyy.zzz#create.product
>>
>> and it passes then successfully. However sometimes it fails with the same
>> error message. But if I repeat the same command it succeeds eventually.
>>
> That should not happen randomly. Please answer the following:
>
> - What kind of component is it that is failing (feature or plug-in)?
> - Is it a workspace project or a component in your target platform?
> - Can you see any special characteristics for this component such as
> platform filters etc.?
Yes, these were workspace projects. I have tried actions on both feature and
plugin projects. I think I have no platform filters nor any other special
settings. It seems that random nature comes from some missing synchronization.
Maybe sometimes some work is able to come to successfull end and sometimes
doesn't when the other thread tries to access common data. That's just my guess
I can be completely wrong.
>
>
>> Then I added changed the script and added resolve command:
>>
>> ------------------------------
>> setpref targetWS=${target.ws} targetOS=${target.os}
>> targetArch=${target.arch} targetPlatformPath=${target.platform.dir}
>> resolve -N xxx.yyy.zzz.cquery build
>> perform xxx.yyy.zzz#create.product
>> ------------------------------
>>
>> Now I get again the situation that it passes sometimes but sometimes it
>> fails. It looks that I get different exceptions. Here are excerpts from
>> log file:
>>
>> ------------------------------
>> !ENTRY org.eclipse.buckminster.runtime 1 293 2008-01-17 17:09:03.981
>> !MESSAGE resolve '-N' '/path/to/xxx.yyy.zzz.cquery'
>>
>> !ENTRY org.eclipse.core.resources 2 567 2008-01-17 17:09:06.323
>> !MESSAGE Failure occurred reading .project file.
>> !SUBENTRY 1 org.eclipse.core.resources 2 567 2008-01-17 17:09:06.323
>> !MESSAGE FWK005 parse may not be called while parsing.
>> !STACK 0
>> org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
>> at
>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1245)
>> at
>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
>> at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at
>> org.eclipse.core.internal.resources.ProjectDescriptionReader.read(ProjectDescriptionReader.java:552)
>> at
>> org.eclipse.core.internal.resources.Workspace.loadProjectDescription(Workspace.java:1458)
>> at
>> org.eclipse.buckminster.core.reader.ProjectDescReader.consumeStream(ProjectDescReader.java:59)
>>
>> ...
>> It looks that here could be something with missing interthread
>> synchronization. On the other hand maybe my way of switching to a
>> different target environment isn't the correct one.
>>
> Indeed. I think the ProjectDescriptionReader is reusing the same parser
> instance. I'll add a synchronization. Thanks for reporting this.
>
> Regards,
> Thomas Hallgren