Community
Participate
Working Groups
I have a java project setup with multiple external tool builders. This lets me call our makefile whenever I change resource that need an external build. My builders look something like: make config Build jar make deploy This, make config only gets run if I change a config file, Build jar happens whenever java files get compiled by eclipse, and make deploy should happen if any of the two steps above get triggered. This is mostly working except for when make deploy gets triggered - I have it set to trigger on a workingset including the jar produced by build jar. However it never gets triggered, I'm guessing because even though Build jar does a refresh of the jar it creates, this is happening during the buid and thus make deploy doesn't get to see it as having changed. Can this be fixed? As a workaround, I can make it trigger on the same files that trigger build jar, but this is a bit of a hack and doesn't scale well if I have multiple other builders whose output I want make deploy to trigger on.
Oops, forgot to mention this is on eclipse I20040413 on linux fedora core 1
This is not currently possible. The way things work under the covers is as follows: * When a build is invoked (auto or manual), the external tool builder first checks if it should "build" by determining if the resources that have changed since the last build include any resources in the relevant working set. If so, the external tool builder runs. However, I do not believe resource changes from builders are used to trigger more builds. John, can you clarify this point?
I'm not sure if I understand the question... If you have three different builders on a project, then each builder will receive a delta that includes changes made by previous builders. However, with the external tool builder, I believe there is only one builder instance, so this won't work; the second copy of the builder will not receive a delta, since nothing has changed since it last finished running.
Clarification: Builder A creates a "jar" file based on a resource delta (changed class files). Builder B deploys the jar file (when the jar changes). However, when the build runs, builder B will not do anything because nothing has change that it cares about (i.e. as John states, the delta will not show that the jar has changed since the last build). I presume there are rules to avoid one builder triggering another - i.e. one build causes a resource change that triggers another?
Yes, changes inside an autobuild do not trigger another autobuild to occur. Again, I think the problem here is that Builder A and Builder B are in fact the same external tool builder. A builder can never see deltas for changes that it made itself.
Deferred
We have similar build problems. An Ant-Build is called to generate Java-Sources from CORBA-IDL files. After that build Eclipse's Java Builder shall be run to compile the generated sources. Since there aren't any Java-Sources until the first builder completes the Java Builder isn't run at all. The problem is still present in the 3.0 final release.
Couldn't you give us back the good old "Rebuild project"/"Rebuild All" which calls all builders in the given order, regardless of the project's state and any builder's delta? Or does anyone know a suitable plugin?
Re comment #7 - it sounds like in your case you just need to put the ant builder before the Java builder, and ensure the Ant builder does not run in the background. That way the Java builder will run after the Ant builder has generated the Java source, and it will be compiled.
The Ant builder is before the Java builder and the ant builder doesn't run in the background. But the Java builder isn't run anyway. May be the problem is that the source folders don't exist when "build project" is performed. When I check out my project from CVS there isn't a folder "generated" yet. That makes sense, since generated sources aren't version controlled. But the folder "generated" is (one of) the JavaProject->Properties...Java Build Path/Source folder. Seems that the condition for the Java builder to be run is evaluated too early. If I do the trick an create the "generated" folder by hand, then - voila - both the ant builder and the Java builder are run.
Created attachment 13047 [details] JavaProject with ExternalTooBuilder and JavaBuilder unzip the project to the file system start a fresh workspace turn off Preferences:build automatically import the unzipped project as an existing project to the workspace try to build the project
I found that JavaBuilder.isWorthBuilding() erroneously returns false. The called method isClasspathBroken() finds Markers of the type org.eclipse.jdt.core.buildpath_problem. You can debug that with the attached project in comment#11. So the JavaBuilder isn't run due to an outdated ProjectInfo. I don't know where the bug is. Should the JavaBuilder cause the ProjectInfo to be updated prior to its isWorthBuilding()? Or should the ExternalToolBuilder do so when its job is done? I also don't know if that kind of problem is actually related to the initial comment. If not, I'm sorry...
I will investigate
Thank you for the test case. It nicely illustrates what is happening. The Java builder has the "generated" folder as a source folder. This folder does not exist yet (it is created by the ant builder). Thus, the Java project initially starts with a build path error. When the build is run, the generated folder is created, but the Java builder's build path error does not go away. I think the Java builder should be detecting that the build path error has been fixed.
I see 2 problems here: 1. No refresh is performed by the first builder so that workspace knows that the missing source folder has been created. Is there some reason why a refresh is not done? 2. The classpath computation generates an error for a missing source folder instead of just creating it... which is what the JavaBuilder would do if given the chance. Now I can change the JavaBuilder to ignore the classpath error & create the 'missing' folder but that's just a hack.
Frank/Mark, can you confirm whether your external tool builder is refreshing the project when it completes (as specified on the "Refresh" tab of your external tool builder configuration).
If your external/ant builder does not refresh, then the JavaBuilder will not see any .java files that you create... assuming the source folder did exist.
The Java builder is supposed to trigger classpath marker updates before doing some work, so presumably the refresh should improve things, since the source folder should be discovered and classpath considered to be fixed (that's the theory).
Yes I was mistaken when I said the JavaBuilder would create missing source folders... we only create missing output folders. We expect source folders to exist (as a resource in the workspace, not just on disk) before a build starts.
Re comment#15 comment#16 As you can see in the attached project the external builder IS refreshing the whole project on completion.
Frank is right - I was reminded again to never rename test projects... I missed a place in the Generator.launch file. So it appears that our classpath computation is either never receiving notification that the 'generated' source folder was created or is not listening for it. But the folder does show up [if you take the testcase as is ;)] & every full build continues to fail. Touching the .classpath file or looking at the project's properties->build path fixes the problem.
*** Bug 74798 has been marked as a duplicate of this bug. ***
A note from my duplicate bug report is that the user who contacted me claims this is a regression for 3.0 and 3.1 (worked in 2.1)
Yep, the regression prevents us from upgrading. The 2.1 builders run in order. A pre java builder may create sources or even source folders that the java builder than takes into account. Therefore the "rebuild project" or "rebuild all" really build. With 3.0 it is not (yet) as convenient to build ones projects.
The bug isn't targeted yet. Is there hope to see the feature in 3.0.2 or 3.1? Sorry for impatience.
We should try to investigate some solution for M6.
*** Bug 86770 has been marked as a duplicate of this bug. ***
*** Bug 114887 has been marked as a duplicate of this bug. ***
I think the root of this problem is JavaProject.flushClasspathProblemMarkers(): IMarker[] markers = this.project.findMarkers(BUILDPATH_PROBLEM_MARKER... for (int i = 0, length = markers.length; i < length; i++) { IMarker marker = markers[i]; if (flushCycleMarkers && flushClasspathFormatMarkers) { marker.delete(); } else { String cycleAttr = marker.getAttribute(CYCLE_DETECTED); String classpathFileFormatAttr = marker.getAttribute(CLASSPATH_FILE_FORMAT); if ((flushCycleMarkers == "true".equals(cycleAttr)) && (flushClasspathFormatMarkers == "true".equals(classpathFileFormatAttr)))) marker.delete(); } } So if only 1 of flushCycleMarkers or flushClasspathFormatMarkers is true, then only problems with the corresponding attribute are deleted. But what about problems with neither of these attributes - such as the problem created for a missing source folder - when are these problems deleted? You need to call flushClasspathProblemMarkers(false, false) or flushClasspathProblemMarkers(true, true) to delete these problems. There is only 1 sender of flushClasspathProblemMarkers(true, true) which will delete all markers and it comes from DeltaProcessor.updateClasspathMarkers() AND only when a JavaProject deletes its JavaNature. There is only 1 sender of flushClasspathProblemMarkers(false, false) which will delete the missing source folder marker and it comes from JavaProject.updateClasspathMarkers(), which looks like: public void updateClasspathMarkers(Map preferredClasspaths, Map preferredOutputs) { this.flushClasspathProblemMarkers(false/*cycle*/, true/*format*/); this.flushClasspathProblemMarkers(false/*cycle*/, false/*format*/); WHY make consecutive calls? Since this is the case, should JavaProject.getRawClasspath(boolean createMarkers, boolean logProblems) be ? if (createMarkers) { this.flushClasspathProblemMarkers(false/*cycle*/, true/*format*/); this.flushClasspathProblemMarkers(false/*cycle*/, false/*format*/); classpath = this.readClasspathFile(createMarkers, logProblems); }
I have question: When the JavaBuilder runs and computes its NameEnvironment, it retrieves the classpath with the call: IClasspathEntry[] classpathEntries = javaProject.getExpandedClasspath(true/*ignore unresolved variable*/, false/*don't create markers*/, ...); So why don't we create markers here? Especially when we know that the project has BUILDPATH_PROBLEM_MARKERs
Jerome - can you have a look at this please.
Counter scenario would be that at very beginning, the classpath looks good (no marker), but some builder (ahead of Java builder) is breaking the classpath by deleting a source folder. Our builder should also notice this (i.e. we cannot only check if classpath markers are still legite).
We could always check to see if multiple builders are attached before spending time recreating the markers. And maybe its enough to only do it on full builds.
Unchecking the new 3.2-Preference Java+Compiler+Building/BuildPathProblems:AbortBuildWhenBuildPathErrorsOccur solves all our problems thanks
*** Bug 184333 has been marked as a duplicate of this bug. ***
Is anything being done on this bug? This is causing us much trouble as it requires generated source folders to be checked into our configuration management tool.
(In reply to comment #36) > Is anything being done on this bug? This is causing us much trouble as it > requires generated source folders to be checked into our configuration > management tool. Sorry there is no good solution to this problem for now. Possible workarounds are: 1. Deactivate the checking: Preferences > Java > Compiler > Building > Incomplete Build path > Warning 2. Make the source folder optional (sorry no UI for that) by creating the source entry with an optional attribute (see JavaCore.newSourceEntry(..., IClasspathAttribute[]) and IClasspathAttriibute#OPTIONAL 3. Make the source folder optional by editing the .classpath file, e.g. <classpathentry kind="src" path="src1"> <attributes> <attribute name="optional" value="true"/> </attributes> </classpathentry>
Will try to come up with a solution for 3.4
*** Bug 221151 has been marked as a duplicate of this bug. ***
This problem has been a big pain for my project as well and I very much look forward to seeing a fix. The problems all involve resources created by one project that are used by another. For us, these include both automatically generated java source and third party packages that create jar files. Changing the 'Incomplete Build Path' preference works for us, but leaves a persistent warning in the problems list. One way to force this to go away is to make a trivial modification to each ".classpath" from outside eclipse (e.g., for cp in */.classpath; do echo >> $cp; done), refresh all the projects, and then restore the projects from source control. I'm sure there's a better way, but at least this one is completely rote and doesn't involve a lot of button pushing.
(In reply to comment #40) Sorry Jim, but we don't currently have the manpower to fix this. A good quality patch is welcome though.
Deferring post 3.4
Unfortunately this issue is still present in v3.7.1. We had the same issue in our project with a jar (kind="lib") that is being auto-generated and were able to circumvent the problem with Jerome's suggestion of making the library optional. Not exactly the best solution since the library really is required, but at least the build works now Any plans on addressing this at some point?
At the moment, we find ourselves having bitten off more than we can comfortably chew for 3.8. And Java SE8 work will start bubbling up in priority just after that. As requested in comment#41, patches are welcome - though we can't commit to 3.8 timeframe for review, testing and incorporation.
Created attachment 209350 [details] Draft patch As Srikanth said, I don't expect to be able to spend much time with this any time soon. However, I am attaching a patch, which I think, has the approach we should be looking at. I must also mention that I haven't investigated in depth and the patch is not thoroughly tested. This seem to work for the scenario where the source folder created is not recognized. If someone can come up with a proper fix with tests, we can look at using it.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
