|
| Re: continous full build, resource tree is lost [message #335432 is a reply to message #335430] |
Wed, 08 April 2009 10:16   |
 Ed Merks
Messages: 33258
Registered: July 2009 |
Senior Member |
|
|
Harald,
Who calls setBuildSpec in step two? Who causes there to be a need for a
refresh of the External Tool Builder? If the problem is specific to
CDT, you might want to ask about it on the CDT newsgroup. If you open a
bugzilla, it will need to have enough detail so that someone can
definitely reproduce it locally.
Harald Kästel-Baumgartner wrote:
> Hi,
>
> Before I file a bug against plattform I want to discuss my problem here.
>
> I'm working with CDT under Eclipse Version: 3.4.0. When I run a
> project build sometimes it happens that the buildState (resource tree)
> isn't cached correctly after the build finished. To explore the
> problem I added console message to the org.eclipse.core.resources
> package.
>
> The build consist of three builders in following order:
> 1. External Tool Builder
> 2. CDT Builder
> 3. Own contributed builder
>
> The External Tool Builder deletes some files in the projects and calls
> a project refresh at the end.
>
> And here is what I found:
>
> 1. When the build starts the BuildManager requests the build commands
> with the method IProjectDescription#getBuildSpec()
>
> 2. Before the CDT Builder starts
> IProjectDescription#setBuildSpec(ICommand[])
> is called. Maybe triggered by the refresh of the External Tool
> Builder. In this method the builders of the old commands are copied to
> new commands. Since the CDT Builder isn't started at this point, the
> builder for the CDT Builder Command is null.
>
> 3. CDT Builder is started. The Builder in the CDT Builder Command is
> set to the instantiated builder (s. BuildManager#getBuilder()).
> Unfortunately, at this time the CDT Builder Command isn't the command
> in the buildSpec of the ProjectDescription. Thus the resource tree,
> safed in the builder isn't referenced from the buildSpec.
> 4. After this a project build is always running a full build because
> the resource tree is lost.
>
> Possible Fixes:
>
> A. Prevent a call of IProjectDescription#setBuildSpec(ICommand[]) when
> a build is running.
>
> B. Keep track of the new build command in the the old command to
> forward the builder, that is set in the old command by
> BuildCommand#setBuilder().
>
>
> A could be difficult. I prefer B. B could be done in
> IProjectDescription#setBuildSpec(ICommand[]) and
> BuildCommand#setBuilder().
>
>
> Your comments?
>
> Harald
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: continous full build, resource tree is lost [message #335439 is a reply to message #335432] |
Wed, 08 April 2009 13:09 |
Harald 
Messages: 37
Registered: July 2009 |
Member |
|
|
Ed Merks wrote:
> Who calls setBuildSpec in step two?
That's what i didn't know yet.
> Who causes there to be a need for a refresh of the External Tool Builder?
It's a feature of org.eclipse.ui.externaltools.ExternalToolBuilder. For
example in CDT a external tool builder can be used to call a batch to
modify/add include files before the internal CDT builder starts.
> If the problem is specific to
> CDT, you might want to ask about it on the CDT newsgroup.
I'll post the bug there. Maybe setBuildSpec is called from CDT. But, does
it matter? You never can be sure that setBuildSpec isn't called during
build process. In CDT these can be long running (several minutes).
> If you open a
> bugzilla, it will need to have enough detail so that someone can
> definitely reproduce it locally.
Just imagine a simple contributed builder that calls
IProjectDescription#setBuildSpec(.)
before the build is finished. Could be a way the reproduce this.
I made a patch for
org.eclipse.core.resources
With this in a first shoot, the build works fine. After a few days and a
lot of people working fine with this, I'll post it in the bug.
FYI in IProjectDescription#setBuildSpec(.) I've added the line
((BuildCommand) buildSpec[j]).setCommand((BuildCommand) result[i]);
in BuildCommand#setBuilder(.) the lines
// Forward the buidler to a new command if the reference is set
if (commandReference != null)
commandReference.setBuilder(builder);
and a new method BuildCommand#setCommand(.)
public void setCommand(BuildCommand buildCommand) {
this.commandReference = buildCommand;
}
Have a nice day.
Harald
> Harald Kästel-Baumgartner wrote:
>> Hi,
>>
>> Before I file a bug against plattform I want to discuss my problem here.
>>
>> I'm working with CDT under Eclipse Version: 3.4.0. When I run a
>> project build sometimes it happens that the buildState (resource tree)
>> isn't cached correctly after the build finished. To explore the
>> problem I added console message to the org.eclipse.core.resources
>> package.
>>
>> The build consist of three builders in following order:
>> 1. External Tool Builder
>> 2. CDT Builder
>> 3. Own contributed builder
>>
>> The External Tool Builder deletes some files in the projects and calls
>> a project refresh at the end.
>>
>> And here is what I found:
>>
>> 1. When the build starts the BuildManager requests the build commands
>> with the method IProjectDescription#getBuildSpec()
>>
>> 2. Before the CDT Builder starts
>> IProjectDescription#setBuildSpec(ICommand[])
>> is called. Maybe triggered by the refresh of the External Tool
>> Builder. In this method the builders of the old commands are copied to
>> new commands. Since the CDT Builder isn't started at this point, the
>> builder for the CDT Builder Command is null.
>>
>> 3. CDT Builder is started. The Builder in the CDT Builder Command is
>> set to the instantiated builder (s. BuildManager#getBuilder()).
>> Unfortunately, at this time the CDT Builder Command isn't the command
>> in the buildSpec of the ProjectDescription. Thus the resource tree,
>> safed in the builder isn't referenced from the buildSpec.
>> 4. After this a project build is always running a full build because
>> the resource tree is lost.
>>
>> Possible Fixes:
>>
>> A. Prevent a call of IProjectDescription#setBuildSpec(ICommand[]) when
>> a build is running.
>>
>> B. Keep track of the new build command in the the old command to
>> forward the builder, that is set in the old command by
>> BuildCommand#setBuilder().
>>
>>
>> A could be difficult. I prefer B. B could be done in
>> IProjectDescription#setBuildSpec(ICommand[]) and
>> BuildCommand#setBuilder().
>>
>>
>> Your comments?
>>
>> Harald
>>
>>
|
|
|
| Re: continous full build, resource tree is lost [message #335445 is a reply to message #335439] |
Wed, 08 April 2009 16:25 |
Ed Merks
Messages: 33258
Registered: July 2009 |
Senior Member |
|
|
Harald,
Comments below.
Harald Kästel-Baumgartner wrote:
> Ed Merks wrote:
>> Who calls setBuildSpec in step two?
>
> That's what i didn't know yet.
It might be your fault. :-P
>
>> Who causes there to be a need for a refresh of the External Tool
>> Builder?
>
> It's a feature of org.eclipse.ui.externaltools.ExternalToolBuilder.
> For example in CDT a external tool builder can be used to call a batch
> to modify/add include files before the internal CDT builder starts.
>> If the problem is specific to CDT, you might want to ask about it on
>> the CDT newsgroup.
>
> I'll post the bug there. Maybe setBuildSpec is called from CDT. But,
> does it matter? You never can be sure that setBuildSpec isn't called
> during build process. In CDT these can be long running (several minutes).
I suspect there are definitely things you ought not to do during a
build, like change how the builds are supposed to be done...
>
>> If you open a bugzilla, it will need to have enough detail so that
>> someone can definitely reproduce it locally.
>
> Just imagine a simple contributed builder that calls
> IProjectDescription#setBuildSpec(.)
> before the build is finished. Could be a way the reproduce this.
That sounds like the perfect type of thing. That way it's easy to
reproduce and although someone might say you shouldn't do that, you
could then redirect the problem to whomever is doing that...
>
> I made a patch for org.eclipse.core.resources
> With this in a first shoot, the build works fine. After a few days and
> a lot of people working fine with this, I'll post it in the bug.
> FYI in IProjectDescription#setBuildSpec(.) I've added the line
> ((BuildCommand) buildSpec[j]).setCommand((BuildCommand) result[i]);
> in BuildCommand#setBuilder(.) the lines // Forward the buidler to a
> new command if the reference is set
> if (commandReference != null)
> commandReference.setBuilder(builder);
> and a new method BuildCommand#setCommand(.)
> public void setCommand(BuildCommand buildCommand) {
> this.commandReference = buildCommand;
> }
Patches/fixes are cool. Committers love those. :-)
>
>
> Have a nice day.
You too. :-)
> Harald
>
>
>> Harald Kästel-Baumgartner wrote:
>>> Hi,
>>>
>>> Before I file a bug against plattform I want to discuss my problem
>>> here.
>>>
>>> I'm working with CDT under Eclipse Version: 3.4.0. When I run a
>>> project build sometimes it happens that the buildState (resource
>>> tree) isn't cached correctly after the build finished. To explore
>>> the problem I added console message to the
>>> org.eclipse.core.resources package.
>>>
>>> The build consist of three builders in following order:
>>> 1. External Tool Builder
>>> 2. CDT Builder
>>> 3. Own contributed builder
>>>
>>> The External Tool Builder deletes some files in the projects and
>>> calls a project refresh at the end.
>>>
>>> And here is what I found:
>>>
>>> 1. When the build starts the BuildManager requests the build
>>> commands with the method IProjectDescription#getBuildSpec()
>>>
>>> 2. Before the CDT Builder starts
>>> IProjectDescription#setBuildSpec(ICommand[])
>>> is called. Maybe triggered by the refresh of the External Tool
>>> Builder. In this method the builders of the old commands are copied
>>> to new commands. Since the CDT Builder isn't started at this point,
>>> the builder for the CDT Builder Command is null.
>>>
>>> 3. CDT Builder is started. The Builder in the CDT Builder Command is
>>> set to the instantiated builder (s. BuildManager#getBuilder()).
>>> Unfortunately, at this time the CDT Builder Command isn't the
>>> command in the buildSpec of the ProjectDescription. Thus the
>>> resource tree, safed in the builder isn't referenced from the
>>> buildSpec.
>>> 4. After this a project build is always running a full build because
>>> the resource tree is lost.
>>>
>>> Possible Fixes:
>>>
>>> A. Prevent a call of IProjectDescription#setBuildSpec(ICommand[])
>>> when a build is running.
>>>
>>> B. Keep track of the new build command in the the old command to
>>> forward the builder, that is set in the old command by
>>> BuildCommand#setBuilder().
>>>
>>>
>>> A could be difficult. I prefer B. B could be done in
>>> IProjectDescription#setBuildSpec(ICommand[]) and
>>> BuildCommand#setBuilder().
>>>
>>>
>>> Your comments?
>>>
>>> Harald
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.04243 seconds
] 
Search
Help
Register
Login
Home
