Community
Participate
Working Groups
Build ID: I20070621-1340 Executive summary: " Wanted: * One instance of settings for several source code trees. * One-way dependencies between the source trees. " Detailed description: This is really bug 35973 comment 59 extracted into its own bug report. Since bug 35973 has turned into a general "Eclipse projects are broken" complaint forum that will never get fixed I'm reporting this very specific issue separately. Please don't dup this into 35973. Imagine you have two source trees, "main" and "test". Code in the "test" tree can use code from "main", but not the other way around. Eclipse should enforce this in the JDT by preventing code completion, imports and the like if they are done the wrong direction. This is currently doable using two separate projects and setting up dependencies between them. Also, I'd like to have one set of settings for the two source code trees. So that if I decide to change the warning levels I can do this in one place and have the change affect both source trees. This is currently doable by having both source trees in the same "project". However, I'd like to have *both* source tree dependencies, *and* one set of settings *at once*. And I want to be able to submit the whole thing to my source code repository. Then, when somebody else extracts everything from there, they too get one set of settings, and two one-way dependent source trees. Messing with the source code repository as suggested in bug 35973 comment 55 is a workaround but not a fix. Having two source folders in the same project as suggested in bug 35973 comment 57 doesn't solve the interdependency problem. I'm putting this on JDT because I'm guessing the JDT is the entity that builds, and needs to start supporting dependencies between different source trees.
Would having settings inheritance between projects (i.e. if project P2 requires P1, it inherits the settings of P1 by default) work for you ?
Yes, I can't see why that wouldn't work.
Moving to Platform/Resources then, as this would be where the settings inheritance would have to be implemented.
The idea with settings' inheritance has some disadvantages. You could have the same settings for projects that are not dependent. The other issue would be the case when a project depends on many projects. I would consider fixing it on the UI level. So far the Properties option (Alt+Enter) is disabled when more than one project is selected. I think that the option should be enabled but only common settings should be visible in the properties dialog. In this case each project would have its own settings, however users would be able to modify them together. I'm reassigning it to UI for comments.
Tod, I'm not sure what's being asked here, please feel free to re-assign. PW
I don't think there is such a thing as common settings - i.e two objects may support the same properties but the values of those properties would be different If two objects were to share properties we would need something from Platform Resources to tell us this.
The idea is that a property page could specify that it supports modifying properties on multiple elements at once (perhaps via an extension to IWorkbenchPropertyPage interface). For example, a property page that supports IProject as input could then take IProject[] as input. Any property change would be applied to all elements. A user could then multi-select ten or twenty projects (or other input element), and modify several at once. This is common in other applications, for example in Windows Explorer you can multi-select a group of files, and set the read-only bit, etc, on all files at once via the Properties dialog.
How about this? I right click my project and do "Properties". I select Java Build Path. My project has two source folders, src/main and src/test. I select src/test, and click the "Edit..." button. One of the Edit source folder tabs is called "Access Rules". It has a list of all source folders in this project, with a check box for each source folder. src/main is checked, since src/test can access code in src/main. src/test is gray (and checked), since src/test must always be able to access itself. To maintain backwards compatibility, everything is checked by default. This way, an Eclipse project will still be the logical entity to represent one real-world project, and settings sharing between projects in the general case can be solved outside the scope of this request. This would be an alternative approach to what has been suggested so far.
My 2 cents: I think that to solve this problem it is enough to implement what is stated in comment 8. Idea presented in comment 7 seems to be quite attractive, but I am afraid it will be very limited - it will require discussion for every property page, and I am afraid a lot of project related properties cannot be handled in that way. Could you please imagine that we are trying to open build path properties that have totally different dependencies? And we want only to add some new one? how we can do that? And we have to remember that various project has various properties set... Actually I believe that multiple project modification is possible only for a few property pages. All this leads me towards more strict control - I am thinking about some kind of working set, that is able to control common properties. And now, if you try to add a project to that set, you will have to adjust settings to much properties... If you remove, properties from working set will be copied to the project...
Jerome should comment on the idea from the comment #8. The common settings (the comments #4 and #7) would be more useful and I would suggest to go this way.
The idea in comment #7 is really only applicable for certain property pages. I agree the build path property page couldn't be edited in this way. In Equinox we have 50+ plugins that we want to all have the same Equinox settings for formatter, organize imports, and compiler warnings. When we decide the alter the Equinox coding conventions, we have 50 different plugins (many of which are unrelated) to update settings for. This has become a nightmare to manage. We can't just set the workspace level settings, because many of us are also committers on other projects/components that have different coding conventions. Perhaps this is a different problem from Johan, but it seemed like Szymon's idea would address both cases.
(In reply to comment #10) > Jerome should comment on the idea from the comment #8. The common settings (the > comments #4 and #7) would be more useful and I would suggest to go this way. > Actually, I'm not the JDT/UI lead. Martin, do you want to comment?
Adding Dani and Markus as Martin is away for the remainder of the month.
To me the solution suggested in comment 8 is targeted at only solving the following (initially reported) problem: allow to put test and main source into the same project (in order to share the settings) and allow to specify dependency relations between source folders. Whether JDT Core can or even wants to support this should be commented by them (i.e. Jerome). Personally I'm in favor of a more general solution. I agree with Szymon that inheritance isn't the way to go. What could work though is allowing a property page to specify another (template) project from which to take the defaults (similar to what we have today where defaults can be taken from the workspace). This would allow to share preferences amongst unrelated and also dependent projects. Of course we'd need to store those preferences along with the selected project in order to have a self-contained project in CVS. Allowing to modify the properties of several resource at once (e.g. change encoding or read-only flag for two files in one step) would be useful too but I'd prefer the above solution. See also related bug 194414.
By the way, regarding the test/source folders issue, I think the easiest way to go would be that described in bug #49611, but it seems out of scope for the JDT team :-( Mauro.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
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.
