Bug 365160

Description Vladimir Piskarev 2011-11-30 02:09:45 EST

Build Identifier: 

There seems to be a couple of issues with ProjectClasspathChangeListener:

- as an eager singleton in SharedModuleWithJdt it is prone to a blindspot 
(i.e. if the user modifies project's classpath before Xtext activation, this change is going to be unnoticed by ProjectClasspathChangeListener)

- the result may depend on when exactly XtextBuilder scheduled to perform FULL_BUILD of the project with changed classpath will run: before workspace (auto-)build (in particular, before JavaBuilder) or after it. In general, it's unpredictable due to inherently concurrent nature.

For example, a Java/Xtext project can be configured to share 'src-gen' source folder between Java APT and Xtext generators. Unfortunately, when doing full build (in particular, in case of classpath change) APT will clean all derived resources under this folder. If JavaBuilder runs before XtextBuilder there are no issues at all: XtextBuilder will re-generate the necessary artifacts. But if XtextBuilder (which ProjectClasspathChangeListener scheduled to perform FULL_BUILD) happens to run before workspace auto-build all the resources it (re-)generates in 'src-gen' folder will be swept away by APT. Another example can be that APT generates some files which XtextBuilder should process, etc. 
In general, the order of builder invocations should match the order of build commands configured on a project (in this case, JavaBuilder should always run before XtextBuilder).

So it seems to me that XtextBuilder could behave like JavaBuilder with regard to classpath changes and get away with ProjectClasspathChangeListener:

/* excerpt from JavaBuilder */
protected IProject[] build(int kind, Map args, IProgressMonitor monitor) throws CoreException {
    //...
    if (kind == FULL_BUILD)
        buildAll();
    else if ((this.lastState = getLastState(this.currentProject)) == null)
        buildAll();
    else if (hasClasspathChanged())
        buildAll();
    else //...

which probably can be generalized with an injectable strategy in XtextBuilder:

protected IProject[] build(int kind, Map args, IProgressMonitor monitor) throws CoreException {
    //...
    if (kind == FULL_BUILD)
        fullBuild(...);
    else if (buildStrategy.isFullBuild(this, kind, args))
        fullBuild(...);
    else //...

Reproducible: Always