| Shouldn't autobuild iterate until all builder-produced resource deltas are consumed? [message #336896] |
Fri, 10 July 2009 14:34  |
Eclipse User |
|
|
|
Originally posted by: aprice.spamnot.tibco.com
Good day eclipse.platform,
Simplified application synopsis - the following builders run, (necessarily,
I believe*) in this order:
1. formBuilder responds to *.form deltas, derives *.properties files
2. processBuilder responds to *.xpdl deltas, derives *.form files
3. giBuilder responds to *.properties deltas, deriving *.xml files
Later builders produce resources that need further processing by earlier
builders, so logically I would expect auto-builds to iterate until:
- all *.xpdl files have corresponding *.form files
- all *.form files have corresponding *.properties files
- all *.properties files have corresponding *.xml files
Instead, the autobuild iterations seem to finish prematurely with
outstandanding *.form and *.properties deltas unbuilt. Some time later (1-5
mins), these resource notifications magically get delivered and the build
kicks off again and runs to completion (i.e., all expected output files
present). Manually refreshing (F5) the project also has the same
build-triggering effect (but immediately).
I've tried to schedule a programmatic recursive project refresh by having
formBuilder schedule a workspace job (rule = project) *after* the build but
this does not work - the refresh job runs in the middle of the build job
sequence rather than afterwards. Enabling build/* and job/* trace options
seems to suggest that the build job is somehow getting canceled then
rescheduled - I don't know why but I'm sure it's not any of our builders
doing this.
Any insights or suggestions would be gratefully received.
Thanks & best regards,
Adrian Price
Senior Architect
TIBCO Software Inc.
* The builder order is, unfortunately, mandated by the allowed dependencies
between the features contributing the respective natures associated with
these builders. If I could change the dependencies, I would.
|
|
|
| Re: Shouldn't autobuild iterate until all builder-produced resource deltas are consumed? [message #336902 is a reply to message #336896] |
Fri, 10 July 2009 18:33  |
| Eclipse User |
|
|
|
Originally posted by: eclipseng.arthorne.com
Changes made by a builder do not cause autobuild to run. This would
often cause infinite cycles in builders because the build manager
doesn't know what kind of file changes you are interested in. You need
to indicate from within your builder that another build iteration is
required by calling:
IncrementalProjectBuilder.needRebuild();
Hope that helps,
John
--
Adrian Price wrote:
> Good day eclipse.platform,
>
> Simplified application synopsis - the following builders run, (necessarily,
> I believe*) in this order:
>
> 1. formBuilder responds to *.form deltas, derives *.properties files
> 2. processBuilder responds to *.xpdl deltas, derives *.form files
> 3. giBuilder responds to *.properties deltas, deriving *.xml files
>
> Later builders produce resources that need further processing by earlier
> builders, so logically I would expect auto-builds to iterate until:
> - all *.xpdl files have corresponding *.form files
> - all *.form files have corresponding *.properties files
> - all *.properties files have corresponding *.xml files
>
> Instead, the autobuild iterations seem to finish prematurely with
> outstandanding *.form and *.properties deltas unbuilt. Some time later (1-5
> mins), these resource notifications magically get delivered and the build
> kicks off again and runs to completion (i.e., all expected output files
> present). Manually refreshing (F5) the project also has the same
> build-triggering effect (but immediately).
>
> I've tried to schedule a programmatic recursive project refresh by having
> formBuilder schedule a workspace job (rule = project) *after* the build but
> this does not work - the refresh job runs in the middle of the build job
> sequence rather than afterwards. Enabling build/* and job/* trace options
> seems to suggest that the build job is somehow getting canceled then
> rescheduled - I don't know why but I'm sure it's not any of our builders
> doing this.
>
> Any insights or suggestions would be gratefully received.
>
> Thanks & best regards,
>
> Adrian Price
> Senior Architect
> TIBCO Software Inc.
>
> * The builder order is, unfortunately, mandated by the allowed dependencies
> between the features contributing the respective natures associated with
> these builders. If I could change the dependencies, I would.
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03359 seconds
] 
Search
Help
Register
Login
Home
