Community
Participate
Working Groups
Repro ===== 1. Turn of auto-build. 2. Setup a project to use an ant script for build. Disable other builders. 3. Project->Clean 4. Select the project and make sure that "Start a build immediately" is checked. 5. Hit ok. 6. Get the error. This error can also be seen when auto-build is on and eclipse attempts to build a project and a dependent project, when both use ant for build. Error ===== Dialog Title = Building Workspace Dialog Message = Build problems Details = Errors during build. Errors running builder "Integrated External Tool Builder" on project <pj>. Ant build <script-file-name> already in progress. Concurrent Ant builds are possible if you specify to build in a separate JRE. Expectation =========== Since I was not intentionally trying to run ant concurrently, I would expect that something (maybe ant builder) would compensate for eclipse's desire to run build concurrently and block/serialize invocations to build scripts. The current workaround of running build in a separate VM is not a good solution since it drastically effects performance and memory foot print.
On the common tab for your builders you will need to toggle off "Launch in background". This ensures serialization of the builds. re: separate VM effects performance and memory foot print. I would be interested in more on this. The memory footprint should be short lived (the separate VM comes and goes --> build memory should be gc'd) and I see almost no performance difference between same and separate JRE builds. Decreasing severity as this does not cause a crash, loss of data or a memory leak.
Disabling "Launch in background" does get around this problem, but since it blocks user from being able to do anything in eclipse until build finishes, I don't think it's a real good answer. The underlying problem should be addressed. re: separate VM effects performance and memory foot print. While memory footprint is short lived, it does cause a significant spike in memory utilization, especially if eclipse triggers a couple of these vms to spawn at the same time. As far as performance is concerned, you end up paying the fixed overhead of a vm launch, which last time I checked is on order of a couple of seconds. On top of that, you pay the classloading cost for the common classes that are already in eclipse. The other problem with the separate vm solution is that of configuration. In order to specify that ant script should launch in a separate vm, I have to choose a named jre configuration. This will differ from one user to the next and will make it difficult to share the launch config. One solution for this problem would be to offer the "run in a separate vm, but always use the jre that eclipse is using" option. I would be interested in more on this. The memory footprint should be short lived (the separate VM comes and goes --> build memory should be gc'd) and I see almost no performance difference between same and separate JRE builds.
Ignore the last paragraph of my previous comment. A copy-n-paste error.
As there are numerous workarounds for this problem and this has been the behavior for Eclipse 3.0 and through the 3.1 development I am seeing this more as an enhancement request. Even if not deemed an enhancement, I am not convinced to do this change so late in the 3.1 cycle. You are correct on the separate JRE cost...I was thinking of trivial examples. Sorry. To facilitate sharing of builders with JREs set the Ant launch configuration attribute is set as follows if you select the default JRE: <booleanAttribute key="org.eclipse.ant.ui.DEFAULT_VM_INSTALL" value="true"/> Default jre is defined as: The VM install is explicitly specified on the launch configuration via the ATTR_VM_INSTALL_TYPE and ATTR_VM_INSTALL_ID attributes. If no explicit VM install is specified, the VM install associated with the launch confiugration's project is returned. If no project is specified, or the project does not specify a custom VM install, the workspace default VM install is returned. This is how the Eclipse debug, JDT and Ant teams work with their shared builders.
Deferred for post 3.1 consideration of a feature to automatically serialize same JRE background builds.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
This is still an issue.
*** Bug 338015 has been marked as a duplicate of this bug. ***
