Community
Participate
Working Groups
Build 3.3M2 (1) When an incoming change occurs on a manifest file, one has to manually force a classpath update to see it in effect (e.g. change the required exec env). (2)When using the manifest editor to change the required exec env, a manual classpath update is also mandated to apply the change. I would expect this to occur on save for free, if (1) was implemented.
The consequences of not doing this are pretty bad. The user will end up with inconsistencies without knowing how to resolve them. If clicking on "Update classpath" fixes it, it should be done for the user without any user interaction. See bug 185129 for the kind of consequences the user can get.
If you change the execution environment on the classpath, you also have to adapt the project-specific compiler compliance settings.
(In reply to comment #2) > If you change the execution environment on the classpath, you also have to > adapt the project-specific compiler compliance settings. It is important to not let PDE interfere with the owners of the JRE container (JDT/Debug). If you feel that some project setting need to be adjusted if the JRE container changes on the classpath, then file a bug report against JDT/Debug.
Olivier, even with PDE implicitly updates the project settings when the manifest.mf changes, these changes won't take effect since the compiler does not react to changes when JavaCore.setOptions(...) gets called. see bug 164244 comment 5 and onward to see what PDE has to do for the changes to take effect. I am not sure PDE should be forcing an implicit rebuild here.
My concern is to prevent a configuration that will only lead to problems. So a rebuild is not a bad thing since a manual update will force a rebuild anyway.
we got into situations before where calling IProject.build(...) was screwing up the overall build order in JDT. How do you recommend we hint to the compiler to rebuild?
Just to be clear: It is fair to ask PDE to synchronize the manifest.mf with the EE-based JRE container entry in the .classpath file to make sure they match. This is what the purpose of this bug report was. As for synchronizing compliance settings and ensuring they are compatible with the EE-based JRE container, this should be the responsibility of the owner of the JRE container (JDT/Debug). After all, EE-based JREs are not a PDE concept, they are a JDT concept. PDE is just one client. PDE currently updates the compliance settings on demand because they are not being done by JDT. But this should not be the case, and we should not optimize PDE to start doing it implicitly. Instead, PDE should stay completely out of the way (and stop updating compliance settings) and have JDT/Debug update the compliance settings when the JRE container changes.
Martin, is there already a JDT UI request that covers what Wassim describes in comment#7 ?
Darin, we have code that does that. it only uses jdt/core. perhaps it could be pushed down?
(In reply to comment #8) Yes, see bug 176516.
(In reply to comment #8) > Martin, is there already a JDT UI request that covers what Wassim describes in > comment#7 ? We had discussions how we could solve that. jdt.core should somehow derive the compliance settings from the selected JRE. But at the moment, jdt.core doesn't have the concept of a JRE and also doesn't know anything about execution environments. At the moment there's no other way for PDE than set the JRE _and_ the compliance settings. But that again is easier said than done, as there is no clear mapping between EE's and compliance. For the New Java project wizard I used a heuristic in a util method: JavaModelUtil: public static String getExecutionEnvironmentCompliance(IExecutionEnvironment executionEnvironment) { String desc= executionEnvironment.getId(); if (desc.indexOf("1.6") != -1) { //$NON-NLS-1$ return JavaCore.VERSION_1_6; } else if (desc.indexOf("1.5") != -1) { //$NON-NLS-1$ return JavaCore.VERSION_1_5; } else if (desc.indexOf("1.4") != -1) { //$NON-NLS-1$ return JavaCore.VERSION_1_4; } return JavaCore.VERSION_1_3; } Maybe at some point launching could take over that code.
Currently, the EE on the build path and the compiler compliance are on different property pages. So there are two scenaiors to deal with - 1) creating a new project fromt the wizard (which does set compliance based on EE), and 2) changing a project's build path (EE) (which does not change the compliance setting). I think we need to be careful with (2), since changing the EE does not neccessarily mean the users want to change their complicance setting.
(In reply to comment #12) > I think we need to be careful with (2), since changing the EE does not > neccessarily mean the users want to change their complicance setting. Right, but we should be careful to keep the user in a consistent state. Let's say the user used to run with a 1.4 VM. He/she defined several projects (either Java or Plugin projects) and he/she never changed the project's specific compiler settings since the workspace ones used to be fine. Now he decides to move to a 1.5 VM to run Eclipse. This is changing the default compiler settings for the workspace. Are all the existing project's settings also updated to used project's specific settings instead of the workspace settings?
We only detect/set the default VM and compliance setting in new workspaces - we don't change existing workspaces.
Could this happen on checking out an old project that doesn't define the specific compiler settings and that was develop in a workspace using 1.4 settings instead of 1.5? Now the user switched to a 1.5 VM to start a new workspace in which he/she checks out the old project. Do we report an error in this case? Do we change the project's settings to be project's specific settings? I guess not since we cannot know what settings to set for the project, but we should at least detect and report this to the user with a quickfix to solve it :-).
Starting a new workspace on 1.5 and checking out projects that have "workspace default" settings will result in 1.5 compliace, where it used to be 1.4. However, that is the danger of using "default" settings. If you need something specific, the project should be configured as such.
Ok, sure. It is dangerous to use default settings. Now we are back to what PDE does when setting the EE of a plugin project. Are the compiler settings moved to project's specific settings even if they are identical to workspace setttings? My point is that we should make sure that this cannot happen with new projects, but also that we detect old projects which are in an inconsistent state.
>Are the compiler settings moved to project's specific settings even if they >are identical to workspace setttings? Yes, we set them directly in the project preferences even if they are identical.
So only existing projects that used the default settings (being different from the actual default settings) are in trouble. If this is a plugin project, could not PDE report an issue when computing its classpath ? If this is a java project, I guess it has to be done by JDT/UI since JDT/Core doesn't know the EE.
We do report a warning on the manifest if there is a mismatch between the EE in the manifest and the JRE container in the .classpath. A mismatch between the JRE container and the compliance settings should be handled by JDT.
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.
