eclipse-jdt / eclipse.jdt.ui

Eclipse Public License 2.0
37 stars 92 forks source link

Eclipse gives up incremental build and goes systematically for full clean and rebuild #1347

Open nbauma109 opened 7 months ago

nbauma109 commented 7 months ago

Version : Eclipse 2024-03

This issue seems to happen only on a large projects.

The following settings are activated :

I experienced the following problems :

Important note: I do not use any integrated build tools such buildship (Gradle) or m2e (Maven).

iloveeclipse commented 6 months ago

Without steps to reproduce we can't help here. Obviously, you are not alone Eclipse user but we didn't had similar reports yet, so something is special in your case. Please try to understand what that "special" part is - extra Eclipse bundle installed, specific project structure, extra builders on the project, whatever...

nbauma109 commented 6 months ago

I have downloaded this version of Eclipse:

Eclipse IDE for Java Developers (includes Incubating components)

Version: 2024-03 (4.31.0) Build id: 20240307-1437

Classpath file:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry including="**/*" kind="src" path="src/main/java"/>
    <classpathentry including="**/*" kind="src" path="src/main/resources/etc"/>
    <classpathentry excluding="etc/**" including="**/*" kind="src" path="src/main/resources"/>
    <classpathentry kind="src" output="build/classes/test" path="src/test/java">
        <attributes>
            <attribute name="test" value="true"/>
        </attributes>
    </classpathentry>
    <classpathentry kind="src" output="build/classes/test" path="src/test/resources">
        <attributes>
            <attribute name="test" value="true"/>
        </attributes>
    </classpathentry>
    <classpathentry exported="true" kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
    <classpathentry exported="true" kind="lib" path="/path/to/some-library.jar" sourcepath="/path/to/some-library-sources.jar">
        <attributes>
            <attribute name="org.eclipse.jst.component.dependency" value="../"/>
        </attributes>
    </classpathentry>
        <!-- skipped other lib entries similar to this one -->
    <classpathentry kind="output" path="build/classes/main"/>
</classpath>

Project file (builders) :

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
    <name>some-project</name>
    <comment/>
    <projects/>
    <natures>
        <nature>org.eclipse.jdt.core.javanature</nature>
        <nature>org.eclipse.wst.common.project.facet.core.nature</nature>
        <nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
        <nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
    </natures>
    <buildSpec>
        <buildCommand>
            <name>org.eclipse.jdt.core.javabuilder</name>
            <arguments/>
        </buildCommand>
        <buildCommand>
            <name>org.eclipse.wst.common.project.facet.core.builder</name>
            <arguments/>
        </buildCommand>
        <buildCommand>
            <name>org.eclipse.wst.validation.validationbuilder</name>
            <arguments/>
        </buildCommand>
    </buildSpec>
    <linkedResources/>
</projectDescription>
iloveeclipse commented 6 months ago

Could you please disable two org.eclipse.wst builders? If the problem disappears, please report to webtools project.

nbauma109 commented 6 months ago

Same issue without, unfortunately.

nbauma109 commented 6 months ago

Also, it appears that I have no component installed to deal with these configurations :

image

nbauma109 commented 6 months ago

It has to do with the structure of the projects :

root
+---extensions
    +---projects
        +---some-project

All projects from the tree are General Projects except some-project which is a Java Project.

When I remove project root from workspace, the problem disappears. When I add it back to the workspace, the problem reappears.

I could have only root as General Project and some-project as Java Project inside the workspace. But even with these 2, I still have the issue.

Also, I tried to add a resource filter to exclude "some-project" from root, but it didn't help. Even closing root project didn't help, only removing it helped.

howlger commented 6 months ago

It seems that your structure of projects causes build cycles that need to be fixed on your side.

When Project > Build Automatically is enabled, a project builder is triggered by file changes. A build cycle occurs when a project builder B is triggered by file changes made by a project builder A, and this in turn makes file changes that trigger again the project builder A directly or via other project builders.

Especially if you have projects that depend on each other and/or are nested within each other, you must ensure that there are no build cycles. It is also possible to have a build cycle in a single project if there are more than one project builders, which does not apply in your case. Eclipse does not support nested Java projects.

In the preferences General > Workspace > Build you can specify the project build order and the maximum number of iterations when building with cycles. Changes in folders and files that have the attribute Derived (right-click Properties: Resource) do not trigger project builders. In general, avoid build cycles and better also cyclical dependencies. It is the expected behavior and not a bug that a project builder is triggered by file changes, no matter if the changes are made in a project from inside or from outside the Eclipse IDE.

howlger commented 6 months ago

This issue was first asked on Stack Overflow.

nbauma109 commented 6 months ago

I'm not sure to follow you. You seem to imply that I have nested builders / nested Java projects. That is not the case.

All projects from the tree are General Projects except some-project which is a Java Project.

Below the project file of root project:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
    <name>root</name>
    <comment></comment>
    <projects>
    </projects>
    <buildSpec>
    </buildSpec>
    <natures>
    </natures>
</projectDescription>
iloveeclipse commented 6 months ago

If I understand your setup, the cycle is due the fact that root project includes every file from other projects. So after a build cycle every file touched by any other project is reported as changed in the root project, and I believe this could cause the build to start yet another round.

nbauma109 commented 6 months ago

I think that's excluded because:

iloveeclipse commented 6 months ago

If you could reduce your example to something that can be zipped and attached here, we could try to reproduce.

What you can do is to download latest I-Build from https://download.eclipse.org/eclipse/downloads/, create new workspace, add your projects there and check if anything changes. If not, try to remove content from projects till the problem disappears.

howlger commented 6 months ago

@nbauma109 A plugin can also listen for file changes and then change files itself. It is therefore important that you test it with the Eclipse SDK without additionally installed plug-ins, and not with an Eclipse IDE package. (It happened to me once that a faulty plugin caused the effect you observed in a project with which this plugin was completely unrelated.)

nbauma109 commented 6 months ago

I found the issue.

In root project, there's a classpath entry (sorry, I missed precisely that one in the classpath file) :

<classpathentry exported="true" kind="lib" path="C:/root/client/resources">
  <attributes>
    <attribute name="org.eclipse.jst.component.nondependency" value=""/>
  </attributes>
</classpathentry>

If I change it to remove the C:, the issue disappears.:

<classpathentry exported="true" kind="lib" path="/root/client/resources">
  <attributes>
    <attribute name="org.eclipse.jst.component.nondependency" value=""/>
  </attributes>
</classpathentry>

The downside is that root has to be in the workspace for that configuration to work, or the following error will show (expectedly):

Project 'some-project' is missing required library: '\root\client\resources'

iloveeclipse commented 6 months ago

So some-project requires root project? Here is the cycle: some-project builds, it updates the root project (because it includes everything), build is re-triggered to update some-project because of of it dependencies changed.

nbauma109 commented 6 months ago

That path C:/root/client/resources remains unchanged during the build. It can be used as long as C:/root is not introduced as a project into the workspace. Once it is introduced into the workspace, the classpath entry has to be changed from C:/root/client/resources to /root/client/resources.

nbauma109 commented 6 months ago

I couldn't reproduce with a sample project. I might have missed some other variable.