Community
Participate
Working Groups
Build Identifier: 20110615-0604 When I build a project (project1) that references another project (project 2), modified resources within project1 are saved before building. However, modified resources in project2 are not. This seems like a minor bug, however it is very annoying to have to manually save all modified files every time I build. Especially annoying if the modification does not introduce a compile error in which case the non-save is unnoticed. Reproducible: Always Steps to Reproduce: 1. Open preferences (Window->Preferences) 2. Disable "Build automatically" 3. Enable "Refresh using native hooks or polling," "refresh on access," and "save automatically before build" 4. Create two java projects (A and B). 5. Create a class in A (AClass) and a class in B (BClass). 6. Set up references between the projects (A references project B). 7. Add a class member to AClass (private BClass member). 8. Modify AClass (don't save) and build project A. Note that AClass is saved. 9. Modify BClass (don't save) and build project A. Note that BClass is _not_ saved. This worked in Helios.
Jay, can you please follow up? Seems like a regression over Helios. Thanks!
I see that the preference is mapped to org.eclipse.ui.internal.ide.IDEInternalPreferences.SAVE_ALL_BEFORE_BUILD. Unfortunately I don't have the set-up to see what's wrong. Moving to Platform UI for further investigation.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
I don’t know about Java projects, but with CDT projects this bug still exists as of Oxygen.3 (yes, I know I’m behind there). It cannot be observed with the "Build project" command because CDT implemented it themselves there in org.eclipse.cdt.internal.ui.cview.BuildGroup.CDTBuildAction.run(), but it occurs when using "Build working set" with a working set that does not include the referenced project. This seems quite easy to fix (to the point that I was wondering whether it was intentional behavior, which led me to this bug) and I have done it here: https://gitlab.indel.ch/thirdparty/eclipse.platform.ui/-/commit/8c89c1943e3d7121393add3eb94ec25364a71de6 (isBuildReferencedSet() is something I introduced myself in the preceding commit, upstream it is always true.) No Gerrit for now as I haven’t tested on a current version.
(In reply to Christian Walther from comment #4) > I don’t know about Java projects, but with CDT projects this bug still > exists as of Oxygen.3 (yes, I know I’m behind there). It cannot be observed > with the "Build project" command because CDT implemented it themselves there > in org.eclipse.cdt.internal.ui.cview.BuildGroup.CDTBuildAction.run(), but it > occurs when using "Build working set" with a working set that does not > include the referenced project. > > This seems quite easy to fix (to the point that I was wondering whether it > was intentional behavior, which led me to this bug) and I have done it here: > https://gitlab.indel.ch/thirdparty/eclipse.platform.ui/-/commit/ > 8c89c1943e3d7121393add3eb94ec25364a71de6 Please note, your patch is not going to check references of referenced projects :-) > No Gerrit for now as I haven’t tested on a current version. Feel free to provide one, once you have everything tested.
(In reply to Andrey Loskutov from comment #5) > Please note, your patch is not going to check references of referenced > projects :-) Good point, I just copied the CDT solution without checking whether IProject.getReferencedProjects() is recursive. I’ll improve that.
In case anyone is interested, here’s the improved version that considers recursive references. It also does it on the build configuration rather than project level - not sure if that adds any value, but it seems more fine-grained. This depends on the assumption that project references entered by the user are automatically translated into build configuration references, which I only checked empirically. https://gitlab.indel.ch/thirdparty/eclipse.platform.ui/-/compare/efee555b...2c9614a5
(In reply to Christian Walther from comment #7) > In case anyone is interested, here’s the improved version that considers > recursive references. It also does it on the build configuration rather than > project level - not sure if that adds any value, but it seems more > fine-grained. This depends on the assumption that project references entered > by the user are automatically translated into build configuration > references, which I only checked empirically. > > https://gitlab.indel.ch/thirdparty/eclipse.platform.ui/-/compare/efee555b... > 2c9614a5 Could you please create a Gerrit review with this patch?
I plan to do that once we update our product to a current Eclipse release and I can test it there - or would you like it untested right now? I don’t have time to update my development environment right now.
(In reply to Christian Walther from comment #9) > I plan to do that once we update our product to a current Eclipse release > and I can test it there - or would you like it untested right now? I don’t > have time to update my development environment right now. Feel free to provide a Gerrit if you are ready. I just assumed the last comment was saying that the right patch is already there.
Moving to 4.19. Feel free to move this bug back to 4.18 if you plan to fix this bug for 4.18.
Removing the target for now.
Working on it, but I won’t make it in time for 4.19.
(In reply to Christian Walther from comment #13) > Working on it, but I won’t make it in time for 4.19. Please re-target when you are ready.
