Community
Participate
Working Groups
From eclipse-dev mailing list: We have workspaces that contain more than 100 plugin java projects. I can give some suggestions to make the development more efficient : 1) Iif you change anything of a java source, the autobuild recompiles everything that depends on it. Some changes don't have any impact on the binaries, e.g. reformat the sources, or changing comments; unfortunately this forces an unnecessary autobuild. The autobuild should be more intelligent in such cases. 2) Although we need all projects in the workspace, each person actually only works on some of these projects. There should be a possibility to indicate projects that should not be rebuilt, even when using "clean all projects". Maybe a "use this project as if it is a binary project" is an option. Only when we refresh from the repository, a rebuild and recreation of a binary project should be performed. What we do now as a (quite manual) "bypass", is create binary projects or a couple of "special" plugin projects that only contain the jars with the compiled versions of the projects we need. This way, there is no rebuild for these projects. Big disadvantage is that we have dependencies to that "big" jar-project instead of only the really needed projects. As you can see, the biggest concern we have is the builds. The more projects the workspace contains, the slower its responsiveness.
Re: 1) Actually, formatting will affect binaries, since it will likely change the layout of the code, and thus impact generated line number attributes. If we did not regenerated them, debugging this code would expose inconsistencies. Note that the Java builder is able to realize that source changes were inocuitous, and thus avoid recompiling all further dependents (unlike some timestamp based make facilities). Re: 2) You may try to only build working sets (excluding the offending project), so you would not be paying for rebuilding the offending project until it effectively changes (after refreshing from repository). Also, why do you need to clean/rebuild things that often ? Isn't incremental build all you need (and then again our Java builder is going to be taking care of avoiding unnecessary recompilations)
When the autobuild is on, the working sets are not respected. If autobuild works on the active working set only, then user would not have to wait for the compilation of the projects he/she was not interested in.
Adding John A for discussion re working sets and autobuild.
We considered the possibility of autobuild on a working set when we introduced working set builds in 3.0. The concern was that it would confuse the user's understanding of autobuild. Now, when autobuild is turned on, the user does not need to think about building at all - it just becomes invisible (assuming all incremental builders behave). If autobuild only took care of a subset of the workspace, the building is no longer "automatic" - the user needs to take control of what needs building and when. It's not a strong argument, but that was the reasoning. It seems with this particular user there is a deeper problem forcing him to use "clean", which as Philippe mentions, should never be necessary with proper incremental builders. If the user was truly working on a small set of projects, and the pre-requisite projects rarely or never change, then very long builds should only be happening when the pre-reqs are updated. I'd like to know what other builders he has installed, and what makes him believe a "clean all" is required.
I can not comment on the original report but I have obsorved similiar behaviour. This usually happens, whne a number of projects depend on a library project, and this is a common thing when working on large web applications. I understand the when autobuild is on user should not worry about the build, but when I select a working set I usually do not care about the other projects untill I deselect or switch to another working set. Is it possible to defer the compile until this happens? Or Do the compilation for unselected projects that they do not block anything.
The bottom line is no VM will tolerate inconsistent .class files. So if a prereq project changes and its dependent projects are not recompiled (when affected) then the unchanged .class files can cause the VM to fail. If you do not want to recompile the prereq/libarary project, since it is below the projects in your working set, then why did you update it? If you are working on the library project then do you really need all of the other projects in your workspace?
Sorry for answering late. Well, here are some indications : I didn't investigate in detail, so I cannot say these were/are bugs. Moreover, as the project is delivered, we don't do much work anymore on this one for now. Sometimes, although autobuild is activated, the builder that parses the plugin.xml doesn't run (completely). In that case, only a "clean project" forces this builder to do its job correctly. And this triggers a recompile of other depending projects. Another thing I noticed is that although we (a group of +/- 6 developers) all started with the same workspace (starting from a .psf), some colleagues had problems after some time which they could only "fix" by forcing a complete rebuild, while others didn't have these problems. In the meantime, this might be resolved, as this happened at the time we were using 3.0 milestone releases. Suggestion : maybe you should have different autobuild preferences : autobuild of all projects | autobuild of working set | autobuild of current project. Then when a larger scope autobuild is necessary, the build engine could force it. In this case, "autobuild" means "build as much as is necessary at this moment". And I can understand that this could be very confusing and even confuse lots of developers because they wouldn't see the impact of their changes. A clear and explicit indication (in status bar or maybe better in menubar, with direct possibility to change the option) is in that case necessary.
Is this still an issue ? We now have scoped build (using working sets)
(In reply to comment #9) > Is this still an issue ? We now have scoped build (using working sets) Actually it is still an issue. I only have java projects in the workspace, so no other builders are necessary. Sometimes (quite regularly in fact) the workspace becomes, for an unknown reason, "corrupt" : when I quit Eclipse (3.2M3), the workspace was ok. But then when I start Eclipse again, the workspace doesn't compile anymore, and has plenty of errors. And in that case, even "clean" or "clean all" doesn't work. I actually have to close the projects, then reopen them, and then clean them. And only then does the workspace, step by step, become correct again.
Well we are going to need a lot more details than that to track down the problem. The next time a build fails, please copy the errors so we can see what they are. Also how reproduceable are the failed builds? How many projects in your workspace? How many builders per project?
Yves, please reopen (or create a new PR) when you have more information.
Looks like a duplicate of bug 80162.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
