Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: A feature request rather than a bug, but I couldn't find an better place to raise it. IntelliJ IDEA you can have several 'modules' within a project, each with their own source folder and library dependencies defined. We have some very large projects with quite a number of source folders (that get compiled to their own output folder and packaged differently). But the project does not suit being split up into many projects as the code is tightly coupled and managed as one (mostly legacy driving this, but also intrinsic business needs). Development tasks always span many of these source folders and it is tedious to try work across many projects. Nor do we wish to have to checkout each part of the applicaion seperately as if we broke the source modules into separate projects. There are other slightly releated projects that we have open in the same workspace that do warrent being separate projects. We are a very large organisation and looking to IntejiJ IDEA for the simple solution it offers. So I wondered if the Eclipse project would entertain this enhancement. As we have different output folders for most source folders, this may help stop Eclipse doing excessive rebuilds of the entire workspace (if it knows the dependencies between source folders then surely it does not need to do an entire workspace rebuild each time we save a file in one source folder). So there might be a bonus outcome. More information:
Features requests are logged as bugs, so this was the right place. We support multiple source folders but they don't manage their own dependencies; those exist at the project level. This is a fairly substantial architectural choice. It's possible it could be enhanced as you suggested but not any time soon. As for rebuild, a dependency tree is calculated and only those which could be affected are rebuilt. We do not rebuild the entire workspace for every change. Moving to JDT to see if they have any suggestions with respect to project organization.
> We support multiple source folders but they don't manage their own > dependencies; those exist at the project level. This is a fairly substantial > architectural choice. It's possible it could be enhanced as you suggested but > not any time soon. Right, I figured it was pretty major. When you look at the build path configuration it seems tantalisingly simple to beable to define the dependencies in that dialog :) How would I log this as a longer term feature request? > As for rebuild, a dependency tree is calculated and only those which could be > affected are rebuilt. We do not rebuild the entire workspace for every change. > Moving to JDT to see if they have any suggestions with respect to project > organization. Sure, I'd like to understand this one better. We have dozens of frustrated developers that sit watching 'rebuilding workspace' for large portions of their day. Sometimes it just triggers when you save a single line change in a java file , just a string literal or something benign. Then off it goes rebuilding thousands of unrelated classes before you are able to do anything more. I will try and create a more specific and isolated example, but the general problem is something we only observe is large projects (where it really hurts) and we have observed the behavious consistently in Eclipse 3.0 - Eclipse 3.3.1.
About the over-zealous rebuilding workspace; What happens is that (rebuild automatically) it is somehow marked incomplete. This means that when you tend to change anything, even a XML file, ANT script, it then proceeds to wipe out the output folder and start again - which is can be 15+ minutes on some of the developers machines. I have yet to work out why. It comes down to some classes not compiling (but no error message). This behavior also becomes visible when class y fails saying class x does not exist even though it is in the same folder. Workarounds include wiping out classes content, and deleting these problem classes. Letting it rebuild, then undeleting said problem classes which then build ok. At first I was thinking it some kind of circular references issue, but I cannot find it. I'll try and add more detail to make this bug report more useful :-)
David, Scott, for the 'rebuilding entire workspace' problem, I would suggest to enter a separate bug report. We heard of such behavior, but we never get a good bug report. I understand it is frustrating and we would like to fix this. So let's start to investigate this problem in a new bug report (since this one is about a separate issue: defining library and source folder dependencies for a source folder).
also see 131531
*** Bug 131531 has been marked as a duplicate of this bug. ***
*** Bug 125330 has been marked as a duplicate of this bug. ***
To be investigated for M4
Planning discussions lead to remove this item from the 3.5 plan.
